Thanks Paul. My original scenario had an UPDATE message from P-->A after P had received the 180 from C. It now seems like although this would be valid it would also be redundant and instead A could just update his session data i.e. "c=" info etc. with the SDP from C either in the 18x or the 200 OK response. Thanks again. John
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 12:21 PM To: Wainwright, John Cc: Dale Worley; [email protected] Subject: Re: [Sip-implementors] UPDATE or INVITE Replaces. Wainwright, John wrote: > 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 ? yes > Without the different dialog > info would this scenario be invalid ? Yes Consider the following pure proxy forking scenario: A P B C | INVITE(sdp1) | | | |------------------>| INVITE(sdp1) | | | |------------------>| | | | 183(sdp2)to-tag=1 | | | 183(sdp2)to-tag=1 |<------------------| | |<------------------| | | | PRACK | | | |------------------>| PRACK | | | |------------------>| | | | 200 PRACK | | | 200 PRACK |<------------------| | |<------------------| | | |<=====================================>| | | | CANCEL | | | |------------------>| | | | 200 CANCEL | | | |<------------------| | | | 487 INVITE | | | |<------------------| | | | INVITE(sdp1) | | |------------------------->| | | 180 to-tag=2 | | |<-------------------------| | 180 to-tag=2 | | |<------------------| | | | 200 (sdp3) to-tag=2 | | |<-------------------------| | 200 (sdp3)to-tag=2| | |<------------------| | | ACK | | |------------------>| | | | ACK | | |<-------------------------| |<============================================>| A only sent an offer once, but that same offer was then sent to two different targets, and each sent an answer. A understands this because the to-tags in the responses containing the answers are different, indicating different dialogs. At the point where A receives the 200 response to the invite, with to-tag=2, it knows that is unrelated to the earlier dialog, and that it completes A's call attempt, so that is the one that A should be using. A doesn't have to cancel the other dialog, because the proxy does it. You can replace P with your B2BUA, and B with your media server, and have the result appear to A just as this call flow. BUT, I suspect there are many UAs out there that won't do the right ting with this call flow. Paul > 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
