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

sip call graph diagram when bug comes:

a = uac
b = opensips
c = uas

a ---------- invite ---------> b <-------- status 100 trying ------- b b ---------- invite ---------> c b <-------- status 100 trying --------- c b <-------- status 200 ok --------------- c <-------- status 200 ok ------------- b ---------- cancel ------------------> b <-------- 200 canceling ----------- 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 ---------- ack ---------------> b b <-------- status 200 ok --------- c <-------- status 200 ok --------- b b <-------- status 200 ok --------- c <-------- status 200 ok --------- b b <-------- status 200 ok --------- c <-------- 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 case problem uas never gets know invite cancelled opensip , keeps on pinging, in case 1xx (i.e provisional replies comes uas opensip sends cancel uas also). desired behaviour???????

from point opensip either should not send ok uac when not sending cancel uas.

steps recreate issue :- have used sipp emulate issue. client xml sipp :-

<?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> 

you can't cancel call once it's been answered. uac should sending bye request instead of cancel request.

b <-------- status 200 ok --------------- c <-------- status 200 ok ------------- b ---------- bye ------------------> b <-------- 200 ok ----------- b 

my guess because opensips receiving invalid cancel request not bother forwarding onto c uas fair enough.

update:

from sip rfc:

the impact of non-2xx final response invite on dialogs , sessions makes use of cancel attractive. cancel attempts force non-2xx response invite (in particular, 487). therefore, if uac wishes give on call attempt entirely, can send cancel. if invite results in 2xx final response(s) invite, means uas accepted invitation while cancel in progress. uac may continue sessions established 2xx responses, or may terminate them bye.