cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6619
Views
5
Helpful
7
Replies

Outbound codec preference based on region

Tom Ribbens
Level 1
Level 1

Hi all,

We have a CUCM cluster, connected to a CUBE connected to the provider. All trunks are SIP:

CUCM --- SIP --- CUBE --- SIP ----PSTN.

The connection to the PSTN is centralized, but there are multiple offices. Through Region settings, all local traffic is set to G.711, but all WAN traffic is G.729, except for faxes. The provider also supports both G.711 and G.729. On incoming calls, the region settings apply, and most calls enter as G.729, except for those in the Device Pool Faxes, which is connected to the Faxes Region. The connection to the PSTN is also adapted to the phone region setting, so no transcoding occurs.

Outgoing however, we see that the connection to the PSTN is whatever we put first in the codec class, and if nessecary, transcoding is done on the gateway. Is it possible negotiate the outgoing codec based on the region settings of the phone?

We currently solved it by adding a prefix to the dialed number and matching a different dial-peer for faxes, but I was wondering if it is possible some other way.

Thanks in advance,

Tom

1 Accepted Solution

Accepted Solutions

Tom after more investigation, I think I finally figure out how the codecs are been selected....

+++++Inbound call+++++++++
Region between phone and cube is set to use G711
inbound and outbound dial-peer set to use voice class codec with g729 as prefered codec

+++Cube receives invite from ITSP with early offer and all supported codecs++++

Received:
INVITE sip:442089650004@172.16.5.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.49:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <07755669900>;tag=451687893-1338998863036-
To: "codec test"<>442089650004@pbx.nationgridemea.globalipcom.com>
Call-ID: BW1807430360606122118811314@192.168.50.90
CSeq: 558275167 INVITE
Contact: <07755669900>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Supported:
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 207

v=0
o=BroadWorks 161384816 1 IN IP4 192.168.50.100
s=-
c=IN IP4 192.168.50.100
t=0 0
m=audio 15382 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no

++++++CUBE sends invite to cucm with early offer and codecs macthed on voice-class codec+++++++++

Sent:
INVITE sip:902089650004@10.100.10.50:5060 SIP/2.0
Via: SIP/2.0/TCP 172.16.5.10:5060;branch=z9hG4bK7954A198F
Remote-Party-ID: <07755669900>;party=calling;screen=no;privacy=off
From: <07755669900>;tag=4C85AF62-DA1
To: <902089650004>
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: 94F4C46B-AF2811E1-95F78F4D-5D7E5E41@172.16.5.10
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2499069035-2938638817-2515636045-1568562753
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1338998863
Contact: <07755669900>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 68
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 355

v=0
o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 172.16.5.10
s=SIP Call
c=IN IP4 172.16.5.10
t=0 0
m=audio 16668 RTP/AVP 18 0 8 100 101
c=IN IP4 172.16.5.10
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

++++++++after a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint codec and IP+++++++++
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.16.5.10:5060;branch=z9hG4bK7954A198F
From: <07755669900>;tag=4C85AF62-DA1
To: <902089650004>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917860
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: 94F4C46B-AF2811E1-95F78F4D-5D7E5E41@172.16.5.10
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  84600;refresher=uas
Require:  timer
Contact: <902089650004>
Content-Type: application/sdp
Content-Length: 214

v=0
o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.100.10.50
s=SIP Call
c=IN IP4 10.44.43.13
t=0 0
m=audio 27770 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

+++++++CUBE sends and ACK+++++++++
Sent:
ACK sip:902089650004@10.100.10.50:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.16.5.10:5060;branch=z9hG4bK7954B2403
From: <07755669900>;tag=4C85AF62-DA1
To: <902089650004>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917860
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: 94F4C46B-AF2811E1-95F78F4D-5D7E5E41@172.16.5.10

++++CUBE then sends a 200 ok to ITSP with endpoint codec to use for the call+++++++++
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.50.49:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <07755669900>;tag=451687893-1338998863036-
To: "codec test"<>442089650004@pbx.nationgridemea.globalipcom.com>;tag=4C85AF76-1DE
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: BW1807430360606122118811314@192.168.50.90
CSeq: 558275167 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: kpml, telephone-event
Remote-Party-ID: <902089650004>;party=called;screen=no;privacy=off
Contact: <442089650004>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 3682 3869 IN IP4 172.16.5.10
s=SIP Call
c=IN IP4 172.16.5.10
t=0 0
m=audio 25278 RTP/AVP 0 101
c=IN IP4 172.16.5.10
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

