cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6684
Views
5
Helpful
11
Replies

SIP Client sends 'CANCEL' request

Hi

Im trying to establish a CUBE with SIP servers on 2 ends. CUBE receives call setup from one side, transcode it and then send invite to other side. After receiving "SIP/2.0 183 Session Progress" from the SIP Server, suddenly the CUBE send it cancel request "CANCEL sip:4444@8.8.8.8.8:5060 SIP/2.0".

SIP Server -----CUBE ----- SIP Server

I am trying to find why the client sends the CANCEL message (with Q.850 code 65)

Here is the abstract fron the debug:

CSeq: 101 INVITE
Contact: <sip:4444@8.8.8.2:5060>
Content-Length: 0


047759: Apr 12 15:25:41: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:4444@8.8.8.36:5060 SIP/2.0
Via: SIP/2.0/UDP 10.50.1.166:5060;branch=z9hG4bKAE814ED
From: <sip:5555@10.50.1.166>;tag=82C6FC-2498
To: <sip:4444@8.8.8.36>;tag=1554691992
Date: Fri, 12 Apr 2013 12:25:39 GMT
Call-ID: EB940A13-A2A211E2-B90DED1C-1AA30C06@10.50.1.166
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0


047760: Apr 12 15:25:41: //10740/6D63682E9EB6/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.50.1.166:5060;branch=z9hG4bKAE91786
From: <sip:5555@10.50.1.166>;tag=82CABC-269
To: <sip:4444@8.8.8.36>;tag=1360713795
Call-ID: EC26866B-A2A211E2-B913ED1C-1AA30C06@10.50.1.166
CSeq: 101 INVITE
Contact: <sip:4444@8.8.8.2:5060>
Record-Route: <sip:8.8.8.36;lr=on;did=71d.60046b02>
Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
Content-Type: application/sdp
Content-Length: 311

v=0
o=- 67371483 0 IN IP4 8.8.8.39
s=Cisco SDP 0
c=IN IP4 8.8.8.39
t=0 0
m=audio 19876 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
         
a=X-cpar: a=fmtp:100 192-194,200-202
a=X-cap: 2 image udptl t38

047761: Apr 12 15:25:42: //10740/6D63682E9EB6/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:4444@8.8.8.36:5060 SIP/2.0
Via: SIP/2.0/UDP 10.50.1.166:5060;branch=z9hG4bKAE91786
From: <sip:5555@10.50.1.166>;tag=82CABC-269
To: <sip:4444@8.8.8.36>
Date: Fri, 12 Apr 2013 12:25:40 GMT
Call-ID: EC26866B-A2A211E2-B913ED1C-1AA30C06@10.50.1.166
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1365769542
Reason: Q.850;cause=65
Content-Length: 0


047762: Apr 12 15:25:42: //10740/6D63682E9EB6/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 canceling
Via: SIP/2.0/UDP 10.50.1.166:5060;branch=z9hG4bKAE91786
From: <sip:5555@10.50.1.166>;tag=82CABC-269
To: <sip:4444@8.8.8.36>;tag=0b99f96261c51ead3d440137a16dff29-4176
Call-ID: EC26866B-A2A211E2-B913ED1C-1AA30C06@10.50.1.166
CSeq: 101 CANCEL
Content-Length: 0


047763: Apr 12 15:25:42: //10740/6D63682E9EB6/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 10.50.1.166:5060;branch=z9hG4bKAE91786
From: <sip:5555@10.50.1.166>;tag=82CABC-269
To: <sip:4444@8.8.8.36>;tag=1360713795
Call-ID: EC26866B-A2A211E2-B913ED1C-1AA30C06@10.50.1.166
CSeq: 101 INVITE
Contact: <sip:4444@8.8.8.2:5060>
Content-Length: 0

Please advise.

Saif

11 Replies 11

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

You need to send the full debug ccsip messages..We cant see the logs for the outbound leg of the call..The orginal invite is also incomplete

Please rate all useful posts

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

Please rate all useful posts

HI,

Here is the complete trace file attached.

Saif

Saif,

From these logs, what i can conclude is that this is not a SIP to SIP call. We do not see the INVITE from the other leg of the call..It looks like you are doing h323-sip

178000: Apr 14 08:22:24: //101233/6D63682E4DA1/SIP/Info/sipSPICodecTranscoder: Xcoder needed

also we can see that the SIP stack is saying that a xcoder is needed...So we need to see the other leg of the call to know whats going on..

Can you send the sh run of your gateway and since the inbound leg looks to be h323..we are going to need

