RE: [reSIProcate] replaces in inbound INVITE

[Scott Godin <slgodin@xxxxxxxxxxxx>]

Thanks Derek!

Note:  I just committed an implementation of most of the checks in section 3 of RFC3891.

 

---

From: Derek MacDonald [mailto:derek@xxxxxxxx]
Sent: Thursday, October 07, 2004 6:40 PM
To: 'Scott Godin'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] replaces in inbound INVITE

 

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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin
Sent: Wednesday, October 06, 2004 1:27 PM
To: 'Derek@xxxxxxxx'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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 2^nd (int - 481) in the pair that is returned.

 

Thanks for your help,

 

Scott