0

SIP Call Graph Diagram when Bug comes:

A = UAC
B = OpenSIPS
C = UAS

A ---------- INVITE ---------> B
A <-------- STATUS 100 TRYING ------- B
B ---------- INVITE ---------> C
B <-------- STATUS 100 TRYING --------- C
B <-------- STATUS 200 OK --------------- C
A <-------- STATUS 200 OK ------------- B
A ---------- CANCEL ------------------> B
A <-------- 200 CANCELING ----------- B
A ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B ---------- ACK ---------------> B
B <-------- STATUS 200 OK --------- C
A <-------- STATUS 200 OK --------- B
B <-------- STATUS 200 OK --------- C
A <-------- STATUS 200 OK --------- B
B <-------- STATUS 200 OK --------- C
A <-------- STATUS 200 OK --------- B
B <-------- STATUS 200 OK --------- C
B <-------- STATUS 200 OK --------- C
B <-------- STATUS 200 OK --------- C
B <-------- STATUS 200 OK --------- C

In my case problem is actually that the UAS never gets to know about the INVITE cancelled by the OpenSIP and it keeps on Pinging, but in the case where only 1XX (i.e provisional replies comes from UAS to OpenSIP it sends Cancel to UAS also). Is this the desired behaviour???????

From my point OpenSIP either should not send OK to UAC also when it is not sending CANCEL to UAS.

Steps to recreate issue :- I have used sipp to emulate the issue. The client xml for the sipp is as :-

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">

<scenario name="Basic Sipstone UAC">


  <send retrans="500">
    ;tag=[pid]SIPpTag00[call_number] To: [service] Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 ]]>
  </send>

  <recv response="100"
        optional="true">
  </recv>

  <recv response="180" optional="true">
  </recv>

  <recv response="183" optional="true">
  </recv>

  <recv response="200" rtd="true">
  </recv>


<send retrans="500">
Call-ID: [call_id] CSeq: [cseq] CANCEL Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 10 Content-Length: 0 ]]>
</send>

  <pause/>


  <send retrans="1">
    ;tag=[pid]SIPpTag00[call_number] To: [service] [peer_tag_param] Call-ID: [call_id] CSeq: 2 BYE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]]>
  </send>

  <recv response="200" crlf="true">
  </recv>

  <ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>


  <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>

</scenario>
Mani
  • 508
  • 1
  • 7
  • 18

1 Answers1

3

You can't cancel a call once it's been answered. The UAC A should be sending a BYE request instead of a CANCEL request.

B <-------- STATUS 200 OK --------------- C
A <-------- STATUS 200 OK ------------- B
A ---------- BYE ------------------> B
A <-------- 200 OK ----------- B

My guess is because OpenSIPS is receiving an invalid CANCEL request it does not bother forwarding it onto C the UAS which is fair enough.

Update:

From the SIP RFC:

The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). Therefore, if a UAC wishes to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2xx final response(s) to the INVITE, this means that a UAS accepted the invitation while the CANCEL was in progress. The UAC MAY continue with the sessions established by any 2xx responses, or MAY terminate them with BYE.

Community
  • 1
  • 1
sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • Thanks for the reply. But in my case what happened is: A dosen't received STATUS 200 OK for the INVITE So A has send CANCEL now (OK for INVITE from B -> A and CANCEL from A-> B are overlapping each other). After sending CANCEL it receives 200 OK for the INVITE sent to B and then it receives 200 OK for the CANCEL Request Also so A dosen't send any Bye message. Can you suggest how can i handle such situation in OpenSIP – Mani Aug 08 '13 at 11:54
  • 2
    In that case it would still be up to the UAC A to send a BYE request. The SIP standard states that if an OK response to an INVITE request is received after a call has been cancelled then the UAC should immediately send a BYE request. – sipsorcery Aug 08 '13 at 22:52
  • actually in my case the ACK of invite is sent by client A to B and after that it receives canceling OK 200 from B. Now in my view client should send bye but it is not doing that. I am not able to find on the internet in any official document that this should be the case so that i may verify it. Would you please guide me to the proper direction (means to any official document or so) so that i may verify it. – Mani Aug 12 '13 at 07:26
  • But you still can close transaction and send bye to other party if you receive cancel. Just need write that correctly in your dialplan. – arheops Aug 14 '13 at 14:25
  • I have a situation where A ----------- INVITE --------> B A <-------- 100 TRYING ------- B A <-------- 200 OK ----------- B A ------------ BYE ----------> B A 200 OK <---------- B A ------------ ACK ----------> B I have shown 200 OK for tbe BYE only half because it is not received by A. Here A continues with session establishment whereas it should hangup. Any idea why? Shouldn't A stop proceeding further with session establishment once it has sent BYE? – BTR Naidu May 20 '15 at 14:04
  • A should stop the session as soon as it sends the BYE. – sipsorcery May 20 '15 at 22:11