cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1583
Views
0
Helpful
10
Replies

testing a hardware transcoder

Sergey Balyura
Level 1
Level 1

hi everybody!

need help.

I want ot test the hardware transcoder.

I have CUCM and cme.

I have sip trunk between them.

and I have registered hardware transcoders for both.

I have g771u in CUCM region and g729 between CUCM and cme

and I have incoming and outgoing dial-peers on cme with g729 codec

but how to force transcoder using?

when I call in the CUCM region - phones use g711u codec.

when I call from CUCM region to cme region - phones use g729 codec.

when I call from cme to CUCM - phones use g729 codec

thanx in advance

10 Replies 10

Joseph Martini
Cisco Employee
Cisco Employee

An important thing to remember is that setting the region in CUCM to g711 means that g711 is the maximum bandwidth codec that can be used.  If your region is set to g711 it's fine to use a lower bandwidth codec such as g729 if both end points support it which they do.

Here's an easy trick to force a transcoder to be used.  Set the region mapping between the test phone on CUCM and the SIP trunk region to g723.  IP Phones do not support g723 so a transcoder will be forced.  Then make sure that the region mappings between the IP phone registered to CUCM's region and the region of the transcoder is 711, and lastly the region of the transcoder to the region of your SIP trunk is g729.  That will allow the transcoder to be successfully allocated.

When the call is between CUCM and CME/CUBE it is indeed possible to force a codec by using voice-class codec in IOS. That way you can specify both the order of preference and the codecs you only want to be used.

This doesnt apply however when call is between two CUCM, where you can only specify the maximym BW of the codec, through REGIONS.

Let me know if further instrucitons needed.

Francesco

hello, Frankaviglia!

the question is not "how to set up codecs preferences".

I just want to force using the hardware transcoder which is already registered on my CUCM.

I'm sorry, maybe I didnt get the question.

you have trunk between CUCM and CME, you setup the region in a way that if the call is between the two, g729 is required. Both phones and CME can speak g711 and g729. When would you want the transcoder to be involved? And by whom?

Francesco

that is the task - to force the hardware transcoder using... for test purposes only.

Even for a test, it needs to be clear when the Hardware has to be involved. This only happens when one of the end point can not cope with the codec reques and thus it is forced to request a n external codec . If you do not create this condition, the transcoder will never be involved.

so first of all you need to understand what is it that you are trying to test.

Cheers,

F

the main purpose is to make a test of hardware transcoder.

I hope I can get the help in this my task

hi, Joseph!

thanx for rhe reply.

it was a good idea to use 723 codec. but I receive the next message when try to insert "codec g723" statement in incoming dial-peer:

ommitted...

g723ar53       G.723.1 ANNEX-A 5300 bps (contains built-in vad that cannot be

                 disabled) -not supported on PVDM3

  g723ar63       G.723.1 ANNEX-A 6300 bps (contains built-in vad that cannot be

                 disabled) -not supported on PVDM3

  g723r53        G.723.1 5300 bps - Not supported on PVDM3.

  g723r63        G.723.1 6300 bps - Not supported on PVDM3.

ommitted...

as you can see I cannot use g723 codec as a codec for the incoming dial-peer (cause I have PVDM3...)

any other suggestions?

You don't want to or need to set g723 on the dial-peer, the objective here is to leave it out.  Change only the settings in CUCM for this.

Based on this chart:

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml, you can see that g723 uses less bandwidth than g729, so even if you advertise g729 based on the dial-peer configuration it cannot be used because the bandwidth requirement is higher than what we have configured in CUCM by setting the region mapping to g723.  So leave the dial-peer as is with g729, and just change the region relationship between the phone on CUCM and the SIP trunk to g723.

result's negative

here is "deb ccsip mes" output:

TEST1#deb ccsip mess

SIP Call messages tracing is enabled

TEST1#

Nov 19 07:10:15.639: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SUBSCRIBE sip:777111@192.168.47.82:5060 SIP/2.0

Date: Tue, 19 Nov 2013 07:29:39 GMT

From: <124>;tag=1846126945

Event: presence

Content-Length: 0

User-Agent: Cisco-CUCM7.1

To: <777111>

Contact: <124>

Expires: 10800

Call-ID: 57f6f900-28b11363-d43-e72da8c0@192.168.45.231

Accept: application/pidf+xml

Via: SIP/2.0/TCP 192.168.45.231:5060;

TEST1#branch=z9hG4bK1fa0254d4429

CSeq: 101 SUBSCRIBE

Max-Forwards: 69

Nov 19 07:10:15.643: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 489 Bad Event - 'Malformed/Unsupported Event'

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1fa0254d4429

From: <124>;tag=1846126945

To: <777111>;tag=E5D7F88-23A9

Date: Tue, 19 Nov 2013 07:10:15 GMT

Call-ID: 57f6f900-28b11363-d43-e72da8c0@192.168.45.231

CSeq: 101 SUBSCRIBE

Allow-Events: telephone-ev

TEST1#ent

