Hello Support Community,
I have a question about behaviour on the Cisco CUBE when it gets a Re-INVITE in order to resume a call on hold.
I see in the SIP traces, and in the Call Statistics one the phone itself, that the codec changes from a-law to u-law as soon as the call is resumed which then invokes transcoding resources which is not really needed, IMO.
So far, the u-law codec has not been completely disabled through the Service Parameters in CUCM, and we still have it in the voice class codec configuration on the CUBE, and this voice class is applied to the dial-peer "facing" to and from the CUCM :
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
On the dial-peers facing to and from our ITSP, we have the voice class where only the g711alaw codec is included (as the ITSP accepts only a-law)
The test scenario is calling an external number from a Cisco phone, pressing hold and resuming the call.
For the Music-On-Hold we have disabled the u-law codec as the first step of troubleshooting and resolving the issue. After the change, the codec is always a-law for the MoH :
v=0
o=CiscoSystemsCCM-SIP 114970291 2 IN IP4 *CUCM5_IP*
s=SIP Call
c=IN IP4 *CUCM2_IP*
t=0 0
m=audio 31058 RTP/AVP 8
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:8 PCMA/8000
I was not suspecting that any dial-peers are being matched when the CUBE gets the Re-INVITE, but one of our test calls was still using a-law codec after pressing resume. Cheking into the SIP traces we see that in this case CUBE answered with 200 OK w/ SDP (for the Re-INVITE):
v=0
o=CiscoSystemsSIP-GW-UserAgent 3170 5288 IN IP4 *CUBE_IP*
s=SIP Call
c=IN IP4 *CUBE_IP*
t=0 0
m=audio 23540 RTP/AVP 8 101
c=IN IP4 *CUBE_IP*
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
where as it usually answers with :
v=0
o=CiscoSystemsSIP-GW-UserAgent 1131 1704 IN IP4 *CUBE_IP*
s=SIP Call
c=IN IP4 *CUBE_IP*
t=0 0
m=audio 22978 RTP/AVP 8 0 18 101
c=IN IP4 *CUBE_IP*
a=rtpmap:8 PCMA/8000
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-15
a=ptime:20
and on that the CUCM replies with ACK w/SDP (u-law is negotiated):
v=0
o=CiscoSystemsCCM-SIP 114970291 3 IN IP4 *CUCM5_IP*
s=SIP Call
c=IN IP4 *PHONE_IP*
b=TIAS:64000
b=AS:64
t=0 0
m=audio 17156 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Before the testing, we've configured another dial-peer with a destionation-pattern set to our internal test phone and with voice class where only the a-law codec is included. Because we saw a call using a-law after resume, it made me think that maybe dial-peer matching is triggered after the CUBE received the Re-INVITE and somehow this additional dial-peer was matched. Unfortunately in this case the debug voice ccapi inout was not enabled, but in the case when the codec changes from a-law to u-law, I also don't see that there is any dial-peer matching done because of the Re-INVITE...or maybe I missed it as the volume of calls on the CUBE is quite large at any given point in time.
The phone and the SIP trunk pointing to the CUBE are in different Device Pools (different Regions) and the relationship between those regions should used the modified Codec Preference list where the a-law codec is higher in the list than u-law.
The plan is to disable the u-law codec completely eventually but in the mean time it would be interesting to know if my suspicion is valid and also why the CUCM sends ACK with u-law (although the call was initiated and connected with a-law) while the 200 OK from CUBE offers/prefers a-law as it is configured in the voice class codec.
CUCM : 10.5.2.14901-1
CUBE : ISR 4451 isr4400-universalk9.03.16.05.S.155-3.S5-ext
PHONE : Cisco 8851 sip88xx.11-5-1-18
Thanks in advance,
