[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] Is SDP in an unreliable response "the answer" ???



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

[IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

Add to Google Powered by Linux