Subject: Re: [MMUSIC] quick WGLC comment on ICE

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jun 2006 23:28:54 -0400

I don't think its contradictory at all. 3261 is pretty clear that what 
comes in a provisional response is the same as will come in a 2xx. Its 
just not reliable so you need to send the same answer in the 2xx. Thus, 
if a UAC should receive a 18x with an SDP, even if the 18x is 
unreliable, that constitutes an answer. Where in RFC 3261 does it say 
that whats in the 18x is NOT an answer? Indeed, according to this:

     o  If the initial offer is in an INVITE, the answer MUST be in a
          reliable non-failure message from UAS back to UAC which is
          correlated to that INVITE.  For this specification, that is
          only the final 2xx response to that INVITE.  That same exact
          answer MAY also be placed in any provisional responses sent
          prior to the answer.  The UAC MUST treat the first session
          description it receives as the answer, and MUST ignore any
          session descriptions in subsequent responses to the initial
          INVITE.

If you receive SDP in a 18x you won't even look at the SDP in the 2xx. 
Pretty clear thats the answer.

Given that the entirety of ICE talks about offers and answers only, and 
these are the only concepts in RFC 3264, I don't think it makes sense to 
move away from offer/answer terminology.

Thanks,
Jonathan R.

Rohan Mahy wrote:

> Hi,
> 
> ICE -08 still refers to offers and answers using terminology which 
> contradicts Section 13.2.1 of RFC3261.  By my reading, a session 
> description in an unreliable 18x is never an offer or an answer.  I 
> often describe this as an "early session description" or "courtesy SDP".
> 
> Several places in ICE (particularly Section 8) talk about performing ICE 
> operations once you receive an answer and refer to courtesy SDP as if it 
> is an answer.
> 
> For example, the current wording of Section 8 para 2:
> 
>    ICE requires a series of STUN-based connectivity checks to take place
>    between endpoints.  These checks start from the answerer on
>    generation of its answer, and start from the offerer when it receives
> 
>    the answer.  These checks can take time to complete, and as such, the
>    selection of messages to use with offers and answers can effect
>    perceived user latency.  Two latency of figures are of particular
> 
>    interest.  These are the post-pickup delay and the post-dial delay.
>    The post-pickup delay refers to the time between when a user "answers
>    the phone" and when any speech they utter can be delivered to the
> 
>    caller.  The post-dial delay refers to the time between when a user
>    enters the destination address for the user, and ringback begins as a
>    consequence of having succesfully started ringing the phone of the
> 
>    called party.
> 
> 
> and my proposed rewording:
> 
>    ICE requires a series of STUN-based connectivity checks to take place
>    between endpoints.  These checks start from the answerer on
>    generation of its first session description sent after the offer, 
> 
>    and start from the offerer when it receives
>    this first session description.  If this first message arrives in 
>    an unreliable message, the actual answer will arrive in the first reliable
>    message after the offer.  
> 
> 
>    STUN connectivity checks can take time to complete, and as such, the
>    number and timing of messages used for these checks can affect
>    perceived user latency.  Two latency figures are of particular
> 
>    interest.  These are the post-pickup delay and the post-dial delay.
>    The post-pickup delay refers to the time between when a user "answers
>    the phone" and when any speech they utter can be delivered to the
> 
>    caller.  The post-dial delay refers to the time between when a user
>    enters the destination address for the user, and ringback begins as a
>    consequence of having succesfully started ringing the phone of the
> 
>    called party.
> 
> and also in the 5th paragraph (currently):
> 
>    For this reason, if an offer is received in an INVITE request, the
>    UAS SHOULD immediately gather its candidates and then generate an
> 
>    answer in a provisional response.  When reliable provisional
>    responses are not used, the SDP in the provisional response is not
>    formally the answer; the value in the 200 OK is the actual answer.
>    However, RFC 3261 allows for SDP to appear in an unreliable
> 
>    provisional response, in which case its value has to be identical to
>    the value placed in the 200 OK.  Thus, we refer to the SDP in the
>    provisional response, even when unreliable, as the answer.  To deal
> 
>    with possible losses of the provisional response, it SHOULD be
>    retransmitted until some indication of receipt.  This indication can
>    either be through PRACK [11], or through the receipt of a STUN
>    Binding Request with a correct username and password.  Even if PRACK
> 
>    is not used, the provisional response SHOULD be retransmitted using
>    the exponential backoff described in [11].  Furthermore, once the
>    answer has been sent, the agent SHOULD begin its connectivity checks.
> 
>    Once a candidate reaches the Valid or Recv-Valid state, the UAS has a
>    known-valid path for media packets towards the UAC.  This point is
>    called the connected point in ICE.
> 
> and my proposed rewording:
> 
>    For this reason, if an offer is received in an INVITE request, the
>    UAS SHOULD immediately gather its candidates and then generate a
>    session descripition in a provisional response.  When reliable provisional
> 
>    responses are not used, the SDP in the provisional response is not
>    formally the answer; the value in the 200 OK is the actual answer.
>    However, RFC 3261 encourages implementors to include this "courtesy SDP" 
> 
>    in an unreliable
>    provisional response, in which case its value has to be identical to
>    the value placed in the 200 OK.  To deal
>    with possible losses, the provisional response SHOULD be
>    retransmitted until the UAS receives some indication of receipt.  This indication can
> 
>    either be through PRACK [11], or through the receipt of a STUN
>    Binding Request with a correct username and password.  Even if PRACK
>    is not used, the provisional response SHOULD be retransmitted using
> 
>    the exponential backoff described in [11].  Furthermore, once the
>    session description has been sent, the agent SHOULD begin its connectivity checks.
>    Once a candidate reaches the Valid or Recv-Valid state, the UAS has a
> 
>    known-valid path for media packets towards the UAC.  This point is
>    called the connected point in ICE.
> 
> I can propose specific text for the other usages if other agree this 
> needs to be changed.
> 
> thanks,
> -rohan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Anzile, Christophe" <[email-masked]>
Date: Wed, 21 Jun 2006 15:18:52 +0200

Hi all,

according
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-08.txt grammar
in chapter 12,

candidate-attribute   = "candidate" ":" candidate-id SP ...

however, all examples in chapter 11 do not use the ":" after candidate
keyword.

Example:
a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
should be:
a=candidate:$L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT

Please correct all the examples in order to conform to the standard SDP
syntax.

Christophe.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 04:27:49 -0400

Yes, this has been pointed out by others and I have already fixed it.

Thanks,
Jonathan R.

---

From: "Rohan Mahy" <[email-masked]>
Date: Sat, 24 Jun 2006 11:11:38 -0700

Hi Jonathan,

IMO, the fundamentally interesting attribute of an answer is that it
closes an offer/answer exchange.  Once the answer is received, either
side can send a new offer.  This is what makes it special.  Early SDP
in an unreliable 18x does not meet that test. Not until the REAL
answer arrives in the 200, can you update your offer/answer state
machine.

thanks,
-rohan