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

[Robert Szokovacs <rszokovacs@xxxxxxxxxxxxxxx>]

On 2011 September 21, Wednesday 16:34:42 you wrote:

Hello,

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

I will definately pressure the developer to fix his app, but I'd like to 
create a robust solution that can handle irregular clients as well :)

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

I'm afraid it's not like that:

(resiprocate 1.7) Dialog.cxx:549

                ServerSubscription* server = findMatchingServerSub(request);
                 ServerSubscriptionHandle serverHandle;
                  if (server)
                  {
                     serverHandle = server->getHandle();
                     server->dispatch(request);
                  }
                  else
                  {
                     server = makeServerSubscription(request);
                     mServerSubscriptions.push_back(server);
                     serverHandle = server->getHandle();
                     server->dispatch(request);
                  }

This will match the second request's subscription with the first one's, so 
when I reply to the cached ServerSubscriptionHandle, it will get the second 
one's CSeq, so this is no way to reply to the first request :(

br

Szo