OpenSIP not sending cancel to UAS in case it received 200 from UAC. Verified in 1.7.2 and 1.8

Question

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>

Answer 1

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.