PRACK/200 OK can carry an SDP Offer answer session and it is very valid. This is a mechanism used to achive pre-condetion calls.
Regards -Satan On Mon, Oct 11, 2010 at 6:44 PM, Attila Sipos <[email protected]>wrote: > >>You said all SDP's must be same, I found a case where 183 SDP answer > and > >>200 OK SDP answer had different IP address for RTP Tx/Rx. The SDP is > not > >>same here right? > > > If PRACK (and forking) isn't used then I believe these answers should be > the same. > > It is possible that that 18x and 200 response are on different forks, > in which case the UAC is allowed to receive different SDP answers > on each of the forks. > > from: http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13 > Note that an offer/answer exchange initiated by an INVITE request > must follow exactly one of the patterns 1, 2, 3, 4. When an initial > INVITE causes multiple dialogs due to forking, an offer/answer > exchange is carried out independently in each distinct dialog. > > > >> and that is how it should happen if some announcement has to be > >>played in between before connecting the actual UAS. > > As I said above, forking is one way. > > But if no forking is taking place, then the change in media can be > performed using UPDATE for example. (it would seem that 18x with SDP > and PRACK with SDP would also be allowed but I remember seeing > some discussions a while ago that were unsure about this) > > > Regards > > Attila > > > > -----Original Message----- > From: Ayyanar P K [mailto:[email protected]] > Sent: 11 October 2010 13:26 > To: Attila Sipos; Vivek Batra; $...@r\/|>r!`/@; Vijay S Nair > Cc: [email protected] > Subject: RE: [Sip-implementors] UAS behavior : Multiple 18x messages > > You said all SDP's must be same, I found a case where 183 SDP answer and > 200 OK SDP answer had different IP address for RTP Tx/Rx. The SDP is not > same here right? and that is how it should happen if some announcement > has to be played in between before connecting the actual UAS. > > Thanks and Regards , > Ayyanar > > ESPEE IT Park,Plot No. 5, > Jawaharlal Nehru Salai, > Ekkattuthangal,Guindy > Main +91 44.4422.6279 > > > -----Original Message----- > From: Attila Sipos [mailto:[email protected]] > Sent: Monday, October 11, 2010 5:07 PM > To: Vivek Batra; Ayyanar P K; $...@r\/|>r!`/@; Vijay S Nair > Cc: [email protected] > Subject: RE: [Sip-implementors] UAS behavior : Multiple 18x messages > > Be careful because the behaviour in the described scenario is only > allowed if all the SDPs are the same. > > o If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE. > > > With the use of PRACK, the first reliable response becomes the first > response that requires PRACK. > > Once you start using PRACK to an SDP answer, the "200 OK" should not > have an SDP - if the "200 OK" does have an SDP, it should be ignored. > > Offer/Answer and PRACK (and UPDATE) are discussed in: > http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13 > > Regards, > > Attila > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Vivek Batra > Sent: 11 October 2010 05:43 > To: 'Ayyanar P K'; '$...@r\/|>r!`/@'; 'Vijay S Nair' > Cc: [email protected] > Subject: Re: [Sip-implementors] UAS behavior : Multiple 18x messages > > Hi, > > I have found it with several service providers which play announcement > (and hence send 183 Session Progress) to wait if actual called party is > busy and send 180 Ringing as soon as called party becomes available. > > Best Regards, > Vivek Batra > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Ayyanar P K > Sent: Monday, October 11, 2010 9:39 AM > To: $...@r\/|>r!`/@; Vijay S Nair > Cc: [email protected] > Subject: Re: [Sip-implementors] UAS behavior : Multiple 18x messages > > Hi, > > Is there a call flow like this ? > > ------- INVITE (OFFER)-------> > <------ 100 TRYING ----------- > <------ 183 PROGESS(ANSWER)--- > <------ 180 RINGING(ANSWER)--- > <------ 200 OK (ANSWER) ------ > ------- ACK -----------------> > > If so, in which scenario can we find a call flow like the above > mentioned. > > Thanks and Regards , > Ayyanar > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > $...@r\/|>r!`/@ > Sent: Monday, October 11, 2010 9:10 AM > To: Vijay S Nair > Cc: [email protected] > Subject: Re: [Sip-implementors] UAS behavior : Multiple 18x messages > > 1. Can UAS responds with multiple 18x for the INVITE request received? > YES. > 2. What should be the behavior of UA1 if it receives multiple 18x? > Create dialog if the response contains tag. Update your state machine. > 3. What should be the behavior of UA1 while receiving the second 18x > with SDP? > When the second 18x is rcvd with SDP, you should save the 18x as you > need it to send it back with your ACK. The UAS cannot send diff SDP in > the 2xx now. > > Also is there any particular reason that you are sending Invite WO > offer? > > On Sat, Oct 9, 2010 at 8:52 PM, Vijay S Nair > <[email protected]>wrote: > > > Hi All, > > > > Here is the scenario, > > > > UA1 > UA2 > > > > ----------------------------------INVITE w/o offer-----------------> > > > <----------------------------------100 > Try------------------------------ > > > > Connection / Port Not allocated > > <----------------------------------18x w/o offer > ---------------------- > > > > Connection / Port allocated <----------------------------------18x > > OFFER ----------------------- > > > > Here are my queries, > > > > 1. Can UAS responds with multiple 18x for the INVITE request received? > > 2. What should be the behavior of UA1 if it receives multiple 18x? > > 3. What should be the behavior of UA1 while receiving the second 18x > > with SDP? > > > > Please comment ... > > > > -- > > Thanks & Regards > > Vijay Sukumaran Nair. > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > -- > cheers!!!! > sarvpriya > http://sarvpriyak.blogspot.com/ > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are notified > that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. Aricent accepts no > responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > -- > This message has been scanned for viruses and dangerous content by Clean > Mail Gateway, and is believed to be clean. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are notified > that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. Aricent accepts no > responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
