Wainwright, John wrote:
Paul,
So the UAC establishes the initial dialog with the media server via the
softswitch using the 183 response and then when the softswitch terminates
the 'real' call it will get a new SDP via either a 183 or 200 which it can
use for the dialog to the end user ? This avoids the use of the UPDATE
method. Have a read this right ?
Right. THe key to making this legal according to offer/answer is that
the answer for the 'real' call is on a different dialog than the one
with the media server.
It is just as if the call was sequentially forked, first to the media
server, and then to the real device. (And this isn't far from the truth.)
Paul
Thanks
John
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat
Sent: Friday, May 20, 2005 5:31 PM
To: Dale Worley
Cc: [email protected]
Subject: Re: [Sip-implementors] UPDATE or INVITE Replaces.
Dale,
Sounds like a pretty natural approach when the box in the middle is a
proxy, which most of us tend to think of as the *right* way. I suspect
that the way this is described, the softswitch wants to be a B2BUA.
ALso, as John said in a later reply, the softswitch interface to the
Media Server might not be sip.
Nevertheless, there is an aspect to what you suggest that can still work
in this case, that makes things (arguably) simpler:
- the 183 establishes an early dialog with an offer1/answer1
- eventually, the call gets sent somewhere else. The responses
from there establish a *different* dialog. It is the responsibility
of the caller to realize what is going on and abandon the early
dialog when the the new one sends a 2xx response.
So all that the softswitch has to do is ensure that it uses a new to-tag
for communications relating to the ultimate call after the media server
is done. It can do that by acting as a proxy, or it can simply establish
a 2nd dialog back to the caller from its B2BUA.
Paul
Dale Worley wrote:
From: Wainwright, John
In particular I am thinking about UA-->softswitch-->Media Server
sequence which plays an announcement/collect a new DN from the UA
forwards this
info
to the softswitch ( in an application specific way ) who then sends
out an INVITE to the collected DN and UPDATES the initial UA with this
dialog information in order to connect the call. The initial UA would
be in an early media type state in effect waiting for the UPDATE from
the
softswitch.
That sequence seems excessively heavy-weight. What seems easier to me
is this sequence:
1. INVITE from UA to Softswitch.
2. INVITE from Softswitch to Media Server.
3. Media Server sends 183 back to UA to set up early dialog.
4. User sends information, Media Server collects and processes it to
determine required action.
5. Media Server sends 302 response to Softswitch, with:
Contact:
<where-ever-call-should-be-forwarded-to>;var=data;var=data;var=data
Where the "var=data" items are various bits of information provided to
the Softswitch by the Media Server.
6. Softswitch processes the "var=data" items, and forwards the INVITE
to the correct destination.
7. UA is ultimately connected to the destination, which establishes
media with the UA.
There doesn't seem to be any need to send an UPDATE, as long as the
Media Server is willing to retry the 183 a few times to allow for its
unreliability.
Dale
_______________________________________________
Sip-implementors mailing list [email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
