Hello, I do not want to extend this subject more than it is needed, but I would like to summarize the scenarios if possible; since the processing of 183 messages + SDP is something of interest
Are these the possible scenarios? INVITE 183 200 ACK OFFER --- ANSWER --- OFFER ANSWER ANSWER --- --- OFFER OFFER ANSWER --- --- OFFER ANSWER Not counting reliable provisional messages. Thanks, Reinaldo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Thursday, February 17, 2005 8:35 AM To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] SDP in 183 non reliable response I read through this long thread. I'm not going to try to respond to every message - there are only a few points being made here, over and over, pro and con. David Monahan stated my position well. I'll make one point below. Paul [EMAIL PROTECTED] wrote: > > > > 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. The problem with this argument is that the offer/answer model is stated independently of how the offers and answers are conveyed. It simply says there are offers, and answers, that are matched in a certain way. The issue here is with how/where/when offers and answers are conveyed in sip. And 3261 is not explicit enough about how that mapping is done in this case. It is explicit about the case where the offer is in the invite. Then it is permissible to put sdp in an unreliable response, and then repeat it in the first reliable response. For purposes of mapping this onto the offer/answer protocol, the sdp in the unreliable 1xx and then in the 2xx are not different answers - there is only one answer. The way I think of this is that if there is sdp in the 1xx, it is not really an answer, but rather is a hint of the answer to come. If the recipient gets this (which isn't guaranteed since the message is unreliable), it can (optionally) jump the gun and treat this as the offer. But then it will have to ignore the real offer in the 2xx. The case where there is no offer in the invite *seems to be* analogous. While 3261 has no language encouraging this, neither does it forbid it. In this case, if there is sdp in an unreliable 1xx, it again can't formally be considered an offer. It again seems reasonable to consider it a hint of the offer to come in the 2xx. So again, putting the sdp both places does not mean that two offers are being sent. The recipient may just ignore the sdp in the 1xx and get the offer from the 2xx. Or potentially it could process the sdp in the 1xx as an early hint of the offer, and then ignore the sdp in subsequent 1xxs and the 2xx. Paul > 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 _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
