cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2388
Views
1
Helpful
12
Replies

voice-class codec command under voice register pool not take effect on SIP CME

Yan Tian
Level 1
Level 1

Hi team

I have below setup

9971 A (DN:4002)----SIP CME(10.68.233.72) -----CUBE(10.68.233.71) ------ CUCM (10.68.233.35) ----- 9971 B (DN:2220)

both CUBE and SIP CME will terminate Signaling and Media.

when 4002 call 2220, and 2220 pickup the call, CUBE will send 200 OK with below SDP to SIP CME:

m=audio 19400 RTP/AVP 116 101
c=IN IP4 10.68.233.71
a=rtpmap:116 iLBC/8000

And SIP CME will further send 200 OK with below SDP to 9971 A

m=audio 16928 RTP/AVP 0 101
c=IN IP4 10.68.233.72
a=rtpmap:0 PCMU/8000

I am just wondering why SIP CME change the original codec from ILBC (payload 116) to G.711ulaw (payload 0) on the call-leg between SIP CME and 9971 A (DN:4002), considering below configuration is already in place on SIP CME:

voice class codec 1
 codec preference 1 ilbc
 codec preference 2 g711ulaw

voice register pool  1       //9971 A (DN: 4002),  Pls Note that I have "no create profiile" and "create profile" many times to let the config take effect.
 voice-class codec 1

I strongly suspected that I might hit a defect / bug here. Attached is the full output of "debug ccsip message" output on SIP CME for this testing call and some key configs on SIP CME. I believe that this debug output is already enough to troubleshoot the specific codec negotiation mis-behaviour on call-leg between SIP CME and 9971 A (DN: 4002).

Pls help me out, thanks in advance.

1 Accepted Solution

Accepted Solutions

Yan,

First of all the reason we didn't see the 200 OK is because there was a jump in the traces..ie some were lost, debug ccsip all does this sometimes

You can see here that there was a jump from 005091 to 005223 ( so we lost a few logs there)

005090: Dec  9 12:34:28.323: //374/8D0699858263/SIP/Info/info/4096/ccsip_iwf_handle_generic_event:
005091: Dec  9 12:34:28.323: //374/8D0699858263/SIP/State/ccsip_cnfsm_debugs: IWF:cur_container:sip_iwf_sip_early_dialog_container, cur_state:S_SIP_IWF_SDP_RCVD_AWAIT_PEER_EVENT, event:E_SIP_IWF_EV_CALL_BRIDGE
005223: Dec  9 12:34:28.495: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created msg=0x1B16C6C0 with refCount = 1
005224: Dec  9 12:34:28.495: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created msg=0x1007B04 with refCount = 1

 

+++Log analysis+++

However from the logs I can see that ilbc was successfully negotiated. Although you need to fix a few things. eg the 200 Ok from CUBE doesn't contain any ptime, hence the default of 30ms was used. The INVITE from 9971 has a ptime of 20ms. This needs addressing.

+++ptime error+++

004769: Dec  9 12:34:28.315: //376/8D0699858263/SIP/Error/sipSPIDoIlbcCodecParamsNegotiation:
 No ptime attribute specified, using the default value of 30
 

+++ilbc codec negotiation+++


 04781: Dec  9 12:34:28.315: //376/8D0699858263/SIP/Info/notify/1/sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1
        payload_type=98, codec_bytes=50, mode=30codec=ilbc, dtmf_relay=rtp-nte
        stream_type=voice+dtmf (1), dest_ip_address=10.68.233.71, dest_port=24172


005026: Dec  9 12:34:28.319: //374/8D0699858263/SIP/Media/sipSPIDisplayStreamInfo:
          Stream type            : voice+dtmf
          Media line             : 1
          State                  : STREAM_ADDING (2)
          Stream address type    : 1
          Callid                 : 374
          Peer Callid            : 376
          RTP/SRTP Negotiated     : 8
          Negotiated Codec       : ilbc, bytes :50
          Nego. Codec payload    : 0 (tx), 0 (rx)
          Negotiated DTMF relay  : rtp-nte
          Negotiated NTE payload : 101 (tx), 101 (rx)
          Negotiated CN payload  : 0
          Media Srce Addr/Port   : [10.68.233.72]:16960
          Media Dest Addr/Port   : [10.68.179.137]:23684
   
    004980: Dec  9 12:34:28.319: //376/8D0699858263/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 2
Media Stream             : 1
Negotiated Codec         : ilbc
Negotiated Codec Bytes   : 50
Nego. Codec payload      : 98 (tx), 116 (rx)
Negotiated Dtmf-relay    : 6
Dtmf-relay Payload       : 101 (tx), 101 (rx)
Source IP Address (Media): 10.68.233.72
Source IP Port    (Media): 16964
Destn  IP Address (Media): 10.68.233.71
Destn  IP Port    (Media): 24172
Orig Destn IP Address:Port (Media): [ - ]:0

 

The question now is does CUBE send ilbc to ccme? Did you use the ? on the phone to check which codec is negotiated

Please rate all useful posts

View solution in original post

12 Replies 12

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Yan,

I have looked at the logs and indeed this looks very strange..

