< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] How to answer a refer that was cancelled


On Mon, Sep 19, 2011 at 10:30 PM, Francis Joanis
<francis.joanis@xxxxxxxxx> wrote:
> On Mon, Sep 19, 2011 at 2:05 PM, SZOKOVACS Robert
> <rszokovacs@xxxxxxxxxxxxxxx> wrote:
>> Hi,
>>
>> I have a resiprocate-based server accessed by a not-resiprocate-based
>> client,
>> sending a REFER. Sometimes I encounter the following situation:
>> Since I do some async processing, it is possible that the client changes
>> it's
>> mind and cancels the REFER with expires=0.
>> And then I'm left with an unanswered request and I can't see a way around
>> it,
>> if I answer it from onExpiredByClient(), it will send the reply to the
>> second
>> REFER, the one with expires=0.
>> I suspect it's illegal for the client to send two messages in the same
>> subscription without waiting for an answer, but the client does it anyway,
>> so
>> I need to handle it.
>> Any advise?
>>
>> TIA
>>
>> br
>>
>> Szo
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel@xxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
> Hi Robert,
>
> I'm curious about the two REFER requests, are you receiving them as
> two separate transactions (for the same dialog)?
>
> Also, what would you want the behavior to be? I'm thinking it should
> only cancel the implied subscription in the REFER but leave the
> creation of the new invite (to the Refer-To target) as is. This seems
> to be what is suggested in RFC 3515, Section 2.4.4.
>
> So, I guess you should process the REFERs as usual: accept (202) the
> first one, let the DUM generate the sip frag NOTIFYs when it needs to
> (i.e. when you are sending the new call leg) then, upon receiving the
> REFER / Expires: 0, properly accept it then end the implied
> subscription (I'm rusty when it comes to handling subscriptions in
> DUM, but I can check tomorrow).
>
> If the peer UA doesn't want an implied subscription, you could also
> look at norefersub (RFC 4488). If, however, it wants to cancel the
> refer request (at the INVITE level) by having the new call leg
> cancelled, then I'll need to dig a bit deeper and get back to you :)
>
> Hope this helps,
> Francis
>
>

Please forgive the last sentence of my email, it is getting late
(although the sentence itself makes sense) :)

>
> If they are two different transactions, then both of them need to be replied 
> to.
>