Subject: RE: [Sipping] Re: psychic early media behavior

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 29 Jun 2006 13:46:40 -0500

Paul Kyzivat wrote:
...
> Is there a reason why it needs to be modified on the reverse path? If 
> all the modifications were done on the forward path then the 
> UAS and UAC 
> would at least have a common understanding.

Yes there is.  Local policy may be based on information returned in the same or a related dialog.  For example, policy may be based on the terminating domain identified in the Via header rather than the next hop.  The transitive trust model I can depend on in some private networks doesn't exist in the internet.  At most the header in the forward direction can indicate that the network may implement some early media policy and that you can make a request for early media if you want to. 

...
> We still need to resolve the issue of whether this header 
> violates the 
> rules for P-headers by altering standard behavior. This is a judgment 
> call whether anything about early media counts here.

Please show me any RFC that absolutely requires this behavior.  I can show you an informational RFC that clearly indicates that this is a matter of local policy.

> 	Paul

Richard

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Jun 2006 19:26:12 -0400

> Yes there is.  Local policy may be based on information returned in the same or a related dialog.  For example, policy may be based on the terminating domain identified in the Via header rather tha…

OK.

> Please show me any RFC that absolutely requires this behavior.  I can show you an informational RFC that clearly indicates that this is a matter of local policy.

Well, I think the most relevant reference is RFC 3264. It says:

    Once the offerer has sent the offer, it MUST be prepared to receive
    media for any recvonly streams described by that offer.  It MUST be
    prepared to send and receive media for any sendrecv streams in the
    offer, and send media for any sendonly streams in the offer (of
    course, it cannot actually send until the peer provides an answer
    with the needed address and port information).  In the case of RTP,
    even though it may receive media before the answer arrives, it will
    not be able to send RTCP receiver reports until the answer arrives.

...

    Once the answerer has sent the answer, it MUST be prepared to receive
    media for any recvonly streams described by that answer.  It MUST be
    prepared to send and receive media for any sendrecv streams in the
    answer, and it MAY send media immediately.  The answerer MUST be
    prepared to receive media for recvonly or sendrecv streams using any
    media formats listed for those streams in the answer, and it MAY send
    media immediately.

...

    When the offerer receives the answer, it MAY send media on the
    accepted stream(s) (assuming it is listed as sendrecv or recvonly in
    the answer).

Note that this is regarding an initial offer/answer, and is without 
regard to whether it is "early" or not.

RFC 3312 says:

    A user agent server that receives an offer with preconditions SHOULD
    NOT alert the user until all the mandatory preconditions are met;
...
    While session establishment is suspended, user agents SHOULD not send
    any data over any media stream.  In the case of RTP [6], neither RTP
    nor RTCP packets are sent.

RFC 4032 (which extends 3312) says:

    In addition to not alerting the user, each precondition type MUST
    define any extra actions UAs should perform or refrain from
    performing when session establishment is suspended.  The behavior of
    media streams during session suspension is therefore part of the
    definition of a particular precondition type.  Some precondition
    types may allow media streams to send and receive packets during
    session suspension; others may not.  Consequently, the following
    paragraph from RFC 3312 only applies to QoS preconditions:

       While session establishment is suspended, user agents SHOULD not
       send any data over any media stream.  In the case of RTP, neither
       RTP nor RTCP packets are sent.

    To clarify the previous paragraph, the control messages used to
    establish connections in connection-oriented transport protocols
    (e.g., TCP SYNs) are not affected by the previous rule.  So, user
    agents follow standard rules (e.g., the SDP 'setup' attribute [7]) to
    decide when to establish the connection, regardless of QoS
    preconditions.

draft-ietf-mmusic-connectivity-precon-02 defines a new connectivity 
precondition:

    ... An entity that wishes to
    delay session establishment or modification until media stream
    connectivity has been established uses this precondition-type in an
    offer.  When a mandatory connectivity precondition is received in an
    offer, session establishment or modification is delayed until the
    connectivity precondition has been met, i.e., media stream
    connectivity has been established in the desired direction(s).
...
    Media stream connectivity can be ascertained in a variety of ways.
    This document does not mandate any particular mechanism for doing so,
    however the appropriate machinery is likely to vary depending on the
    type of transport used for media carriage.  In order to comply with
    the intent of an endpoint requiring connectivity preconditions, the
    following general principles apply:

    o  The 3-way handshake connection establishment procedures of a
       reliable transport protocol such as TCP are usually adequate to
       demonstrate bi-directional connectivity (and hence "sendrecv"
       media capability).  Probe packets sent over the connection are
       generally not required to satisfy the precondition.
    o  A pure datagram transport such as UDP (whether carrying RTP or
       some other protocol) by itself provides no useful feedback about
       connectivity.  Hence, some sort of probe traffic is necessary to
       ascertain whether packets are being received successfully.