+++ACK then received from ITSP++++

002855: Jun  6 16:07:45.557: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:442089650004@172.16.5.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.49:5070;branch=z9hG4bKhcdhmt20fg9gu7pf22b0.1
From: <07755669900>;tag=451687893-1338998863036-
To: "codec test"<>442089650004@pbx.nationgridemea.globalipcom.com>;tag=4C85AF76-1DE
Call-ID: BW1807430360606122118811314@192.168.50.90
CSeq: 558275167 ACK
Contact: <07755669900>
Max-Forwards: 69
Content-Length: 0


So in summary here is how codec is chosen..


+++INBOUND LEG+++++

on the inbound leg..

The region setting will take effect regardless of what you have configured on the voice-class codec for your inbound dial-peer. This is because when 200 ok is sent CUCM will send the codec defined between the endpoint and the CUBE as the codec. CUBE then passes this on to ITSP.

+++OUTBOUND LEG++++

on the outbound direction...

The advertised codec to ITSP will be used, beacuse ITSP is the one making decision which codec to use based on advertised codec.So here with voice class codec, the preffered codec in the list will be selected by the ITSP and this will be used for the call regardless of what the region setting is on the phone to the cube gateway.

if the codec is hardcoded..if its set to g711, then g711 response will be obtained from the ITSP and that codec will be used for the call.

if its g729 then it will be g729...

So the outbound leg is independent of the region settings beacuse it is the far end that is choosing

what codec to use for the call.

So in both cases the codec selected by the far end will determine what codec is used for the call

Inbound leg, far end is CUCM..region takes effect
outbound leg, far end is ITSP, prefered codec in advertised codec will take effect..Simples!

So if you want to choose a codec for your outbound leg, you have to either set it as preferred in your voice class list or hardcode it such that it is the codec been advertised as the prefferd to your ITSP

NB: on the faxes, on the inbound call we are using voice class codec and region settings (g711 is used for fax). As explained above fax will use G711 because of its region settings to the cube gateway

On the outbound leg, we have done similar config as yours. Prefix digits to the called number and then configure dial-peer to use G711.

Please rate useful posts

"I am complete in God, God completes me"

Please rate all useful posts

View solution in original post

7 Replies 7

In SIP-SIP CUBE, negotiation of an audio codec from a list of codecs is supported in IOS 15.1(2)T. I believe you are running lower IOS which is causing this behaviour.

If you find the post helpful, please rate it.

Namur#show version

Cisco IOS Software, C2951 Software (C2951-UNIVERSALK9-M), Version 15.1(4)M1, REL         EASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2011 by Cisco Systems, Inc.

Compiled Tue 14-Jun-11 19:47 by prod_rel_team

ROM: System Bootstrap, Version 15.0(1r)M6, RELEASE SOFTWARE (fc1)

Namur uptime is 1 day, 9 hours, 34 minutes

System returned to ROM by reload at 01:01:15 CEST Wed Jun 6 2012

System restarted at 01:02:53 CEST Wed Jun 6 2012

System image file is "flash:c2951-universalk9-mz.SPA.151-4.M1.bin"

This is the version I am running. It does seem higher than what you said?

Tom,

NB: I set region between phone and Cube to use G711. I have voice-class codec with g729 preffered..So I was hoping the call will be forced to use G711..but the traces showed it used G729...

I did a test yesterday on this for outbound calls and to my surprise the codec used was not based on the region setting between the phone and the cube. What I saw was that when the invite was received on cube from CUCM, cube sends invite to ITSP with all codecs in its voice-class fconfig...

When the ITSP responded in session progress with SDP, it sent only G729. Hence cube sent 183 to CUCM with only g729 and the call used g729. Even though the region between the phone and cube was set to g711...

trace here..

++++++Invite sent to ITSP++++

Sent:

From: "codec test" <447777777777>;tag=4C8AB41A-1D46
To: <5555555501>
Date: Wed, 06 Jun 2012 16:40:14 GMT
Call-ID: 1FD8C261-AF2D11E1-8E25FE93-B3867CA6@17.17.17.17
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Contact: <447777777777>


v=0
o=CiscoSystemsSIP-GW-UserAgent 6874 7727 IN IP4 17.17.17.17
s=SIP Call
c=IN IP4 17.17.17.17
t=0 0
m=audio 21956 RTP/AVP 18 0 8 100 101
c=IN IP4 17.17.17.17
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

++++Session progress from ITSP+++++