debug voip capi inout

debug h225 asn1

debug h245 asn1

Please rate all useful posts

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

Please rate all useful posts

Hi,

Here is the debug after as per the given commands.

saif

Ok,

So here is whats going on...

+++++++CUBE sends a TCS to the far end advertising G711alaw+++++++++


279361: Apr 14 13:59:45: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
    {
      sequenceNumber 1
      protocolIdentifier { 0 0 8 245 0 7 }
      multiplexCapability h2250Capability :
  capabilityTable
      {

        {
          capabilityTableEntryNumber 34
          capability receiveRTPAudioTelephonyEventCapability :
          {
            dynamicRTPPayloadType 101
            audioTelephoneEvent "0-16"
          }
        },
        {
          capabilityTableEntryNumber 4
          capability receiveAudioCapability : g711Alaw64k : 20
        }

++++++++The far end sends its TCS advertsising G729 and G7231++++++++


279485: Apr 14 13:59:46: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
    {
      sequenceNumber 1
      protocolIdentifier { 0 0 8 245 0 8 }
      capabilityTable
      {

        {
          capabilityTableEntryNumber 1
          capability receiveAudioCapability : g729 : 2
        },
        {
          capabilityTableEntryNumber 2
          capability receiveAudioCapability : g7231 :
          {
            maxAl-sduAudioFrames 7
            silenceSuppression FALSE
          }
        },
        {
          capabilityTableEntryNumber 3
          capability receiveAudioCapability : g729AnnexA : 2

++++++++Then CUBE sends a TCS reject to the far end+++++++++


279487: Apr 14 13:59:46: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= response : terminalCapabilitySetReject :
    {
      sequenceNumber 1
      cause unspecified : NULL

++++++=CUBE then sends a release complete with cause code of 65+++++++++

79490: Apr 14 13:59:46: H225.0 OUTGOING PDU ::=

value H323_UserInformation ::=
    {
      h323-uu-pdu
      {
        h323-message-body releaseComplete :
        {
          protocolIdentifier { 0 0 8 2250 0 4 }
          callIdentifier
          {
            guid '6D63682E3332332D5BD552208730002C'H
          }
        }
        h245Tunneling TRUE
      }
    }

279491: Apr 14 13:59:46: H225.0 OUTGOING ENCODE BUFFER::= 2580060008914A0004110011006D63682E3332332D5BD552208730002C10800180
279492: Apr 14 13:59:46:
279493: Apr 14 13:59:46: //119970/6D63682E5BD5/CCAPI/cc_api_call_disconnected:
   Cause Value=65, Interface=0x137DCC70, Call Id=119970
279494: Apr 14 13:59:46: //119970/6D63682E5BD5/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=65, Retry Count=0)
279495: Apr 14 13:59:46: H225.0 OUTGOING PDU ::

This is consistent with what we see on the SIP leg..

You  need to ensure that the other leg of your call can support G711alaw or configure a xcoder on your CUBE

Please rate all useful posts

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

Please rate all useful posts

Hi

Thanks for your analysis but I have already configured the XCODER. They are CONNECTED as below:

Berlin-CME#sh sccp
SCCP Admin State: UP
Gateway Local Interface: GigabitEthernet0/1
        IPv4 Address: x.x.x.166
        Port Number: 2000
IP Precedence: 5
User Masked Codec list: None
Call Manager: x.x.x.166, Port Number: 2000
                Priority: N/A, Version: 7.0, Identifier: 1
                Trustpoint: N/A

Transcoding Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: x.x.x.166, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 8
Reported Max Streams: 60, Reported Max OOS Streams: 0
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30

Transcoding Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: x.x.x.166, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 9
Reported Max Streams: 356, Reported Max OOS Streams: 0
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30

Please send me your full config..Sh run

Please rate all useful posts

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

Please rate all useful posts

Here you go.

You need to re configure you system. The dial-peer that calls are matching on the inbound leg is dial-peer 2.. This dial-peer is configured for sip, however inbound calls to this dial-peer are using h323. Ensure that calls coming to this dial-peer are using sip or change the config on thei dial-peer to use h323 by removing the session sip protocol on it

Please rate all useful posts

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

Please rate all useful posts

This is all the debug I received using 'debug ccsip mess'

Saif

Sent from Cisco Technical Support iPad App

Try increasing the scroll back history of your terminal application, there should definitely be more debugging information associated with the call. The cause code 65 refers to a capability not implemented error but without the full trace we can't say what the issue is.

Sent from Cisco Technical Support iPad App