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