Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Cannot interrupt a SIP call after 180 Ringing was sent

I work on a Cisco 2651 with a seemingly simple scenario and I can't progress.

There is an incoming call initiated on the ISDN network. The call is configured to be routed to a SIP dial peer and that dial peer talks to a homegrown SIP application. The scenario is very simple.

1. Gateway places an INVITE to the application.

2. The application responds with 180 Ringing.

3. Eventually the application cancels the call, e.g. with a 486 Busy Here response.

The problem is that after the application sends the 180 Ringing, the gateway refuses to accept the error response canceling the call. If I remove the 180 Response, the call is correctly canceled. If, however, the 180 Ringing is sent to the gateway before the error response, the call is never cancelled. I turned on a bunch of debug logs. Please, observe that the 180 Ringing message delivered to the gateway before the 486 Busy here has exactly the same transaction data. The 180 is accepted, the 486 is not.

*Mar 17 19:17:30.077: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

From: <sip:902079028151@10.1.4.5>;tag=56896ABF-25C6

To: <sip:200@10.1.9.101>

Call-Id: 73673FDA-391211D6-8CE2B6AA-5613AF35@10.1.4.5

Cseq: 101 INVITE

Timestamp: 1016392646

Contact: <sip:200@10.1.5.63:5560>

X-Targetleg: 2

Allow: INVITE

Allow-Events: talk

Content-Length: 0

Date: Mon, 09 Feb 2009 11:24:42 GMT

Via: SIP/2.0/UDP 10.1.4.5:5060;branch=z9hG4bK2BC779

*Mar 17 19:17:30.077: //3440/7362F86082D4/SIP/Info/ccsip_api_call_alert: SDP Bod

y either absent or ignored in 180 RINGING:- will wait for 200 OK to do negotiati

on.

*Mar 17 19:17:30.077: //3440/7362F86082D4/SIP/Info/HandleSIP1xxRinging: ccsip_ap

i_call_alert returned: SIP_SUCCESS

*Mar 17 19:17:30.077: //3440/7362F86082D4/SIP/State/sipSPIChangeState: 0x84DDA17

4 : State change from (STATE_RECD_PROCEEDING, SUBSTATE_NONE) to (STATE_RECD_PRO

CEEDING, SUBSTATE_NONE)

*Mar 17 19:17:30.986: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpSocketReads: Msg enque

ued for SPI with IP addr: 10.1.9.101:5060

*Mar 17 19:17:30.986: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewCo

nnMsg: context=0x00000000

*Mar 17 19:17:30.986: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIMatchRespToReqTran: Fail

ed Response check insippmh_get_resp_code

*Mar 17 19:17:30.990: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 486 Busy here

From: <sip:902079028151@10.1.4.5>;tag=56896ABF-25C6

To: <sip:200@10.1.9.101>

Call-Id: 73673FDA-391211D6-8CE2B6AA-5613AF35@10.1.4.5

Cseq: 101 INVITE

Timestamp: 1016392646

Contact: <sip:200@10.1.5.63:5560>

X-Targetleg: 2

Content-Length: 0

Date: Mon, 09 Feb 2009 11:24:43 GMT

Via: SIP/2.0/UDP 10.1.4.5:5060;branch=z9hG4bK2BC779

*Mar 17 19:17:30.990: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor: Cou

ld not find matching transaction for this response, Dropping it.

3 REPLIES
Community Member

Re: Cannot interrupt a SIP call after 180 Ringing was sent

Let me answer my own question. :-)

The gateway's behaviour seems to be erroneous if the 180/183 responses don't establish an early dialog. The To tag of the 180 Ringing response above has no tag, therefore it does not establish an early dialog. According to my reading of the specification, this is legal. In this case, however, the 4xx response arriving after the 180/183 response is rejected.

The solution is to create an early dialog (add a tag to the To header in the 180/183 response).

I also have soft phones that exhibit this behaviour and then it is not possible to hang up the call from the softphone if that is the called party.

I would say this is a standard compliance problem of the gateway.

Community Member

Old thread but it seems CUCM

Old thread but it seems CUCM shows similar behaviour;

 

When receiving a 486 busy here from a SIP IVR after 180 Ringing, CUCM will not keep hunting to the next destination in a Route List, so overflow cannot be configured. If anyone has any input (like a workaround) please shout, I have a TAC case opened and it seems a defect will be filed. CUCM version 9.1.

 

Isidro

Community Member

For future reference, that

For future reference, that was exactly the issue. Once 180 ringing was suppresed for busy calls by the 3rd party application, Route List will keep hunting to the next Route Group.

cheers

Isidro

712
Views
0
Helpful
3
Replies
CreatePlease to create content