So, according to 3362 each side MAY begin sending as soon as it receives 
the offer or answer. 3312 and 4032 modify that and require that RTP 
media be delays until a QoS preconditions are clear.

And 4032, together with draft-ietf-mmusic-connectivity-precon-02 
introduces some new cases when data may have to be exchanged over the 
media stream before preconditions can be resolved and the call answered. 
In those cases, by definition early media is required.

Now I agree all this is circumstantial evidence. None of this says that 
media sent over an early media stream must arrive. But its clear that 
there are things that break when early media doesn't work.

This is why this is still a judgement call. I wish I was hearing more 
opinions here.

	Paul

---

From: [email-masked]
Date: Thu, 29 Jun 2006 21:54:53 -0400

From: Paul Kyzivat <[email-masked]>

   I wish I was hearing more opinions here.

Be careful what you wish for!

Let me first say that I'm sure that a bar BOF is called for, as I
don't think that we yet have a consensus on what the questions really
are.

Secondly, I think we're finally enunciating clearly that the fundamental
question is whether a plain-vanilla RFC 3261 system (UAs *and*
network) is required to pass early media.  If that is answered in the
affirmative, almost any system for regulating or reporting regulation
of early media is non-upward-compatible, and cannot be handled by a
P-header alone.

Finally, if we really have to, we can cobble together a solution that
is strictly RFC 3261 compliant, allows all the controls that TISPAN
could possibly want, and is sufficiently isolated from all current SIP
implementations that we do not have to vet it microscopically before
approving it as an RFC.  Viz.:

    Introduce an option tag, e.g., "controlled-early-media".  If a UA
    specifies "Supported: controlled-early-media", that UA will generate
    extension headers to control early media, and is prepared to interpret
    such headers that are received.

    If UA1 desires to use these headers, it will send
    requests/responses with "Supported: controlled-early-media" and
    extension headers.  If UA2 does not understand the extension, it
    will ignore the headers, and not send "Supported:
    controlled-early-media", which will allow UA1 to know that there
    is no early media control.  If UA2 understands the extension, it
    will send "Supported: controlled-early-media" and extension
    headers, and the UAs can negotiate early media usage.

    If UA1 *requires* these headers, it will send requests with "Require:
    controlled-early-media" (and "Supported:  controlled-early-media").
    If UA2 does not understand the extension, it will reject the request
    with 420 (Extension Not Understood).  If UA2 understands the
    extension, continue as above.

    If UA1 requires these headers, if it receives a request without
    "Supported: controlled-early-media", it will reject the request with
    421 (Extension Required).  If UA1 receives a request with "Supported:
    controlled-early-media", continue as above.

    [The above rules can be restricted to particular subsets of requests
    (e.g., INVITE), if those are all that need to be restricted.]

    If the network and/or proxies through which a request passes
    require these headers, 1) any entering requests that do not
    contain "Supported: controlled-early-media" are rejected with 421,
    and 2) any requests passed that do not contain "Require:
    controlled-early-media" have it added.

    (RFC 3261 permits a proxy to add headers (except those listed in
    section 19.1.5) to a request en route:  The proxy forwards the request
    to an integral UA, which responds with a 302 whose Contact is
    <...original-destination...?Require=controlled-early-media>.)

If two UAs wish to communicate, and at least one of them does not
understand controlled early media, and the network/proxies do not
require controlled early media, this mechanism allows them to
communicate just as before, and either UA that does understand
controlled early media knows that it cannot use that mechanism.

If a UA does not understand controlled early media, and the other UA
and/or the network/proxies require it, a connection attempt will fail
with 420 or 421, specifying that the lacking extension is
"controlled-early-media".  This is inherently ugly, but is unavoidable
if we are going to satisfy TISPAN's requirement at all, but not have
RFC 3261-only UAs experience early media failures that they are not
notified of.

The extension headers only have to be understood by UAs that support
controlled early media, and networks/proxies that desire to understand
them.  So implementors of all other SIP agents can safely ignore their
definitions, regardless of how perverse they are.  This should allow
advancement of any proposal that TISPAN wants to an RFC relatively
quickly.

Dale