Hi, As Troy said, you can send the 18x for the announcement on a different SIP dialog than the 200. Then, as previously said, the responses are independent from each other, as far as the offer/answer state goes.
Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Uttam Kumar Sarkar [mailto:[EMAIL PROTECTED] > Sent: 16. helmikuuta 2005 16:06 > To: Christer Holmberg (JO/LMF); 'Steven Egan'; > [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip-implementors] SDP in 183 non reliable response > > > Christer, > You said "you can assume that the SDP will not change in any > additional 18x > (or 200) for the same dialog within the same transaction". > How about the scenario when announcement is played by media > server sent in > 183 and then the final response is sent from the phone which would be > different. > Thanks, > Uttam > > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 16, 2005 7:13 AM > To: 'Steven Egan'; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip-implementors] SDP in 183 non reliable response > > > > Hi, > > It is allowed to send an SDP answer an unreliable 18x. The > reason it's not > considered as a "valid answer" is because it's unreliable, so > if it gets > lost and a new offer is sent the whole offer/answer state > would get out of > synch. However, that doesn't mean that you can't use the SDP > you receive in > un unreliable 18x, und you can assume that the SDP will not > change in any > additional 18x (or 200) for the same dialog within the same > transaction. > > > Regards, > > Christer Holmberg > Ericsson Finland > > > > -----Original Message----- > > From: Steven Egan [mailto:[EMAIL PROTECTED] > > Sent: 16. helmikuuta 2005 11:35 > > To: [EMAIL PROTECTED] > > Cc: Christer Holmberg (JO/LMF); [EMAIL PROTECTED]; > [EMAIL PROTECTED]; > > [email protected] > > Subject: Re: [Sip-implementors] SDP in 183 non reliable response > > > > > > Hi Sayan, > > I am sending the Invite with no offer to a Cisco AS5350. It is the > > AS5350 that is sending back the 183 with SDP (I wouldn't > > refer to it as > > an offer per se, as it is not a reliable response). I have > > no control > > over how the 183 response is constructed, so I was looking to > > know if it > > is allowed to contain the SDP or not. I have not found > > anything in the > > documentation detailing this. What we are probably going to do is > > ignore the 183 SDP and wait for the SDP in the subsequent 200. > > Cheers, > > Steven > > > > [EMAIL PROTECTED] wrote: > > > Hi, > > > Bit confused, but how does this help? > > > As I understand the answer for the offer in the 18x (identical SDP > > > repeated in the 200), will be answered only in the ACK to > > the 200 OK. > > > So what's the point in doing an "early offer" in an 18x, as > > the offer > > > answer can only be completed when the 200 OK/ACK exchange > > takes place. > > > Does sending an offer in 18x helps in any specific call flow? > > > Just curious... > > > > > > Regards , > > > Sayan > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Christer > > > Holmberg (JO/LMF) > > > Sent: Wednesday, February 16, 2005 4:11 AM > > > To: 'Paul Kyzivat'; Bala Neelakantan > > > Cc: [email protected] > > > Subject: RE: [Sip-implementors] SDP in 183 non reliable response > > > > > > > > > Hi, > > > > > > To my understanding the same SDP shall be sent in all subsequent > > > provisional responses - no matter if they are sent reliably > > or not. You > > > can only have at most one offer/answer exchange per SIP > > transaction, so > > > once you've sent an offer (or answer, if the INVITE did contain an > > > offer) in 18x you can't send any more within that transaction. > > > > > > When it comes to forking, each dialog is handled > completely separate > > > from each other, ie the offer/answer "state" on one dialog is not > > > affected by other dialog. How the UAC then chooses which > dialogs to > > > accept/reject, and how to handle possible media received > > from multiple > > > UASs, is an implementation issue. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > >>-----Original Message----- > > >>From: [EMAIL PROTECTED] > > >>[mailto:[EMAIL PROTECTED] Behalf Of Paul > > >>Kyzivat > > >>Sent: 15. helmikuuta 2005 18:42 > > >>To: Bala Neelakantan > > >>Cc: [email protected] > > >>Subject: Re: [Sip-implementors] SDP in 183 non reliable response > > >> > > >> > > >> > > >> > > >>Bala Neelakantan wrote: > > >> > > >>>Paul, > > >>> > > >>>I agree that the same SDP should be sent in the subsequent > > >> > > >>non-reliable > > >> > > >>>response and also on the first Reliable response. > > >> > > >>I guess you are shifting from the subject of the original > > >>question, and > > >>discussing a "normal" invite that includes an offer. > > >> > > >> > > >>>What if the call is forked? In that case, there could > be multiple > > >>>provisional responses, each could be potentially different? > > >> > > >> How does the > > >> > > >>>UAC handle those? > > >> > > >>This has been well documented and discussed, though it can > > >>get complex. > > >> > > >>The response to each fork creates a separate dialog. It is up > > >>to the UAC > > >>to keep the different dialogs straight until one is > answered and the > > >>others are cancelled. > > >> > > >> Paul > > >> > > >> > > >>>Thanks, > > >>>Neel > > >>> > > >>>-----Original Message----- > > >>>From: [EMAIL PROTECTED] > > >>>[mailto:[EMAIL PROTECTED] On Behalf > > >> > > >>Of Paul Kyzivat > > >> > > >>>Sent: Tuesday, February 15, 2005 9:48 AM > > >>>To: Steven Egan > > >>>Cc: [email protected] > > >>>Subject: Re: [Sip-implementors] SDP in 183 non reliable response > > >>> > > >>>Well, I went back and read to refresh my memory. I agree > > >> > > >>that there is > > >> > > >>>nothing that suggests SDP might be in an unreliable > > >> > > >>provisional when > > >> > > >>>there had been no offer in the initial request. > > >>> > > >>>If it *was* there, you wouldn't be able to consider it a > > >> > > >>true offer, > > >> > > >>>since that must be in a reliable request or response. It > > >> > > >>would have to > > >> > > >>>be a hint of the offer to come. I don't find any language that > > >>>explicitly *prohibits* this. But in the absence of anything > > >> > > >>suggesting > > >> > > >>>it might be valid you would be best to not count on it. > > >>> > > >>> Paul > > >>> > > >>>Steven Egan wrote: > > >>> > > >>> > > >>>>Hi Paul, > > >>>>So you are saying that when an INVITE is sent with no > > >> > > >>offer, a 183 with > > >> > > >>>>SDP can be sent in response? > > >>>>Can you point me to where exactly this is documented > please, as my > > >>>>problem is I cannot find anything in RFC 3261 or any other > > >> > > >>documentation > > >> > > >>>>to confirm expected behaviour for the 183? > > >>>>Cheers, > > >>>>Steven > > >>>> > > >>>>Paul Kyzivat wrote: > > >>>> > > >>>> > > >>>> > > >>>>>Steven Egan wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Hi, > > >>>>>>Is it valid to include the SDP in a non reliable 183 sent > > >> > > >>in response > > >> > > >>>>>>to an Invite with no initial offer? > > >>>>>> > > >>>>>>It is ok to include the SDP in the 183 when the Invite > > >> > > >>contains the > > >> > > >>>>>>initial offer, but RFC 3261 is not clear as to whether > > >> > > >>the SDP can be > > >> > > >>>>>>included when no offer is included in the initial invite. > > >>>>> > > >>>>> > > >>>>> > > >>>>>I believe the answer is YES. The *same* SDP should be > sent in the > > >>>>>first reliable response. > > >>>>> > > >>>>> Paul > > >>>> > > >>>> > > >>>_______________________________________________ > > >>>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 > > > > > > > > > > > > Confidentiality Notice > > > > > > The information contained in this electronic message and > > any attachments to this message are intended > > > for the exclusive use of the addressee(s) and may contain > > confidential or privileged information. If > > > you are not the intended recipient, please notify the > > sender at Wipro or [EMAIL PROTECTED] immediately > > > and destroy all copies of this message and any attachments. > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [email protected] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > -- > > * Email: [EMAIL PROTECTED] * > > * WWW : www.aepona.com * > > * Phone: +44 (0)28 9026 9106 * > > * Fax : +44 (0)28 9026 9111 * > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > NOTE: This message, including any attachments, may include privileged, > confidential and/or inside information. Any distribution or > use of this > communication by anyone other than the intended recipient(s) > is strictly > prohibited and may be unlawful. If you are not the intended recipient, > please notify the sender by replying to this message and then > delete it from > your system. Thank you. > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
