| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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 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 |