According to RFC 3261 section 13.2.1 a UAC must treat the first session description it receives as the answer and must ignore session descriptions in subsequent responses to the initial INVITE. Relating this to your answer below seems to indicate that the initial 183 response completes the first offer/answer description and when the 'real' call is answered it will result in a second offer/answer scenario but it will be on a different dialog - due to the To tag ? - which makes this legal ? Without the different dialog info would this scenario be invalid ? John
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 8:55 AM To: Wainwright, John Cc: Dale Worley; [email protected] Subject: Re: [Sip-implementors] UPDATE or INVITE Replaces. 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
