>>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:ayyanar...@aricent.com] Sent: 11 October 2010 13:26 To: Attila Sipos; Vivek Batra; $...@r\/|>r!`/@; Vijay S Nair Cc: sip-implementors@lists.cs.columbia.edu 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:attila.si...@vegastream.com] Sent: Monday, October 11, 2010 5:07 PM To: Vivek Batra; Ayyanar P K; $...@r\/|>r!`/@; Vijay S Nair Cc: sip-implementors@lists.cs.columbia.edu 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: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Vivek Batra Sent: 11 October 2010 05:43 To: 'Ayyanar P K'; '$...@r\/|>r!`/@'; 'Vijay S Nair' Cc: sip-implementors@lists.cs.columbia.edu 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: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Ayyanar P K Sent: Monday, October 11, 2010 9:39 AM To: $...@r\/|>r!`/@; Vijay S Nair Cc: sip-implementors@lists.cs.columbia.edu 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: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of $...@r\/|>r!`/@ Sent: Monday, October 11, 2010 9:10 AM To: Vijay S Nair Cc: sip-implementors@lists.cs.columbia.edu 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 <vijaysukumarann...@gmail.com>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 > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- cheers!!!! sarvpriya http://sarvpriyak.blogspot.com/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu 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 Sip-implementors@lists.cs.columbia.edu 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 Sip-implementors@lists.cs.columbia.edu 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 Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