NB that the provider is only sending G729 back..

Received:
SIP/2.0 183 Session Progress

v=0
o=BroadWorks 161411162 1 IN IP4 10.106.33.132
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 18758 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no

++CUBE sends 183 to CUCM with G729+++++++

Sent:
SIP/2.0 183 Session Progress

v=0
o=CiscoSystemsSIP-GW-UserAgent 2278 8254 IN IP4 17.17.17.17
s=SIP Call
c=IN IP4 17.17.17.17
t=0 0
m=audio 29694 RTP/AVP 18 100 101
c=IN IP4 17.17.17.17
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

+++We received 200 ok from ITSP++++

Received:
SIP/2.0 200 OK


v=0
o=BroadWorks 161411162 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 18758 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no

Please rate useful posts

++++CUBE sends 200 OK to CUCM++++

sent:
SIP/2.0 200 OK

v=0
o=CiscoSystemsSIP-GW-UserAgent 2278 8254 IN IP4 17.17.17.17
s=SIP Call
c=IN IP4 17.17.17.17
t=0 0
m=audio 29694 RTP/AVP 18 100 101
c=IN IP4 17.17.17.17
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

++++and the most inportant part cucm sends ACK with SDP with endpoint codec and IP++++


Received:
ACK sip:55555555555@17.17.17.17:5060 SIP/2.0

CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp


v=0
o=CiscoSystemsCCM-SIP 812149 1 IN IP4 10.11.11.10
s=SIP Call
c=IN IP4 10.50.17.20
t=0 0
m=audio 28170 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

So on the outboound direction, it looks as though its what your ITSP sends in the session progress that will determine the codec to be used...I will investigate further...

You can have alook at your logs too and see if you get the same from your traces...

pls rate useful posts

"I am complete in God, God completes me"

Please rate all useful posts

Tom after more investigation, I think I finally figure out how the codecs are been selected....

+++++Inbound call+++++++++
Region between phone and cube is set to use G711
inbound and outbound dial-peer set to use voice class codec with g729 as prefered codec

+++Cube receives invite from ITSP with early offer and all supported codecs++++

Received:
INVITE sip:442089650004@172.16.5.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.49:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <07755669900>;tag=451687893-1338998863036-
To: "codec test"<>442089650004@pbx.nationgridemea.globalipcom.com>
Call-ID: BW1807430360606122118811314@192.168.50.90
CSeq: 558275167 INVITE
Contact: <07755669900>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Supported:
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 207

v=0
o=BroadWorks 161384816 1 IN IP4 192.168.50.100
s=-
c=IN IP4 192.168.50.100
t=0 0
m=audio 15382 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no

++++++CUBE sends invite to cucm with early offer and codecs macthed on voice-class codec+++++++++

Sent:
INVITE sip:902089650004@10.100.10.50:5060 SIP/2.0
Via: SIP/2.0/TCP 172.16.5.10:5060;branch=z9hG4bK7954A198F
Remote-Party-ID: <07755669900>;party=calling;screen=no;privacy=off
From: <07755669900>;tag=4C85AF62-DA1
To: <902089650004>
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: 94F4C46B-AF2811E1-95F78F4D-5D7E5E41@172.16.5.10
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2499069035-2938638817-2515636045-1568562753
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1338998863
Contact: <07755669900>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 68
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 355

v=0
o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 172.16.5.10
s=SIP Call
c=IN IP4 172.16.5.10
t=0 0
m=audio 16668 RTP/AVP 18 0 8 100 101
c=IN IP4 172.16.5.10
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

++++++++after a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint codec and IP+++++++++
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.16.5.10:5060;branch=z9hG4bK7954A198F
From: <07755669900>;tag=4C85AF62-DA1
To: <902089650004>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917860
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: 94F4C46B-AF2811E1-95F78F4D-5D7E5E41@172.16.5.10
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  84600;refresher=uas
Require:  timer
Contact: <902089650004>
Content-Type: application/sdp
Content-Length: 214

v=0
o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.100.10.50
s=SIP Call
c=IN IP4 10.44.43.13
t=0 0
m=audio 27770 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

+++++++CUBE sends and ACK+++++++++
Sent:
ACK sip:902089650004@10.100.10.50:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.16.5.10:5060;branch=z9hG4bK7954B2403
From: <07755669900>;tag=4C85AF62-DA1
To: <902089650004>;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917860
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: 94F4C46B-AF2811E1-95F78F4D-5D7E5E41@172.16.5.10

