Hi, I appologise, I meant to say that it is allowed to send an SDP OFFER in an unreliable 18x.
I know it's not said in the spec, but in this case I see no differene between an offer and an answer. An SDP is an SDP :) Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Steven Egan [mailto:[EMAIL PROTECTED] > Sent: 16. helmikuuta 2005 14:19 > To: Christer Holmberg (JO/LMF) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [email protected] > Subject: Re: [Sip-implementors] SDP in 183 non reliable response > > > Hi Christer, > What you have said is already clear from the specification, > however, I > am not refering to the SDP in 183 being sent as an answer. In the > scenario I am dealing with, no SDP is sent in the Invite in the first > place, so this is different from what is detailed in the > specification. > Cheers, > Steven > > Christer Holmberg (JO/LMF) wrote: > > 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 * > >> > >> > > -- > * 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
