I just went back and re-read the thread and realized I missed the part in the original question where Steven mentioned the 183 *was* sent unreliably. Apologies for the noise.
I tend to agree with Rob though: I don't believe 3261 actually forbids putting the offer in something other than the first reliable, non-error response. B Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. +44 20 7422 0439 +44 7835 136 187 [EMAIL PROTECTED] INVITE. TRYING. RINGING. OK. ACK. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 17 February 2005 12:25 To: Ben Gatewood Cc: Silvy Samuel; [email protected]; Steven Egan Subject: RE: [Sip-implementors] SDP in 183 non reliable response Hi, sending offer in RPR( Reliable provisional response ) is ok. But it is sending in non reliable provisional response. 3262 is talking about RPR Regards, Thangarajan. "Ben Gatewood" <[EMAIL PROTECTED] door.net> To "Silvy Samuel" 02/17/05 05:40 PM <[EMAIL PROTECTED]>, "Steven Egan" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> cc <[email protected]> Subject RE: [Sip-implementors] SDP in 183 non reliable response I think RFC 3262 covers this scenario. I know the AS5350 supports this standard which means that the 183 *is* a reliable response presuming the UAC indicates support for it in the initial INVITE (Supported: 100rel). 3261 defined 200 OK as the only reliable, non-error response but 3262 extended this to provisional responses (apart from 100 TRYING). The introduction to 3262 explicitly cites interoperation with the PSTN as part of the motivation behind this extension. HTH, B Ben Gatewood Lead Architect - IP Telephony Streamdoor Ltd. +44 20 7422 0439 +44 7835 136 187 [EMAIL PROTECTED] INVITE. TRYING. RINGING. OK. ACK. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Silvy Samuel Sent: 17 February 2005 11:58 To: Steven Egan; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] SDP in 183 non reliable response Hi Steven, Quoted from the RFC, which rules out offer in non-reliable response, without making any assumptions. "The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response." Regards, Silvy. ----- Original Message ----- From: "Steven Egan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Thursday, February 17, 2005 4:35 PM Subject: Re: [Sip-implementors] SDP in 183 non reliable response > Hi Thangarajan, > I think you are making assumptions based on what exists in the > specification... > > "(ie) you should not send the offer in non- reliable response" > > The specification does not categorically state that it is illegal to send > SDP in non reliable response. > The cisco AS5350 DOES send the same offer in the 200 OK also, and so until > the specification states that it is illegal to send an offer in a non > reliable response prior to the first reliable response, the AS5350 is not > breaking the protocol. > Admittedly this is a grey area, however it is best to stick to what is > stated in the spec rather than assumptions based on what is in the spec. > Cheers, > Steven > > > [EMAIL PROTECTED] wrote: >> >> >> >> Hi neeraj, >> >> Quoting from RFC 3261: >> >> 'If the INVITE does not contain a session description, the UAS is >> being asked to participate in a session, and the UAC has asked that >> the UAS provide the offer of the session. It MUST provide the offer >> in its first non-failure reliable message back to the UAC. In this >> specification, that is a 2xx response to the INVITE." >> >> It MUST provide the offer >> in its first non-failure reliable message back to the UAC >> >> >>>>>>>>>>.Offer MUST be in first non failure reliable message back to UAC. >> >> (ie) you should not send the offer in non- reliable response <<<<<<<<< >> >> so, the behavior of Cisco AS5350 is not as per the RFC 3261 >> >> >> Regards, >> Thangarajan. >> >> >> >> >> >> "Neeraj Jain" >> <[EMAIL PROTECTED] ackets.com> >> To <[EMAIL PROTECTED]>, 02/17/05 02:50 PM >> <[email protected]> cc Subject RE: [Sip-implementors] SDP >> in 183 non reliable response -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> [EMAIL PROTECTED] >> Sent: Thursday, February 17, 2005 2:39 PM >> To: [email protected] >> Subject: [Sip-implementors] SDP in 183 non reliable response >> >> >> >> >> >> Hi >> >> Quoting from RFC 3261: >> >> 'If the INVITE does not contain a session description, the UAS is >> being asked to participate in a session, and the UAC has asked that >> the UAS provide the offer of the session. It MUST provide the offer >> in its first non-failure reliable message back to the UAC. In this >> specification, that is a 2xx response to the INVITE." >> >> [Neeraj] This statement does NOT prohibit sending SDP (offer or answer) >> in non-reliable 1xx response in anyway. >> >> so, the behavior of Cisco AS5350 is not as per the RFC 3261, since it >> should not send the offer in 183 non reliable response. >> The UAC which is receiving the offer should discard it since offer is not >> as per the RFC 3261. >> >> But the problem is Cisco AS5350 can not send the offer in 200 ok, since >> it >> already sent the offer in 180, so what should be the behavior of UAC, >> when >> it did not receive any offer. >> >> INVITE ( with out offer ) >> UAC --------------------------------------> Cisco AS5350 >> >> 100 ( with out offer since not reliable) >> UAC < -------------------------------------- Cisco AS5350 >> >> 180 ( with out offer since not reliable) >> UAC < -------------------------------------- Cisco AS5350 >> >> 200 ( with out offer ) >> UAC < -------------------------------------- Cisco AS5350 >> >> ACK ( with out answer ) >> UAC -------------------------------------- > Cisco AS5350 >> >> >> >> Now the dialog will be establised with out any offer and answer. Whether >> this dialog is allowed ??? >> Whether RFC is telling anything about the dialog with out offer and >> answer. >> >> >> Regards, >> Thangarajan. >> >> >>>-----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 >> >> >> >> >> *********************** HSS-Private *********************** >> "DISCLAIMER: This message is proprietary to Hughes Software Systems >> Limited >> (HSS) 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. HSS 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] >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >> >> >> >> *********************** HSS-Private *********************** >> "DISCLAIMER: This message is proprietary to Hughes Software Systems >> Limited >> (HSS) 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. HSS 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] >> 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 _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ************************************************************************ ************** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&[EMAIL PROTECTED] or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com ************************************************************************ ************** ************************************************************************ ************** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&[EMAIL PROTECTED] or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com ************************************************************************ ************** *********************** HSS-Private *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) 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. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ************************************************************************ ************** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&[EMAIL PROTECTED] or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com ************************************************************************ ************** ************************************************************************************** Disclaimer: This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated. Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. For further assistance on email policy, or if you have received this email in error, please contact Streamdoor Group IT&C Helpdesk by email at it&[EMAIL PROTECTED] or write to Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY. www.streamdoor.com ************************************************************************************** _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