++++CUBE then sends a 200 ok to ITSP with endpoint codec to use for the call+++++++++
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.50.49:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <07755669900>;tag=451687893-1338998863036-
To: "codec test"<>442089650004@pbx.nationgridemea.globalipcom.com>;tag=4C85AF76-1DE
Date: Wed, 06 Jun 2012 16:07:43 GMT
Call-ID: BW1807430360606122118811314@192.168.50.90
CSeq: 558275167 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: kpml, telephone-event
Remote-Party-ID: <902089650004>;party=called;screen=no;privacy=off
Contact: <442089650004>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 3682 3869 IN IP4 172.16.5.10
s=SIP Call
c=IN IP4 172.16.5.10
t=0 0
m=audio 25278 RTP/AVP 0 101
c=IN IP4 172.16.5.10
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

+++ACK then received from ITSP++++

002855: Jun  6 16:07:45.557: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:442089650004@172.16.5.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.49:5070;branch=z9hG4bKhcdhmt20fg9gu7pf22b0.1
From: <07755669900>;tag=451687893-1338998863036-
To: "codec test"<>442089650004@pbx.nationgridemea.globalipcom.com>;tag=4C85AF76-1DE
Call-ID: BW1807430360606122118811314@192.168.50.90
CSeq: 558275167 ACK
Contact: <07755669900>
Max-Forwards: 69
Content-Length: 0


So in summary here is how codec is chosen..


+++INBOUND LEG+++++

on the inbound leg..

The region setting will take effect regardless of what you have configured on the voice-class codec for your inbound dial-peer. This is because when 200 ok is sent CUCM will send the codec defined between the endpoint and the CUBE as the codec. CUBE then passes this on to ITSP.

+++OUTBOUND LEG++++

on the outbound direction...

The advertised codec to ITSP will be used, beacuse ITSP is the one making decision which codec to use based on advertised codec.So here with voice class codec, the preffered codec in the list will be selected by the ITSP and this will be used for the call regardless of what the region setting is on the phone to the cube gateway.

if the codec is hardcoded..if its set to g711, then g711 response will be obtained from the ITSP and that codec will be used for the call.

if its g729 then it will be g729...

So the outbound leg is independent of the region settings beacuse it is the far end that is choosing

what codec to use for the call.

So in both cases the codec selected by the far end will determine what codec is used for the call

Inbound leg, far end is CUCM..region takes effect
outbound leg, far end is ITSP, prefered codec in advertised codec will take effect..Simples!

So if you want to choose a codec for your outbound leg, you have to either set it as preferred in your voice class list or hardcode it such that it is the codec been advertised as the prefferd to your ITSP

NB: on the faxes, on the inbound call we are using voice class codec and region settings (g711 is used for fax). As explained above fax will use G711 because of its region settings to the cube gateway

On the outbound leg, we have done similar config as yours. Prefix digits to the called number and then configure dial-peer to use G711.

Please rate useful posts

"I am complete in God, God completes me"

Please rate all useful posts

Thanks a lot! That explains it as far as I'm concerned, and now I know I didn't do an unnecesary workaround for the faxes. It would be nice though, if there would be a feature that could adapt the codec preference depending on the region settings.

As stated by Mohammed mid-call codec negoriation is available on CUBE with IOS 15.1.2T:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps10587/ps10592/ps10952/product_bulletin_c25-620744.html

Cisco Unified Border Element (CUBE) Feature Enhancements

• Box to Box Redundancy for SIP Trunk calls with active call preservation

•  Support for mid call negotiation of an audio codec with SIP calls Additional MIBs to all monitoring utilization of critical resources on  the Border Element

• Dial-peer level bind for SIP Messages allowing configuration of multiple incoming SIP Trunk providers

•  Inbound Dial-peer Matching Based on Remote IP Address for SIP  Messages;Topology Hiding in History-info, and Call-routing Based on  History-info

• Support for Voice Mail Waiting Indicator (VMWI) over SIP on Cisco IOS Gateways

Benefits

•  Box to Box redundancy is important for many large scale deployment of  SIP Trunks. This feature provides a important tool to improve resiliency  of Cisco SIP Trunk solution Mid call codec renegotiation enabled new  deployment scenarios that allow for calls to be transferred between  regions that support different codecs.

Chris

Chris,

We were on "c3900e-universalk9-mz.SPA.151-3.T1.bin" and mid call didntt work with faxes. We had to hardcode the codec.

Please rate useful posts

"I am complete in God, God completes me"

Please rate all useful posts
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: