Subject: [MMUSIC] RTSP 2.0 SDP issue: Directionality attribute

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Mar 2013 19:12:52 -0400

WG,

Flemming has found an issue in Section D.1.5. This is that this section
actually redefined the default behavior of the a=sendrecv, a=recvonly,
a=sendonly. This is clearly unsuitable and I propose that we change the
current text:

D.1.5.  Directionality of media stream

   The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
   provide instructions about the direction the media streams flow
   within a session.  When using RTSP the SDP can be delivered to a
   client using either RTSP DESCRIBE or a number of RTSP external
   methods, like HTTP, FTP, and email.  Based on this the SDP applies to
   how the RTSP client will see the complete session.  Thus media
   streams delivered from the RTSP server to the client, would be given
   the "a=recvonly" attribute.

   The direction attributes are not commonly used in SDPs for RTSP, but
   may occur. "a=recvonly" in a SDP provided to the RTSP client MUST
   indicate that media delivery will only occur in the direction from
   the RTSP server to the client.  In SDP provided to the RTSP client
   that lacks any of the directionality attributes (a=recvonly,
   a=sendonly, a=sendrecv) MUST behave as if the "a=recvonly" attribute
   was received.  Note that this overrules the normal default rule
   defined in SDP[RFC4566].  The usage of "a=sendonly" or "a=sendrecv"
   is not defined, nor is the interpretation of SDP by other entities
   than the RTSP client.

To instead become:

D.1.5.  Directionality of media stream

   The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
   provide instructions about the direction the media streams flow
   within a session.  When using RTSP the SDP can be delivered to a
   client using either RTSP DESCRIBE or a number of RTSP external
   methods, like HTTP, FTP, and email.  Based on this the SDP applies to
   how the RTSP client will see the complete session.  Thus media
   streams delivered from the RTSP server to the client, would be given
   the "a=recvonly" attribute.

   "a=recvonly" in a SDP provided to the RTSP client indicates that
   media delivery will only occur in the direction from the RTSP server
   to the client.  In SDP provided to the RTSP client that lacks any of
   the directionality attributes (a=recvonly, a=sendonly, a=sendrecv)
   would be interpreated as having a=sendrecv.  At the time of writing
   there exist no RTSP mode suitable for media traffic in the direction
   from the RTSP client to the server.  Thus all RTSP SDP SHOULD have
   a=recvonly attribute when using the PLAY mode defined in this
   document.  If future modes are defined for media in client to server
   direction, then usage of a=sendonly, or a=sendrecv may become
   suitable to indicate intended media directions.  The usage of
   "a=sendonly" or "a=sendrecv" SHOULD then be well defined.

This means that we expect SDP files for RTSP 2.0 to do contain the
directionality attribute.

Please provide feedback on this proposal.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Sean Sheedy <[email-masked]>
Date: Fri, 15 Mar 2013 08:25:46 -0400

This change sounds good to me.  I would recommend changing "In SDP 
provided ..." to "SDP provided ...".

Sean

On 03/14/2013 07:12 PM, Magnus Westerlund wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--
Sean Sheedy
Staff System Software Engineer, Media and Communications Systems
[email-masked] | 503-495-9454 (Phone)
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Mar 2013 09:14:28 -0400

Thanks,

Change applied to source.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Mar 2013 10:31:17 -0400 (EDT)

> From: Magnus Westerlund <[email-masked]>
> 
>    "a=recvonly" in a SDP provided to the RTSP client MUST
>    the RTSP server to the client.

I know little about RTSP though I've worked with SIP a lot.  I think
you might want to flag this odd inconsistency between RTSP and SIP:

When SDP is used in offer-answer mode, the directionality attributes
indicate directionality *from the point of view of the sender of the
SDP*.  (RFC 3264 section 5.1) So a SIP offer containing "a=recvonly"
indicates that the offerer expects to *receive* media.

When SDP is used in session-announcement mode, the directionality
attributes indicate directionality *from the point of view of the
receiver of the SDP*.  (This is not stated directly in RFC 4566,
rather it says "a=recvonly: This specifies that the tools should be
started in receive-only mode where applicable." but eventually you can
track down that "the tools" means the receiver's device.)  So an RTSP
announcement containing "a=recvonly" indicates that the announcer
expects to *send* media.

This difference is not what I would have expected.  Initially, I
assumed the text in your draft had gotten the directions reversed
relative to reality.

You might want to mention this somewhere, e.g., after the first
paragraph of D.1.5, add the paragraph

    (Note that RTSP uses SDP in session-announcement mode [RFC 4566],
    in which the directionality attributes indicate the direction of
    media flow from the point view of the interpreter of the SDP.
    This contrasts with SDP in offer-answer mode [RFC 3264], in which
    the directionality attributes indicate the direction of media flow
    from the point of view of the generator of the SDP.)

Dale

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Mar 2013 20:15:29 +0100

Hi Dale,

You are correct that RTSP uses SDP with an different interpretation, the
interpretation that is common to usage in SAP, rather than the one in
O/A. I think you are correct that this should be pointed out, but
belongs in the introduction, rather than down in the definition,
although this appears to be the only section where it really matters.

I thus propose a more generic version of your text in the D. section:

   This appendix describes how an SDP file determines the operation of
   an RTSP session.  Thus, it is worth pointing out that the
   interpretation of the SDP is done in the context of the SDP receiver
   is the one being configured.  This is the same as in SAP [RFC2974],
   this differs from SDP Offer/Answer [RFC3264] where the SDP describes
   what the peer agent is ready to receive and willing to send.

Does this works for you?

Thanks

Magnus

-- 

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 19 Mar 2013 15:37:14 -0400 (EDT)

>    what the peer agent is ready to receive and willing to send.

I agree with the overall concept, but there are some edits that would
help:

There's some flaw in the wording around "of the SDP receiver is the
one".  Perhaps it was intended to be "... of the SDP receiver, which
is the one being configured."?

Strictly, in "the same as in SAP [RFC2974],", the final "," should be
";", as the two things being joined are complete sentences.

The final clause does not seem definite enough to me, as "the peer
agent" is used rather than "the agent sending the SDP".  I suppose
that is the meaning that it must have, but in many situations, "the
peer agent" is used to denote the agent at the *other end* of the
connection from the agent being described.  So I would say "where the
SDP describes what the agent sending it is ready to receive and
willing to send."

Dale

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Mar 2013 17:03:36 +0100

Dale,

Thanks for the input. I have tried to address your input in this version:

   This appendix describes how an SDP file determines the operation of
   an RTSP session.  Thus, it is worth pointing out that the
   interpretation of the SDP is done in the context of the SDP receiver,
   which is the one being configured.  This is the same as in SAP
   [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where the SDP
   describes what the agent providing the SDP is ready to receive and
   willing to send.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 Mar 2013 13:43:05 -0400 (EDT)

> Date: Fri, 22 Mar 2013 17:03:36 +0100

Sorry, I've dropped the ball on this.  Looking at this text, I'm
thinking that the "reversal" between SAP and offer/answer usage is not
stated as clearly as it could be.  How about copying the wording from
the second sentence into the third?

    This appendix describes how an SDP file determines the operation of
    an RTSP session.  Thus, it is worth pointing out that the
    interpretation of the SDP is done in the context of the SDP receiver,
    which is the one being configured.  This is the same as in SAP
    [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each
    SDP is interpreted in the context of the agent providing it.

Dale