11-17-2013 11:19 PM - edited 03-16-2019 08:27 PM
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
11-18-2013 03:46 AM
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.
11-18-2013 04:05 AM
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
11-18-2013 05:07 AM
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.
11-18-2013 05:25 AM
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
11-18-2013 05:46 AM
that is the task - to force the hardware transcoder using... for test purposes only.
11-18-2013 05:51 AM
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
11-18-2013 06:01 AM
the main purpose is to make a test of hardware transcoder.
I hope I can get the help in this my task
11-18-2013 05:05 AM
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?
11-18-2013 06:16 AM
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.
11-18-2013 11:42 PM
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=1846126945124>
Event: presence
Content-Length: 0
User-Agent: Cisco-CUCM7.1
To: <777111>777111>
Contact: <124>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=1846126945124>
To: <777111>;tag=E5D7F88-23A9777111>
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"192.168.45.231:5060>
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694124>
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=off124>
Content-Length: 0
User-Agent: Cisco-CUCM7.1
To: <777111>777111>
Contact: <124>;video;audio124>
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-32728694124>
To: <777111>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-32728694124>
To: <777111>;tag=E5D87B8-82B777111>
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=off111>
Contact: <777111>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-3272869124>
TEST1#4
To: <777111>;tag=E5D87B8-82B777111>
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=off111>
Contact: <777111>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-32728694124>
Allow-Events: presence, kpml
Content-Length: 0
To: <777111>;tag=E5D87B8-82B777111>
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-82B777111>
To: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694124>
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-82B777111>
Content-Length: 0
To: <124>;tag=3a84564d-80b7-4449-9f46-0f25652d3b58-32728694124>
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-32728694124>
P-Asserted-Identity: <124>124>
Content-Length: 0
User-Agent: Cisco-CUCM7.1
To: <777111>;tag=E5D87B8-82B777111>
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-32728694124>
To: <777111>;tag=E5D87B8-82B777111>
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide