Subject: [MMUSIC] quick WGLC comment on ICE

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 26 Apr 2006 13:53:26 -0700

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