Re: [reSIProcate] How to answer a refer that was cancelled
On Tue, Sep 20, 2011 at 4:01 AM, Robert Szokovacs
<rszokovacs@xxxxxxxxxxxxxxx> wrote:
> On 2011 September 20, Tuesday 04:30:12 you 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).
>
> The problem is that I can't accept the first one, because I need some async
> magic to determine if I can accept it or not, and while I'm doing it the
> second REFER arrives, and from that point whatever I do with the
> ServerSubscription, resip will generate a packet answering the second REFER. I
> can't find a way to send anything with the CSeq of the firts one.
>
> br
>
> Szo
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
Hi,
I wonder if you could send a 100 Trying right after getting the first
REFER and before starting your internal async. request?
ServerSubscription::send and Helper::makeResponse(..., 100) could be
used to do that.
That way, you will indicate to the peer UA that you are in the process
of handling the request and that might prevent it from transmitting
another REFER.
Also, by quickly looking at the code of Dialog.cxx/hxx, I don't think
the second REFER overwrites the first one: you could probably cache
the ServerSubscriptionHandle of the first one in your application
(i.e. your own AppDialogSet) or either try to find it using
Dialog::getServerSubscriptions. Maintaining the handles as such should
enable you to answer them independently.
Those are just ideas, I haven't tested any of this ;)
Let me know if this helps,
Francis