[reSIProcate] Cancel not honored by UAS.

[Jan Granqvist]

 During my testing, it looks like the issue is in method 'DialogSet::dispatch', lack of code when mState is 'Terminating'.
 . .   else if(mState == Terminating)   {      SharedPtr<SipMessage> response(new SipMessage);      mDum.makeResponse(*response, msg, 481);      mDum.send(response);      return;   }
/Janne

    Den onsdag 16 september 2020 22:54:50 CEST, Scott Godin <sgodin at sipspectrum.com> skrev:  
 
 Not sure offhand.  Maybe there is something we need to add to the ClientInviteSession state machine. We don't have a test case for that scenario in TFM dum right now, so it's possible DUM is mishandling subsequent UPDATE requests after sending a successful cancel.
Examining the logs, should help to determine if you can handle this outside DUM, or if we need DUM changes to handle it correctly.
Scott
On Wed, Sep 16, 2020 at 4:26 PM Jan Granqvist <jan_granqvist at yahoo.com> wrote:

Hi Scott,
Thanks for the reply.Yes, your assumption is correct, the 200 OK is for the CANCEL, sorry for that.
My dilemma for responding with a 481 is that I’m using DUM and it seems thatmy application does not get any notification of the occurrence.I might be doing something wrong using DUM.Or is it DUM that ought to handle the response?
TIA/Janne
Sent from my iPad

On 16 Sep 2020, at 18:01, Scott Godin <sgodin at sipspectrum.com> wrote:



I believe you should send a 481 response to the UPDATE requests.  I think you really need to send a fault report to the operator as well.  :)  
Note:  I am assuming the 200 OK below the cancel is a 200 OK for the cancel request, and not a 200 OK to the initial INVITE.
Scott
On Wed, Sep 16, 2020 at 5:15 AM Jan Granqvist via resiprocate-devel <resiprocate-devel at resiprocate.org> wrote:




---------- Forwarded message ----------
From: Jan Granqvist <jan_granqvist at yahoo.com>
To: "resiprocate-devel at resiprocate.org" <resiprocate-devel at resiprocate.org>
Cc: Jan Granqvist <jan.granqvist at advoco.se>
Bcc: 
Date: Wed, 16 Sep 2020 08:32:27 +0000 (UTC)
Subject: Cancel not honored by UAS.
Hi all,
I ran into a call scenario which I don't know how to handle.In the below call scenario our UAC CANCELs the call, to which the operator responds with 200 OK.However, the operator does NOT honor it, but continues sending updates as if the CANCEL never occurred.
UAC                                          UAS(Sip trunk)|------------------INVITE(sdpA)-------------->||<------------------100 Trying----------------||<----------183 Session Progress(sdpB)--------||--------------------PRACK------------------->||<------------------200 OK--------------------||<-----------------UPDATE(sdpB')--------------||------------------200 OK(sdpA)-------------->||---------------------CANCEL----------------->|             <---- time lapse ---->|<--------------------200 OK------------------||<----------181 Call Is Being Forwarded-------||<----------------UPDATE(sdpB'')--------------||<----------------UPDATE(sdpB'')--------------||------------------100 Trying---------------->|
Is there anything I should/can do to handle this, other than sending a fault report to the operator?I was wondering if it should be prudent to respond with 481 Call Leg/Transaction Does Not Exist.
TIA/Janne



---------- Forwarded message ----------
From: Jan Granqvist via resiprocate-devel <resiprocate-devel at resiprocate.org>
To: "resiprocate-devel at resiprocate.org" <resiprocate-devel at resiprocate.org>
Cc: 
Bcc: 
Date: Wed, 16 Sep 2020 08:32:27 +0000 (UTC)
Subject: [reSIProcate] Cancel not honored by UAS.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel



  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20200918/9efc0b07/attachment.htm>