[reSIProcate] replaces in inbound INVITE

[Derek MacDonald]

This one is a bit clunky; basically, the idea is if there isn't a valid
dialog to replace, the second member of the pair is the error code that
should be returned. 481 if no dialog was found, 486 based on the early-only
flag of the replaces header(not implemented yet).  See section 3 of the
replaces draft.

 

It is up to the app to terminate the dialog being replaced if there is a
match.

 

--Derek

 

  _____  

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Scott
Godin
Sent: Wednesday, October 06, 2004 1:27 PM
To: 'Derek at xten.com'
Cc: resiprocate-devel at list.sipfoundry.org
Subject: [reSIProcate] replaces in inbound INVITE

 

Hi Derek,

 

I see that the replaces header is handled, when a REFER is received and you
use makeInviteSessionFromRefer to create the outbound INVITE request.  But
how should an app use the DUM api to match an inbound INVITE that contains a
replaces header?  It looks like the DUM will create a new Invite Session for
this request, instead of "replacing" the old one.  If that's that case
should an app then call findInviteSession(CallId replaces) to get the
replaced InviteSessionHandle and handle the "replacement" from the within
the application only.

 

There is a comment in the findInviteSession function:

   //486/481 decision making logic where?  App may not wish to keep track of

   //invitesession state

 

Can you elaborate on it?  What is the purpose of the 2nd (int - 481) in the
pair that is returned.

 

Thanks for your help,

 

Scott

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