Subject: [MMUSIC] SDP: rcvonly vs. sendonly

From: Holger Schmidt <[email-masked]>
Date: Wed, 29 Nov 2006 14:44:58 +0100

Hi all,

For me it is not quite clear how to interpret the a=recvonly and
a=sendonly SDP items in an RTSP response to a DESCRIBE request. The SDP
specification says that "this specifies that the tools should be started
in" the specified mode (recvonly or sendonly). However, in an asymmetric
scenario, where one entity is only sending and the other entity is only
receiving, it is not quite clear, which entity is meant by "the tools".
In RTSP, is "the tools" actually the RTSP server or the client? Is there
a general answer for this question for other protocols like SIP as well?

Is there anything more concrete about this issue, or is this a gap in
the SDP specification?

Thank you in advance.

Best regards,
Holger Schmidt

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

---

From: "Mark Handley" <[email-masked]>
Date: Wed, 29 Nov 2006 13:59:30 +0000

SDP was originally devised for multicast sessions, and this wording
reflects the original use.  If a session was recvonly, the multicast
participants who received the SDP description must not transmit data.
Obviously someone else will transmit data or the session will be
rather quiet.

In a unicast world, recvonly would typically indicate that the
recipient of the SDP description should not send data. Thus it would
apply to the RTSP client, as the SDP is sent from the server to the
client.

 - Mark

---

From: Holger Schmidt <[email-masked]>
Date: Wed, 29 Nov 2006 15:24:38 +0100

OK, but when having the Offerer/Answerer model in mind, I would expect
that the SDP describes the sending terminal's capabilities, right?

Best regards,
Holger

---

From: "Mark Handley" <[email-masked]>
Date: Wed, 29 Nov 2006 14:54:18 +0000

Yes, offer/answer inverted the original meaning of this.  According to RFC 3264:

   If the offerer wishes to only send media on a stream to its peer, it
   MUST mark the stream as sendonly with the "a=sendonly" attribute.  We
   refer to a stream as being marked with a certain direction if a
   direction attribute was present as either a media stream attribute or
   a session attribute.  If the offerer wishes to only receive media
   from its peer, it MUST mark the stream as recvonly.

So it's pretty clear if offer/answer is used, what the sense of
recvonly and sendonly are.

But I didn't think RTSP used offer/answer.  Or if it does now, I
missed it somewhere (I haven't been watching RTSP for a long time).

 - Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Nov 2006 17:03:23 +0100

> missed it somewhere (I haven't been watching RTSP for a long time).

Your correct, RTSP doesn't use offer/answer. There is no text in either 
RFC 2326 or draft-ietf-mmusic-rfc2326bis about the usage of recvonly. It 
is however included in some examples. To my reading of RFC 4566 is quite 
applicable in for a client receiving an a=recvonly line in the DESCRIBE 
response. However we probably should add a few line of text in regards 
to this.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Mark Handley" <[email-masked]>
Date: Wed, 29 Nov 2006 17:09:55 +0000

> response. However we probably should add a few line of text in regards

Agreed.  Unfortunately the examples in RFC 2326 and in rfc2326bis are
all of a multicast session, so the meaning is clear, but it's hard for
the reader to generalise to unicast from this.  Especially when
offer/answer does the opposite.  I wish the offer/answer spec hadn't
reversed this, but it's too late to change now.

For RTSP with unicast streams, I guess the main issue is not so much
what I intended when I wrote the SDP spec, but rather how current RTSP
implementations interpret this for unicast.

 - Mark

---

From: sunil bhargo <[email-masked]>
Date: Wed, 29 Nov 2006 16:58:15 -0800 (PST)

> missed it somewhere (I haven't been watching RTSP

       I think offer/answer were being discussed to
setup the RTSP streams/session some while ago when
RTSP and SIP combination was being discussed on this
list.

sunil bhargo

--- Magnus Westerlund <[email-masked]>
wrote:

> Mark Handley skrev:
> > Yes, offer/answer inverted the original meaning of
> this.  According to 
> > RFC 3264:
> > 

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Nov 2006 09:29:50 +0100

> RTSP and SIP combination was being discussed on this

Yes, in the context of doing media setup for RTSP controlled session 
using SIP one does end up using offer/answer (in the SIP part). However 
I don't think anyone has seriously argued for using offer/answer within 
RTSP.

Cheers

Magnus Westerlund

---

From: Holger Schmidt <[email-masked]>
Date: Thu, 30 Nov 2006 10:11:13 +0100

Hi,

> implementations interpret this for unicast.

I also agree.
To conclude it depends on using offer/answer which kind of semantics is
used for recvonly and sendonly.
Therefore, for clarifying I would appreciate this being explicitly
stated in some draft/rfc.

Holger