[reSIProcate] Cancel not honored by UAS.

[Scott Godin]

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
> that
> my 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/20200916/db76ec0c/attachment.htm>