05-17-2013 06:43 AM - edited 03-16-2019 05:22 PM
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.
05-17-2013 07:12 AM
Under the ephone specify the codec, i.e.
ephone 1
codec g729r8
HTH,
Chris
05-17-2013 08:24 AM
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.
05-17-2013 08:40 AM
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
05-17-2013 09:00 AM
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=off2535551000>
From: <2535551000>;tag=379C63D8-E2A2535551000>
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>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-E2A2535551000>
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-E2A2535551000>
To: <>>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K
Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1
CSeq: 101 INVITE
Contact: <8005551212>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-E2A2535551000>
To: <>>8005551212@ld01-04.fs.broadvox.net>;tag=y9aNKB4ta1H6K
Call-ID: A915CD2A-BE4011E2-9F0DB982-B2BECDFE@50.1.1.1
CSeq: 101 INVITE
Contact: <8005551212>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-E2A2535551000>
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-E2A2535551000>
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-E2A2535551000>
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-E2A2535551000>
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
05-17-2013 11:54 AM
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?
05-17-2013 12:29 PM
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.
05-17-2013 02:09 PM
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
05-20-2013 06:16 AM
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
05-20-2013 12:02 PM
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!
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