CUCM 8.6 Call fail with Bearer capability not implemented over sip trunk

[Ayodeji Okanlawon]

Guys,

I have an issue I am investigating and just want to know your thoughts..

Call flow...

CUBE---->CUCM---->UnityConnection----->CUCM----->GK------CUBE---SP

Incoming call flow is as described above...

I have attached a detail trace----all explained as the call flows. I have explained each step of the trace so its fairly easy to read.

The problem is this...

1. I get a disconnect cause of 65. Which is bearer capability not implemented..

******H245 error**********

13:22:20.211 |TranslateAndTransport(5526)::wait_SdlCloseInd - ERROR: H245 signaling connection aborted!!!, err=0|28,100,63,1.134678^172.15.10.30^*
13:22:20.211 |SIG-MediaCoordinator-wait_AuDisconnectRequest,CI(484551469,484551483),IFCreated(1,1)|28,100,13,231427.46^10.105.40.84^*

********h225 disconnect cause..65***************

13:22:20.210 |In  Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol|*^*^*
13:22:20.210 |Ie - Q931CauseIe -- IEData= 08 02 80 C1 |*^*^*
13:22:20.210 |Ie - H225UserUserIe -- IEData= 7E 00 22 05 25 80 06 00 08 91 4A 00 04 11 00 11 00 00 68 63 FA 79 8E D1 F7 DA 13 DA 1C 0A 69 28 4A 10 80 01 00 |*^*^*
13:22:20.210 |MMan_Id= 0. (iep=  0 dsl=  0 sapi=  0 ces= 0 IpAddr=5428690a IpPort=1720)|*^*^*
13:22:20.210 |IsdnMsgData1= 08 02 93 DA 5A 08 02 80 C1 7E 00 22 05 25 80 06 00 08 91 4A 00 04 11 00 11 00 00 68 63 FA 79 8E D1 F7 DA 13 DA 1C 0A 69 28 4A 10 80 01 00 |*^*^*
13:22:20.210 |value H323-UserInformation ::= |*^*^*
13:22:20.210 |{
  h323-uu-pdu
  {
    h323-message-body releaseComplete :
      {
        protocolIdentifier { 0 0 8 2250 0 4 },
        callIdentifier
        {
          guid '006863FA798ED1F7DA13DA1C0A69284A'H

2. Here is the ********sip disconnect cause..65***************

13:22:28.216 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.15.10.30 on port 5060 index 405
[513486,NET]
BYE sip:07567890000@172.15.10.30:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 172.15.10.20:5060;branch=z9hG4bK1e703211043c4
From: <sip:901788239701@172.15.10.20>;tag=74431~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-484551469
To: <sip:07567890000@172.15.10.30>;tag=23DEB814-124C
Date: Thu, 05 Apr 2012 12:22:19 GMT
Call-ID: C9635D99-7E5011E1-8741D34F-B20E53F1@172.15.10.30
User-Agent: Cisco-CUCM8.6
Max-Forwards: 70
CSeq: 105 BYE
Reason: Q.850;cause=65

3. During the call I see several mid-call invite with SDPs.

The call originally started with G729 codec, but mid-call Changes to G711ulaw...

I suppose this is where the problem is. It looks like the far end cant do G729 or G711ulaw. Would this be the reason why I get aleast 3 mid-call invite?

4. I know that bearer ca[ability can be a few things. But does this look more like the far end wants G711a. Bear in mind its an IPCC call center so I know for certain its G711. But looks like G711ulaw inst working.

Thanks for the ideas guys...

[moataz_mamdouh]

Hello

I think you need to change the  SIP session-expires from Advanced Service Parameter page in CUCM to its maximum value

[Ayodeji Okanlawon]

Moataz,

Thanks for your response. Why do you think I need to increase the session expire timers? Is there anything in the l ogs that suggests I need to do that?

[moataz_mamdouh]

Hi

becasue i think that CUCM is sending a mid-call Re-invite , so if you increase this timer to its maximum this will prevent CUCM from having to send the mid-call  re-invite into the call and will allow the call to stay  active.

Moataz Tolba

[Ayodeji Okanlawon]

Moataz,

This issue has been resolved.. It was a codec issue. I am not sure if I agree that the mid-call invite was due to the timers expring. Most of the time the mid-call invite was sent due to SDP changes such as cucm and the destination trying to negotiate new media capabilities..

[chinatyg317]

Hi aokanlawon,

I'm also encountered this fault.if it was codec issue,How to solve it ?

Thanks!

[Ayodeji Okanlawon]

Yiguang,

Can you describe your call flow?

Can you send a sh run of your config and a debug ccsip messages.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[chinatyg317]

Aokanlawon,

As shown in the following figure, Cisco IP phone (Ext: 8000) call the phone (Ext: 13203716888), the phone ringing normal,but the call will be disconnected if it is to answer.

CUCM:172.16.0.125

VOIP Gatrway:192.168.0.33

The following is a detailed call flow

126 6.600863000 172.16.0.125 192.168.0.33 SIP 934 Request: INVITE sip:013203716888@192.168.0.33:5060
127 6.602409000 172.16.0.254 172.16.0.125 ICMP 590 Redirect             (Redirect for host)
129 6.606959000 192.168.0.33 172.16.0.125 SIP 439 Status: 100 Trying
185 11.084708000 192.168.0.33 172.16.0.125 SIP 475 Status: 183 Session Progress
265 14.524966000 192.168.0.33 172.16.0.125 SIP 504 Status: 200 OK
266 14.529118000 172.16.0.125 192.168.0.33 SIP 445 Request: ACK sip:192.168.0.33:5060
267 14.530083000 172.16.0.125 192.168.0.33 SIP 518 Request: BYE sip:192.168.0.33:5060
268 14.530183000 172.16.0.254 172.16.0.125 ICMP 473 Redirect             (Redirect for host)
269 14.535508000 192.168.0.33 172.16.0.125 SIP 500 Status: 200 OK
57933 3523.826018000 172.16.0.125 192.168.0.33 SIP 935 Request: INVITE sip:013203716888@192.168.0.33:5060
57934 3523.831865000 192.168.0.33 172.16.0.125 SIP 440 Status: 100 Trying
58031 3529.351884000 192.168.0.33 172.16.0.125 SIP 476 Status: 183 Session Progress
58103 3531.872048000 192.168.0.33 172.16.0.125 SIP 505 Status: 200 OK
58104 3531.874452000 172.16.0.125 192.168.0.33 SIP 445 Request: ACK sip:192.168.0.33:5060
58105 3531.874720000 172.16.0.125 192.168.0.33 SIP 517 Request: BYE sip:192.168.0.33:5060
58106 3531.876107000 172.16.0.254 172.16.0.125 ICMP 473 Redirect             (Redirect for host)
58107 3531.880957000 192.168.0.33 172.16.0.125 SIP 499 Status: 200 OK
59404 3636.117665000 172.16.0.125 192.168.0.33 SIP 935 Request: INVITE sip:013203716888@192.168.0.33:5060
59405 3636.119270000 172.16.0.254 172.16.0.125 ICMP 590 Redirect             (Redirect for host)
59407 3636.124193000 192.168.0.33 172.16.0.125 SIP 440 Status: 100 Trying
59456 3640.986030000 192.168.0.33 172.16.0.125 SIP 476 Status: 183 Session Progress
59474 3642.691632000 192.168.0.33 172.16.0.125 SIP 505 Status: 200 OK
59475 3642.696072000 172.16.0.125 192.168.0.33 SIP 445 Request: ACK sip:192.168.0.33:5060
59476 3642.696581000 172.16.0.125 192.168.0.33 SIP 517 Request: BYE sip:192.168.0.33:5060
59477 3642.697824000 172.16.0.254 172.16.0.125 ICMP 473 Redirect             (Redirect for host)
59478 3642.704748000 192.168.0.33 172.16.0.125 SIP 499 Status: 200 OK

The following is the details of the "BYE" record

No.     Time           Source                Destination           Protocol Length Info
    267 14.530083000   172.16.0.125          192.168.0.33          SIP      518    Request: BYE sip:192.168.0.33:5060

Frame 267: 518 bytes on wire (4144 bits), 518 bytes captured (4144 bits) on interface 0
Ethernet II, Src: Vmware_48:53:69 (00:0c:29:48:53:69), Dst: Micro-St_f9:3e:17 (00:21:85:f9:3e:17)
Internet Protocol Version 4, Src: 172.16.0.125 (172.16.0.125), Dst: 192.168.0.33 (192.168.0.33)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: BYE sip:192.168.0.33:5060 SIP/2.0
        Method: BYE
        Request-URI: sip:192.168.0.33:5060
            Request-URI Host Part: 192.168.0.33
            Request-URI Host Port: 5060
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 172.16.0.125:5060;branch=z9hG4bK2a6ed3a8de
            Transport: UDP
            Sent-by Address: 172.16.0.125
            Sent-by port: 5060
            Branch: z9hG4bK2a6ed3a8de
        From: <8000>;tag=4264c374-5511-401f-a8ba-b5f34d7c68f4-31665682
        To: <013203716888>;tag=-B74581BD8D893025
        Date: Fri, 18 Jan 2013 05:56:23 GMT
        Call-ID: c87f6300-f81e407-13-7d0010ac@172.16.0.125
        User-Agent: Cisco-CUCM8.0
        Max-Forwards: 70
        P-Asserted-Identity: <8000>
        CSeq: 102 BYE
        Reason: Q.850;cause=65
            Reason Protocols: Q.850
            Cause: 65(0x41)[Bearer capability not implemented]
        Content-Length: 0

Thanks

[Ayodeji Okanlawon]

I am not sure where you too this logs from, but they dont look so right. Can you send a debug ccsip messages from the gateway (is this a cisco gateway?) If it is then that should be easy. If it is not, the only way I can help if for you to send CUCM traces

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[KY_]

Hi Dear

Can you please  somone explain what is the  bearer capability functionality exactly ?

Thanks

[yadwindersingh]

Hi,  We are also facing the same issue because of codec mismatch. 

Using codec g729 we are unable to make calls on some numbers. After checking call logs,  found bearer channel capabilities issue.  After that changed codec to g711 and we are able to make calls. 

Can you please let me know this issue in details and how can i rectify this issue on all phones without changing codecs. 

[jawad-ahmed]

I was able to fix Bearer capability not implemented error on PRI by adding the following command under voice-port.

#voice-port 2/0:23
#bearer-cap speech