Content-Length: 0

Nov 19 07:10:17.723: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:777111@192.168.47.82:5060 SIP/2.0

Date: Tue, 19 Nov 2013 07:29:41 GMT

Call-Info: <192.168.45.231:5060>;method="NOTIFY;Event=telephone-event;Duration=500"

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

Allow-Events: presence, kpml

P-Asserted-Identity:

TEST1#p:124@192.168.45.231>

Supported: timer,resource-priority,replaces

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Min-SE:  1800

Remote-Party-ID: <124>;party=calling;screen=yes;privacy=off

Content-Length: 0

User-Agent: Cisco-CUCM7.1

To: <777111>

Contact: <124>;video;audio

Expires: 180

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1fa75102de42

TEST1#

CSeq: 101 INVITE

Session-Expires:  1800

Max-Forwards: 69

Nov 19 07:10:17.731: //43/7A990DF88063/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1fa75102de42

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

To: <777111>

Date: Tue, 19 Nov 2013 07:10:17 GMT

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

CSeq: 101 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGa

TEST1#teway/IOS-15.3.3.M1

Content-Length: 0

Nov 19 07:10:17.743: //43/7A990DF88063/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1fa75102de42

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

To: <777111>;tag=E5D87B8-82B

Date: Tue, 19 Nov 2013 07:10:17 GMT

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE,

TEST1#REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <111>;party=called;screen=no;privacy=off

Contact: <777111>

Server: Cisco-SIPGateway/IOS-15.3.3.M1

Content-Length: 0

Nov 19 07:10:19.391: //43/7A990DF88063/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1fa75102de42

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-3272869

TEST1#4

To: <777111>;tag=E5D87B8-82B

Date: Tue, 19 Nov 2013 07:10:17 GMT

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: <111>;party=called;screen=no;privacy=off

Contact: <777111>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-15.3

TEST1#.3.M1

Require: timer

Session-Expires:  1800;refresher=uac

Supported: timer

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 218

v=0

o=CiscoSystemsSIP-GW-UserAgent 4080 9541 IN IP4 192.168.47.82

s=SIP Call

c=IN IP4 192.168.47.82

t=0 0

m=audio 16430 RTP/AVP 0 19

c=IN IP4 192.168.47.82

a=rtpmap:0 PCMU/8000

a=rtpmap:19 CN/8000

a=ptime:20

Nov 19 07:10:19.399: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:777111@

TEST1#192.168.47.82:5060;transport=tcp SIP/2.0

Date: Tue, 19 Nov 2013 07:29:41 GMT

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

Allow-Events: presence, kpml

Content-Length: 0

To: <777111>;tag=E5D87B8-82B

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1fae7f015f78

CSeq: 101 ACK

Max-Forwards: 70

Nov 19 07:10:19.411: //43/7A990DF88063/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:124

TEST1#@192.168.45.231:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 192.168.47.82:5060;branch=z9hG4bK122172

From: <777111>;tag=E5D87B8-82B

To: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

Date: Tue, 19 Nov 2013 07:10:19 GMT

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

User-Agent: Cisco-SIPGateway/IOS-15.3.3.M1

Max-Forwards: 70

Timestamp: 1384845019

CSeq: 101 BYE

Reason: Q.850;cause=86

P-RTP-Stat: PS=0,OS=0,PR=0,OR=0,PL=0,JI=0,LA=0,DU=0

TEST1#

Content-Length: 0

Nov 19 07:10:19.411: //43/7A990DF88063/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Date: Tue, 19 Nov 2013 07:29:43 GMT

From: <777111>;tag=E5D87B8-82B

Content-Length: 0

To: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

Via: SIP/2.0/TCP 192.168.47.82:5060;branch=z9hG4bK122172

CSeq: 101 BYE

Nov 19 07:10:19.599: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg

TEST1#:

Received:

BYE sip:777111@192.168.47.82:5060;transport=tcp SIP/2.0

Reason: Q.850;cause=47

Date: Tue, 19 Nov 2013 07:29:41 GMT

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

P-Asserted-Identity: <124>

Content-Length: 0

User-Agent: Cisco-CUCM7.1

To: <777111>;tag=E5D87B8-82B

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1faff032471

CSeq: 102 BYE

Max-Forwa

TEST1#rds: 70

Nov 19 07:10:19.599: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 481 Call Leg/Transaction Does Not Exist

Via: SIP/2.0/TCP 192.168.45.231:5060;branch=z9hG4bK1faff032471

From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694

To: <777111>;tag=E5D87B8-82B

Call-ID: 59282600-28b11365-d47-e72da8c0@192.168.45.231

CSeq: 102 BYE

Content-Length: 0

as I understand the reason of disconecting - codec mismatch. and this is the result I expect.

if the incoming dial-peer on CME exists it has g729 codec as default codec

so how can CUCM and CME choose the right codec? CUCM cannot use more bandwidth then g723 use. and CME accepts only g729.

if I woulm be able to use g723 codec on CME... but I cannot.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: