Thanks for all your responses. On Tue, Oct 12, 2010 at 8:16 AM, SIP Satan <[email protected]> wrote:
> 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 >> > > -- Thanks & Regards Vijay Sukumaran Nair. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
