The spec says the offer MUST be in the INVITE or the first reliable non-failure message. It does NOT say that it can ONLY be in the INVITE or the first reliable non-failure message. There's a difference.
- rob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 17, 2005 5:28 AM To: David Monahan Cc: [email protected] Subject: Re: [Sip-implementors] SDP in 183 non reliable response Hi David, >> The Cisco AS5350 sends the same SDP in the 183 and in the 200. I think having offer in 180 and 200 , is not as per the offer/answer model Since if you sent the offer, u can not send it again. u can send second offer only after getting answer. Section 13.2.1 of RFC3261 also says, "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." The offer should be in first reliable non-failure message, so it can not be non reliable response like 183. so Cisco AS5350 is not as per RFC 3261. Regards, Thangarajan. David Monahan <[EMAIL PROTECTED] pona.com> To [EMAIL PROTECTED] 02/17/05 04:38 PM cc [email protected] Subject Re: [Sip-implementors] SDP in 183 non reliable response Thangarajan, The Cisco AS5350 sends the same SDP in the 183 and in the 200. The actual offer is in the 200 as this is transmitted reliably. The original question was if there is any issue with sending the same SDP in a non-reliable 183. IF the offer had been in the INVITE, RFC3261 allows the same SDP (answer) to be sent in a 1xx and in the 200 (it MUST be in the 200). There is no corresponding text for SDP in 1xx when the offer is not in the INVITE. However it is not explicitly forbidden. Section 13.2.1 of RFC3261 also says, "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." Your example was the scenario where there is no SDP in the 200. I would have expected that the treatment would be the same whether the offer or the answer was expected in the 200. Regards, David [EMAIL PROTECTED] wrote: > > > > 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." > > 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. *********************** 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 _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
