The first, second and fourth scenarios are defined in the spec, so these are ok, however the third scenario is not clearly defined. I have only seen the third scenario when an invite (no offer) is sent to the cisco AS5350. You may see a different scenario if you send the invite (no offer) to a different endpoint (A SIP phone for instance).
Cheers,
Steven
Reinaldo Penno wrote:
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,
I think having offer in 180 and 200 , is not as per the offer/answerThe Cisco AS5350 sends the same SDP in the 183 and in the 200.
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
-- * 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
