I agree with Shinji below. But there are three things going on in this
draft:
- collecting together and clarifying the rules as they are,
including various inferences that are not apparent to
all readers.
- best practices wneh sending messages.
If these best practices are followed, certain
problems are avoided
- best practices when receiving messages.
This helps address the problem situations that
may arise if the sender is doing something
*valid* but which does not follow the best
practices for sending.
Having a best practice for sending that avoids a problem doesn't
eliminate the value is documenting a best practice for coping with that
problem.
Thanks,
Paul
OKUMURA Shinji wrote:
Christer,
Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
Wed, 21 Apr 2010 13:55:15 +0200
Hi,
I understand that this is a very rare case,
A B
| |
|INVITE (offer) |
|================================>|
| 1xx-rel(answer)|
|<===========\ /=================|
| \/ |
| /\ 18x-norel(answer)|
|<===========/ \=================|
|PRACK |
|-------------------------------->|
| |
IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert
new offer into PRACK.
You now seem to be suggesting that an SDP answer can be
transported unreliably. I strongly disagree to such statement.
NO. An SDP answer transported unreliably is only a "preview" of
the true answer.
I know it well.
A copy of the SDP answer can be sent unreliably, and the UAC can
use it, but the "real" SDP answer must still be sent reliably.
Maybe "ignore" is the wrong wording. The UAC cannot ignore
the fact that the reliable response contains the SDP answer,
because THAT SDP finishes the offer/answer transaction,
but it does not need to parse it.
That's right. "ignore" confuse me. Another clarification is
necessary.
If 18x-norel has no SDP, this confusion can not be occured.
Because offer/answer rules are complicated enough,
somening unnecessary should not exist.
It's "Best" Current Practices, I think.
Regards,
Shinji
Regards,
Christer
To avoid this situation UAS should not ...
Regards,
Shinji
Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21
Apr 2010 12:23:39 +0200
Hi,
<Dean Willis hat on>
Offer/answer is a mess. Instead, let's regard media as an
application
on top of SIP, and use an Info Package for negotiating the
media. There
is no connection to the SIP transactions, which means we don't need
complicated rules on when and where to insert SDP, and we
don't need to
describe how offer/answer works for re-INVITEs etc.
<Dean Willis hat off>
I don't disagree with what people are saying, but trying to read it
>from a I-am-a-new-implementor-and-I-would-like-to-
get-it-right-from-the-beginning perspective I don't think
anything is
clarified. Eg. talking about that an SDP sent after the
answer would be
"missunderstood as a new offer"
is confusing. The important thing is not whether the UAS
includes the
UAS answer in subsequent responses or not, because the UAC
still has to
handle such situation.
What is important is that the UAS MUST NOT send a *new* offer.
Regards,
Christer
-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji
Sent: 21. huhtikuuta 2010 8:45
To: sipping@xxxxxxxx
Subject: Re: [Sipping] Is SDP in an unreliable response
"the answer" ???
Hi,
Hans Erik van Elburg <ietf.hanserik@xxxxxxxxx> Tue, 20 Apr 2010
21:53:17 +0200
On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <pkyzivat@xxxxxxxxx> wrote:
Here is my attempt at summarizing the discussion conclusions:
Normative things (stated or implied in existing RFCs):
- If the UAC sent an offer in the INVITE, then after it receives
SDP (the
answer) in a reliable response to the INVITE, any SDP in
subsequent responses to the INVITE MUST be ignored.
- Further, if SDP is received in an unreliable response to the
invite prior to receiving SDP in a reliable response, then it MUST
be treated as the answer for purposes of media processing, but not
for purposes of determining when another offer may be sent or received.
[HE] I miss what the UAC should do in this case for subsequent
responses, does the following hold as well:
"If the UAC sent an offer in the INVITE, then after it receives SDP
(the answer) in an unreliable response to the INVITE, any SDP in
subsequent responses to the INVITE MUST be ignored/granted/... ." ?
I agree. And it's certainly "ignored".
Regardless what the correct behaviour is, it is missing in
your summary.
- if the UAS receives an offer in the INVITE, it MUST NOT include
SDP in any response it sends until it has determined the intended
answer SDP to the offer.
- once the intended answer SDP is determined, it MUST be sent in a
reliable response to the INVITE. It MAY be sent in one or more
*preceding* unreliable provisional responses.
Non-normative, best practice suggestions:
- if the UAS receives an offer in the invite, once it has sent the
answer in a reliable response, it should not send any SDP in
subsequent responses to the INVITE.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