CCME receives 200 OK with ilbc as the offered codec and then it sends 200 OK with G711ulaw and also it changes the packetization time from default 20 to 30ms..

We will need to look at debug ccsip all to see why this is happening. We need to look at the SDP computation on CCME to know why its not sending ilbc to the phone..

Please do the ff

service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit

Then..

<Enable debugs, then test again.>

debug ccsip all

<Enable session capture to txt file in terminal program.> (such as Putty)


then do the ff:

terminal length 0
show logging

 

Please rate all useful posts

Hi Ayodeji,

Thanks for your reply. Attached is the output of debug ccsip all.

Strange that in the debug output, I can not find the the SIP 200 OK message sent by CME to 9971 Phone (DN: 4002).

Yan Tian

Yan,

First of all the reason we didn't see the 200 OK is because there was a jump in the traces..ie some were lost, debug ccsip all does this sometimes

You can see here that there was a jump from 005091 to 005223 ( so we lost a few logs there)

005090: Dec  9 12:34:28.323: //374/8D0699858263/SIP/Info/info/4096/ccsip_iwf_handle_generic_event:
005091: Dec  9 12:34:28.323: //374/8D0699858263/SIP/State/ccsip_cnfsm_debugs: IWF:cur_container:sip_iwf_sip_early_dialog_container, cur_state:S_SIP_IWF_SDP_RCVD_AWAIT_PEER_EVENT, event:E_SIP_IWF_EV_CALL_BRIDGE
005223: Dec  9 12:34:28.495: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created msg=0x1B16C6C0 with refCount = 1
005224: Dec  9 12:34:28.495: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: created msg=0x1007B04 with refCount = 1

 

+++Log analysis+++

However from the logs I can see that ilbc was successfully negotiated. Although you need to fix a few things. eg the 200 Ok from CUBE doesn't contain any ptime, hence the default of 30ms was used. The INVITE from 9971 has a ptime of 20ms. This needs addressing.

+++ptime error+++

004769: Dec  9 12:34:28.315: //376/8D0699858263/SIP/Error/sipSPIDoIlbcCodecParamsNegotiation:
 No ptime attribute specified, using the default value of 30
 

+++ilbc codec negotiation+++


 04781: Dec  9 12:34:28.315: //376/8D0699858263/SIP/Info/notify/1/sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1
        payload_type=98, codec_bytes=50, mode=30codec=ilbc, dtmf_relay=rtp-nte
        stream_type=voice+dtmf (1), dest_ip_address=10.68.233.71, dest_port=24172


005026: Dec  9 12:34:28.319: //374/8D0699858263/SIP/Media/sipSPIDisplayStreamInfo:
          Stream type            : voice+dtmf
          Media line             : 1
          State                  : STREAM_ADDING (2)
          Stream address type    : 1
          Callid                 : 374
          Peer Callid            : 376
          RTP/SRTP Negotiated     : 8
          Negotiated Codec       : ilbc, bytes :50
          Nego. Codec payload    : 0 (tx), 0 (rx)
          Negotiated DTMF relay  : rtp-nte
          Negotiated NTE payload : 101 (tx), 101 (rx)
          Negotiated CN payload  : 0
          Media Srce Addr/Port   : [10.68.233.72]:16960
          Media Dest Addr/Port   : [10.68.179.137]:23684
   
    004980: Dec  9 12:34:28.319: //376/8D0699858263/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 2
Media Stream             : 1
Negotiated Codec         : ilbc
Negotiated Codec Bytes   : 50
Nego. Codec payload      : 98 (tx), 116 (rx)
Negotiated Dtmf-relay    : 6
Dtmf-relay Payload       : 101 (tx), 101 (rx)
Source IP Address (Media): 10.68.233.72
Source IP Port    (Media): 16964
Destn  IP Address (Media): 10.68.233.71
Destn  IP Port    (Media): 24172
Orig Destn IP Address:Port (Media): [ - ]:0

 

The question now is does CUBE send ilbc to ccme? Did you use the ? on the phone to check which codec is negotiated

Please rate all useful posts

Hi Ayodeji,

I did check call statistics on 9971 (DN:4002) after call finished. it shows, g.711ulaw is used and received packet is 0..

what is your recommended action plan for me pls ? Thanks

Can you please send the sh run from CUBE and the debug ccsip messages..

 

Please rate all useful posts

Hi Ayodeji,

Pls give me some more time, I will provide you the info, stuck with work stuff.

Thanks for your patience.

Thanks for the update..

Can you change the packetization period on ilbc to 20ms using the command below..

voice class codec 1
 codec preference 1 ilbc packetization-period 20
 

Please also send the sh run of your ccme (attach here)

Please rate all useful posts

Hi Ayodeji,

Sorry for the delay and thanks for your hints.

"codec preference 1 ilbc mode 30" solves the problem, ILBC is now used on call leg between SIP CME and 9971 A.  

Thanks again for your help and reply.

Yan Tian

Glad to help. Please mark thread as answered so as to help others. Did you try using packetization period instead of frame size ?

Please rate all useful posts

Hi Ayodeji,

AFAIK, "codec preference 1 ilbc mode 30" aims to change packetization period to 30 msec. So, I was actually trying what you recommended and it fixed the problem.

Deleted

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: