Codecs, I need just 1 phone to use g729, all others use g711

Michael Durham · ‎05-17-2013

I have a completly working CME netowrk and all calls are G711u codec. My office is a remote office and I use a VPN to connect my remote IP phone to the CME router at the main office. Right now all my calls are also using the G711u codec. What do I need to set up so that my phone uses the G729 codec while all of the other phones still use G711u?

I set my ephone to use G729r8 but when I make outbound calls via our SIP provider, my calls are using G711u. What else do I need to configure?

I only need calls to the SIP VoIP provider to be G729. I do not care if internal calls are still G711.

ADDED.... Office CME router config. Public IP's were changed to protect our privacy.

Chris Deren · ‎05-17-2013

Under the ephone specify the codec, i.e.

ephone 1

codec g729r8

HTH,

Chris

Michael Durham · ‎05-17-2013

Chris,

I did that but when I make outbound calls to the PSNT the calls are using G711u still. I don't know how to tell if my connection to the CME router is using G729 and the router is using translation. But I do know that ther is no translation configured on the router.

I'll add my office's CME router config above.

Chris Deren · ‎05-17-2013

Looks like you are using SIP trunk, normally SIP trunk providers offer single codec. Did you check with them if G729 is available? Also, you can see what is being negotiated in "debug ccsip messages".

Chris

Michael Durham · ‎05-17-2013

I have a call into Broadvox to see what they offer and what we have. Right now I know we are using G711 through them.

I changed our public IP to 50.1.1.1, our office number to 2535551000 and my cell phone (the called number) to 8005551212

here is the debug you requested. Thanks for your help!

SIP Call messages tracing is enabled

2851_CME#

May 17 15:52:49.861: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:8005551212@ld01-04.fs.broadvox.net:5060 SIP/2.0

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DC1F6B

Remote-Party-ID: <2535551000>;party=calling;screen=no;privacy=off

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>

Date: Fri, 17 May 2013 15:52:49 GMT

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 2797537368-3191869922-2668149122-2998849022

User-Agent: Cisco-SIPGateway/IOS-12.x

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

CSeq: 101 INVITE

Max-Forwards: 70

Timestamp: 1368805969

Contact: <2535551000>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 282

v=0

o=CiscoSystemsSIP-GW-UserAgent 4363 5505 IN IP4 50.1.1.1

s=SIP Call

c=IN IP4 50.1.1.1

t=0 0

m=audio 19352 RTP/AVP 0 18 101

c=IN IP4 50.1.1.1

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

May 17 15:52:49.937: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DC1F6B

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

CSeq: 101 INVITE

Timestamp: 1368805969 0.000223

User-Agent: Broadvox Fusion

Content-Length: 0

May 17 15:52:51.141: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DC1F6B

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

CSeq: 101 INVITE

Contact: <8005551212>

User-Agent: Broadvox Fusion

Accept: application/sdp

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

Supported: timer, precondition, path, replaces

Allow-Events: talk, hold, refer

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 222

v=0

o=Sonus_UAC 5410 31029 IN IP4 10.128.66.100

s=SIP Media Capabilities

c=IN IP4 64.156.174.71

t=0 0

m=audio 17870 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

May 17 15:52:56.226: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DC1F6B

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

CSeq: 101 INVITE

Contact: <8005551212>

User-Agent: Broadvox Fusion

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

Supported: timer, precondition, path, replaces

Allow-Events: talk, hold, refer

Min-SE: 1800

Content-Type: application/sdp

Content-Disposition: session

Content-Length: 222

v=0

o=Sonus_UAC 5410 31029 IN IP4 10.128.66.100

s=SIP Media Capabilities

c=IN IP4 64.156.174.71

t=0 0

m=audio 17870 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

May 17 15:52:56.234: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:8005551212@208.93.227.215:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DD7C8

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K

Date: Fri, 17 May 2013 15:52:49 GMT

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0

May 17 15:53:21.666: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:8005551212@208.93.227.215:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DE1218

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K

Date: Fri, 17 May 2013 15:52:49 GMT

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1368806001

CSeq: 102 BYE

Reason: Q.850;cause=16

P-RTP-Stat: PS=1399,OS=223840,PR=1527,OR=244320,PL=0,JI=0,LA=0,DU=25

Content-Length: 0

May 17 15:53:21.762: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DE1218

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

CSeq: 102 BYE

Timestamp: 1368806001 0.000072

User-Agent: Broadvox Fusion

Content-Length: 0

May 17 15:53:21.762: //1957/A6BF08589F08/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 50.1.1.1:5060;branch=z9hG4bK4DE1218

From: <2535551000>;tag=379C63D8-E2A

To: <>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K

Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1

CSeq: 102 BYE

User-Agent: Broadvox Fusion

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

Supported: timer, precondition, path, replaces

Content-Length: 0

Michael Durham · ‎05-17-2013

I was talking to our office's SIP provider and they ran a WireShark while I caled their test phone. I have a copy of this capture. From what they saud, the packets are getting stacked up real bad on the office router. Looking at the audio stream they captured, my inbound stream is perfect but my outbound stream is packing up real bad.

This tells me that the problem is defeantly on our end, not the SIP providers'.

Since the CME router is on the 192.168.2.0 network and my phone is on the 192.168.3.0 network that is tunneled through the 172.30.1.0 network, something is causing my outbound rtp packets to back up in the system.

Any ideas?

will.alvord · ‎05-17-2013

The initial invite sent lists these allowed codecs in the sdp: g711ulaw and g729 (0 = g711u and 18=g729). However when the other end continues the codec negotiation (in the sdp of the 183 message), you see that they only specify g711u. This implies that your provider only supports g711ulaw, but it doesn't hurt to ask them if they support something else.

Michael Durham · ‎05-17-2013

I set up another outbound dial-peer as below and my outbound calls are not being made with the g729 codec.

dial-peer voice 10 voip

translation-profile outgoing PSTN_Outgoing

destination-pattern ..........

session protocol sipv2

session target sip-server

incoming called-number 1005

voice-class codec 2

dtmf-relay rtp-nte

no vad

It helped my QoS issue a lot but not completely.

Tahnks for your help

will.alvord · ‎05-20-2013

Michael,

It sounds like you're working on 2 issues -- qos and codec negotiation. The dial-peer config in your last post has no qos-related configs so I'm not sure what you mean by that helped with your qos issue. Disabling vad might have the audible effect of sounding better but it's not qos-related. There are no qos-related configs in the configs attached to your 1st post either.

As for your codec negotiation issue... Has your service provider confirmed the codecs they support? Even if you are allowing 729 but your provider isn't, negotiation at that codec will fail. I'm assuming that your 2 codec class only has g729? If you look at the sdp data in your provider's response to your invite -- you'll see what codecs they're allowing. That will be the proof of what codecs your provider supports. It takes a few seconds to check and is relatively painless even if you don't have a lot of experience interpreting sip messaging.

cheers,

will

Michael Durham · ‎05-20-2013

I have added my router ans switch's config files above.

My latest office side now has a 4th dial-peer which changes it so ALL my calls DO go out G729. This has helped call quality a bit but not good enough to use as a business line.

!
dial-peer voice 4 voip
description ** Outgoing G729 **
translation-profile outgoing PSTN_Outgoing
source-pattern 1005
destination-pattern ..........
session protocol sipv2
session target sip-server
voice-class codec 1
dtmf-relay rtp-nte
no vad
!

Other than no VAD, I do not know of any QoS settings I can make in the dial-peer.

Thanks for your help!