Subject: [MBONED] mboned: multicast/{SSM} URLs...

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Nov 2007 16:04:10 -0800

Ok, too lazy to do a more exhaustive search on my own. Hopefully
some folks here will have the right pointers:

Overall: what's the status of using multicast addresses in URLs ?

Like: is there any rfc/draft that even describes this ? From quickly
checking the URL RFCs i couldn't find the work multicast in any
of them.

I know that some applications support eg:
  
  udp://<ip-multicast-group-address/

but is that actually defined anywhere ?

I have seen VLC also support SSM, so maybe the full "best practice" ? URL
format is:

  udp://{<srcip>@}<group-ip>{:port}/

right ? Which apps (beyond VLC) are known to support SSM here ?

Any cases where there is support for

  a) more than one source IP address with SSM

     (if not, then what would be a good way do do it ?
      udp://<srcip1>,<srcip2>@... ??? (or other character than ',' ? )
  
  b) Use of this scheme with other protocols but udp (rtp ? ...) ?
     (if so, which app, protocols are known ?)
  
  c) any support for stuff behind the final slash ? 

  d) any example of how one would for example support a single URL for
     two media (audio, video) with two different port numbers (as usual
     with at least a bunch of tools... ?

Would there be a better working group but mboned if one ultimately wanted
to standardize on such formats ?

Thanks
    Toerless

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

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 9 Nov 2007 16:55:35 -0800

>but is that actually defined anywhere ?

Not really.  It's certainly not defined by any IETF standard, and 
it's bad practice, in any case.  The problem with this is that the 
multicast address alone gives much too little information about the 
stream.  In particular, it says nothing about the codec(s) that the 
stream uses, and nothing about any out-of-band parameters that may 
need to be passed to the clients' decoder.  For some stream types - 
e.g., MPEG Transport Streams - you may be able to get away with 
knowing just the multicast address and port, but that's the 
exception, rather than the rule.

The standard (and preferred) way to describe stream information - 
including for multicast streams - is to use RTSP - i.e., using a 
"rtsp://" URL.  The server will then return a SDP description that 
contains not just the multicast address(es) and port(s) for the 
stream, but also other information (e.g.. codecs) that describes the 
stream.

(Contrary to widespread belief, RTSP is not just for unicast streams; 
it can also be used for a multicast stream.  See section 14.4 of the 
RTSP 1.0 specification (RFC 2326) for an example of this.)

>right ?

No, definitely wrong - for the same reasons as noted above.  The 
right way to describe a SSM stream is in a SDP description, using a 
"a=source-filter:" line.  See RFC 4570.

>Which apps (beyond VLC) are known to support SSM here ?

Note that both VLC *and* MPlayer - which use the "LIVE555 Streaming 
Media" libraries - can use "rtsp://" URLs for multicast streams, 
including those that are SSM.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 9 Nov 2007 16:55:35 -0800

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Nov 2007 18:33:34 -0800

> exception, rather than the rule.

Right. 

> stream, but also other information (e.g.. codecs) that describes the 

Sure. But that creates another candidate bottleneck with the introduction
of an rtsp server and bidirectional networks. Also increses channel
change etc.. if you start using the URLs in such a way.

Given all the crap i had to see being encoded in URLs on various web-pages
and CMS products, i would for fairness reasons insist on having that 
ability also for multicast ;-))

> RTSP 1.0 specification (RFC 2326) for an example of this.)

Sure.

> "a=source-filter:" line.  See RFC 4570.

But that's not the answer to the question ;-))

> including those that are SSM.

Seriously. What's wrong in encoding the little stuff needed, and i agree
it can be "a bit" (port numbers, codecs, ...) in a URL ? Why having to
force receivers for yet another TCP connection and SDP file parsing ?
Aka: What's better there beside "it's already defined" ?

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Nov 2007 18:33:34 -0800

Right. 

Sure.

Cheers
    Toerless

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 9 Nov 2007 22:44:17 -0800

>of an rtsp server and bidirectional networks.

OK, but alternatively, you could just create a SDP description as a 
local file (i.e., without getting it from a RTSP server), and read it 
using your media player client.  VLC supports this, and I think 
MPlayer does also.

>it can be "a bit" (port numbers, codecs, ...) in a URL ?

Feel free to define such an URL format, and get it adopted by the 
IETF.  (I'm not going to support any such URL format unless it's on 
the IETF standards track.)

>  Why having to

Parsing a SDP file is almost exactly the same as parsing a SDP 
descriptor that comes back in response to a RTSP "DESCRIBE".  I.e., 
the code is already there (in the "LIVE555 Streaming Media" 
libraries, and thus VLC and MPlayer).
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 9 Nov 2007 22:44:17 -0800

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 12:25:03 +0000

> On Fri, Nov 09, 2007 at 04:55:35PM -0800, Ross Finlayson wrote:
...
> Aka: What's better there beside "it's already defined" ?

Because "a bit" can be several kilobytes, depending on the codec,  
encryption, etc., and you really don't want all that coded into the  
URL. Plus, you often want some negotiation before allowing the user  
to join the session (to check that they've paid to view the content,  
for example).

If you need to negotiate, use RTSP as Ross suggests. Otherwise,  
reference an SDP file describing the session via HTTP, SAP, FLUTE, etc.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 12:25:03 +0000

...

-- 
Colin Perkins
http://csperkins.org/

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:23:38 -0800

> exception, rather than the rule.

Coming to think of it, is it not also a bad encoding if you need to
be able to know from a multicast session description more than the transport
layer address ? Wouldn't sufficiently self descriptive streams be
what you should ahve anyhow ? I mean it's not as if you could do negotiation
of encoding on a multicast session, right ?

In which cases for example do you need more than the transport layer
addressing to successfully decode a stream (that you do have codecs for) ?

I always thought that RTP does provide for exactly that: sufficient
headers to allow selection of the appropriate codecs.

Eg: If we would say that a URL encoding only session description is
to be used to simplify the requirements in signaling (no RTSP server
required, no SDP decoding required, etc.), and we would only allow
description of the transport layer str]
	helo=sj-iport-2.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqpOo-0006nb-La
	for [email-masked]; Sat, 10 Nov 2007 07:25:19 -0500
Date: Sat, 10 Nov 2007 04:23:38 -0800
From: Toerless Eckert <[email-masked]>
To: Ross Finlayson <[email-masked]>
Subject: Re: [MBONED] mboned: multicast/{SSM} URLs...
Cc: [email-masked]

> exception, rather than the rule.

Coming to think of it, is it not also a bad encoding if you need to
be able to know from a multicast session description more than the transport
layer address ? Wouldn't sufficiently self descriptive streams be
what you should ahve anyhow ? I mean it's not as if you could do negotiation
of encoding on a multicast session, right ?

In which cases for example do you need more than the transport layer
addressing to successfully decode a stream (that you do have codecs for) ?

I always thought that RTP does provide for exactly that: sufficient
headers to allow selection of the appropriate codecs.

Eg: If we would say that a URL encoding only session description is
to be used to simplify the requirements in signaling (no RTSP server
required, no SDP decoding required, etc.), and we would only allow
description of the transport layer stream, aka: IP src, dest, and port
numbers, can you then give an example what type of most-relevant 
audio/video streams stream this would not allow to receive and decode ?
   
   MPEG TS over UDP, no RTP with MPEG2 video/audio ?
   MPEG TS or PS over RTP with MPEG2/4 video/audio ?

what else ?

Cheers
    Toerless

eam, aka: IP src, dest, and port
numbers, can you then give an example what type of most-relevant 
audio/video streams stream this would not allow to receive and decode ?
   
   MPEG TS over UDP, no RTP with MPEG2 video/audio ?
   MPEG TS or PS over RTP with MPEG2/4 video/audio ?

what else ?

Cheers
    Toerless

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 12:25:03 +0000

...

-- 
Colin Perkins
http://csperkins.org/

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:23:38 -0800

what else ?

Cheers
    Toerless

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 12:25:03 +0000

...

-- 
Colin Perkins
http://csperkins.org/

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:23:38 -0800

what else ?

Cheers
    Toerless

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 12:29:49 +0000

On 10 Nov 2007, at 12:23, Toerless Eckert wrote:
> be able to know from a multicast session description more than the  
> transport layer address ? Wouldn't sufficiently self descriptive  
> streams be what you should ahve anyhow ? I mean it's not as if you  
> could do negotiation of encoding on a multicast session, right ?

Unless you need to authenticate the user...?

> headers to allow selection of the appropriate codecs.

No, we abandoned that policy in AVT at the Munich IETF meeting, when  
it became clear it was unworkable.

>    MPEG TS or PS over RTP with MPEG2/4 video/audio ?

It wouldn't allow you to decode any payload format standardised in  
the past decade or so, since they all rely on SDP (or some similar  
out of band channel).

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 12:29:49 +0000

-- 
Colin Perkins
http://csperkins.org/

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:45:38 -0800

> reference an SDP file describing the session via HTTP, SAP, FLUTE, etc.

Correct me if i am wrong, but isn't the mayority of unicast streaming
over the internet, eg: whenever i click on some video somewhere done
without SDP but just by pointing to a file object retrieved by HTTP ?
Isn't the 99% usage reason in the internet for additional signaling
like rtsp or mms in the internet just trick play for vod which isn't
applicable to multicast ?

Aka: Why then do we need to insist that the minimum complexity solution
for multicast needs this arbitrarily extensible description format SDP ? 

Yes, if you do need more info than transport layer info to successfully
decode, then i would agree that the URL might become easily too convoluted,
but i just don't understand that case i guess.

And yes, i am not considering encryption here, because there are often other
methods used to disseminate keys than RTSP/SDP. I am actually not aware of
any service that uses that scheme to disseminate keys - do you have an example ?

Last but not least: When you say checking for payment, do you refer
to the idea that first having to do rtsp before you get the session
information (via SDP) is a form of security against unsanctioned
reception of the content ??? I can not believe that that would be
an IETF security standards compliant approach, especially not if all you
need to know to "illegally" receive the content are effectively
the network layer addresses of the stream! The only thing i would
call this scheme (if no keys are included in the SDP) is a collaborative
means to count receivers. And for that i thought you might rather use
RTSP to achieve more scalability.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:45:38 -0800

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:47:40 -0800

> the past decade or so, since they all rely on SDP (or some similar  

So, does it allow to decode the ones i listed ?
(I thought MPEG4 was only standardized this decade ;-))

Can you give an example of the maybe most widely used payload format
that would not work ?

Thanks
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 04:47:40 -0800

Thanks
    Toerless

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 10 Nov 2007 08:07:34 -0500

> applicable to multicast ?

You have it backwards, I think. It's progressive download that is  
generally done by clicking on
http://<some file path>; streaming generally requires a SDP file or  
its equivalent.

In Apple Quicktime streaming, for example, there is an SDP file, you  
just don't see it at the point and click
level because it is pointed to by the link you are clicking on (the  
embedded html points
to a reference movie which points to the sdp file, or the embedded  
html points to a
reference movie which points to an rtsp server which serves the sdp  
file). Unicast and multicast
work the same way, BTW, and Real and WM are
similar. (My understanding of Flash streaming video support
is that their new H.264 support will involve an SDP file, but I still  
am not entirely sure what they
are doing, and would welcome insight here.)

You do not want to re-invent this wheel.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 10 Nov 2007 08:07:34 -0500

Regards
Marshall

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 05:32:36 -0800

> You do not want to re-invent this wheel.

Far from it, i just want to understand why this wheel has all these pink
striped spikes and figure out whether or not there are useful cases where
we could have simpler and faster wheels without all these add-ons.

I am still waiting for the most common example of information disseminated
in an SDP file beyond transport layer addresses that is necessary to
successfully decode a streaming multicast UDP/MPEG2, RTP/MPEG2/4 or for
that matter any other widely used data stream. Without encryption.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 10 Nov 2007 05:32:36 -0800

Cheers
    Toerless

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 13:36:20 +0000

On 10 Nov 2007, at 12:47, Toerless Eckert wrote:
>>> description of the transport layer stream, aka: IP src, dest, and  
>>> port numbers, can you then give an example what type of most- 
>>> relevant audio/video streams stream this would not allow to  
>>> receive and decode ?
>>>

Yes - MPEG TS video is one of the few video formats that can be  
decoded without additional information.

> (I thought MPEG4 was only standardized this decade ;-))

MPEG-4 elementary streams sent within RTP [RFC 3016, or RFC 3640]  
cannot be decoded without additional configuration data coded with SDP.

> Can you give an example of the maybe most widely used payload format

H.264

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 13:36:20 +0000

H.264

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 14:04:06 +0000

On 10 Nov 2007, at 13:32, Toerless Eckert wrote:

> striped spikes and figure out whether or not there are useful cases  
> where we could have simpler and faster wheels without all these add- 
> ons.
>
> I am still waiting for the most common example of information  
> disseminated in an SDP file beyond transport layer addresses that  
> is necessary to successfully decode a streaming multicast UDP/ 
> MPEG2, RTP/MPEG2/4 or for that matter any other widely used data  
> stream.

RFC 3640 ("RTP Payload Format for Transport of MPEG-4 Elementary  
Streams") defines the following SDP parameters which are specific to  
the codec, and are required to decode the stream:

	streamType
	profile-level-id
	config
	objectType
	constantSize
	constantDuration
	maxDisplacement
	de-interleaveBufferSize
	sizeLength
	indexLength
	indexDeltaLength
	CTSDeltaLength
	DTSDeltaLength
	randomAccessIndication
	streamStateIndication
	auxiliaryDataSizeLength

The RTP payload format for H.264 video defines 16 parameters that  
must be signalled in SDP [RFC 3984]. AMR audio [RFC 4867] requires 12  
parameters to be sent in the SDP. The overwhelming majority of other  
RTP payload formats also require SDP parameters.

> Without encryption.

- The mapping from RTP Payload Type number to payload type
- Bandwidth specifiers, to allow QoS reservations
- Times the session is active
- Metadata about the session (title, language, URL for more info, etc.)
- Codec packetisation interval
- Content disposition (main camera, sign language "subtitle", etc)
- Grouping information for streams (this is FEC for that, etc)

Do you need all of this for every stream? No, of course not. But  
enough of it is needed for every stream that just signalling the  
transport addresses is insufficient.

Can you build a (closed) system that maps a single RTP payload type  
value to a defined set of parameters, such that only the transport  
addresses are needed to decode the stream? Yes, but the result will  
be inflexible, and difficult to extend as new codecs are defined, new  
options are added to existing codecs, and new functionality is required.

I'm with Marshall on this: you do not want to reinvent this wheel.  
There's significant and non-obvious complexity which bites everyone  
who tries it. SDP is big, ugly, complex, and required for a reason.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sat, 10 Nov 2007 14:04:06 +0000

streamType
	profile-level-id
	config
	objectType
	constantSize
	constantDuration
	maxDisplacement
	de-interleaveBufferSize
	sizeLength
	indexLength
	indexDeltaLength
	CTSDeltaLength
	DTSDeltaLength
	randomAccessIndication
	streamStateIndication
	auxiliaryDataSizeLength

-- 
Colin Perkins
http://csperkins.org/

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 11 Nov 2007 17:32:34 -0500

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 

> > Can you give an example of the maybe most widely used payload format

Possibly, there's some confusion here.

When people refer to "MPEG-4" they usually mean *only* the H.264
compression algorithm, which is Part 10 of MPEG-4. And most often, that
codec is used over MPEG-2 TS transport.

So in fact, use of H.264 in a media stream *often*, or perhaps even
usually (but I'm not sure about that), should not require any additional
information sent.

If more info is required, I always thought that the combination of SAP
and SDP is what the "modern" solution was? No?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 11 Nov 2007 17:32:34 -0500

Bert

---

From: Colin Perkins <[email-masked]>
Date: Sun, 11 Nov 2007 22:56:52 +0000

On 11 Nov 2007, at 22:32, Manfredi, Albert E wrote:
...
> usually (but I'm not sure about that), should not require any  

Or the additional information is sent within the MPEG transport  
stream using the MPEG systems framework. That's one approach,  
certainly, but differs from the IETF model which has a separate  
signalling and media paths.

> and SDP is what the "modern" solution was? No?

SAP has some significant limitations, and isn't necessarily something  
I'd recommend. Either retrieve the SDP session description using HTTP  
or FLUTE, or use RTSP, depending on how much negotiation and/or  
session control you need.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Sun, 11 Nov 2007 22:56:52 +0000

-- 
Colin Perkins
http://csperkins.org/

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 11 Nov 2007 19:00:04 -0800

> signalling and media paths.

One of the problem of that IETF model is that as soon as you have
incongruency between the unicast and multicast paths, you will have
problem getting path-coupled path operations that need access to
some of the control information.

> session control you need.

SAP is not a good method of discovery because of the requirement
of doing interdomain ASM. But if you would simply use SAP inband to
the actual media stream (aka: on the same multicast tree just with a
different port number), potentially with caching/triggered resending of
the SAP session information from routers when branches are added, then it
could overcome that non-path-coupling of media and session information.
I just do not think anything like this has been defined.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 11 Nov 2007 19:00:04 -0800

Cheers
    Toerless

---

From: Colin Perkins <[email-masked]>
Date: Mon, 12 Nov 2007 08:28:22 +0000

> some of the control information.

That's a problem with unicast systems too, since the signalling and  
media often follow different paths. Take it to MMUSIC - you'll  
probably find people interested in working in this area.

> I just do not think anything like this has been defined.

The IMG work in MMUSIC was heading in that direction, but stalled.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 12 Nov 2007 08:28:22 +0000

-- 
Colin Perkins
http://csperkins.org/

---

From: Stig Venaas <[email-masked]>
Date: Tue, 13 Nov 2007 11:43:13 +0100

Colin Perkins wrote:
> media often follow different paths. Take it to MMUSIC - you'll probably
> find people interested in working in this area.
> 

This sounds like a great idea (in fact it did occur to me before I
read this). It's quite useful to be able to receive the SDP and the
content without having to do any unicast signalling to get the SDP,
in particular for things like satellite I would imagine.

Of course SAP with FLUTE would also be a possibility. It could also
be SSM where different content providers can send SAP on different SSM
channels.

It would be interesting to know why it stalled. Is it regarded as a
bad idea, or did the proponents lose interest or...

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 13 Nov 2007 11:43:13 +0100

Stig

---

From: Colin Perkins <[email-masked]>
Date: Wed, 14 Nov 2007 09:24:42 +0000

...
>>>>> If more info is required, I always thought that the combination  
>>>>> of SAP and SDP is what the "modern" solution was? No?
>>>>

Insufficient push from the proponents, primarily. I expect MMUSIC  
would be receptive to new work in the area, if there was someone  
willing to drive it.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 14 Nov 2007 09:24:42 +0000

...

-- 
Colin Perkins
http://csperkins.org/

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 17 Nov 2007 14:37:40 +0900 (JST)

> bad idea, or did the proponents lose interest or...

IMO, some conceptual discussion about IMG has done in MMUSIC. We have
two IMG requirement and framework RFCs.
Now, it may be a good idea to further discuss the session announcement
"architecture" or its "operational conditions/experiences" in MBONED.
I'd be willing to work for it, if the MBONED community thinks it's
beneficial.
Charter discussion might help defining the direction.
Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 17 Nov 2007 14:37:40 +0900 (JST)

---

From: Stig Venaas <[email-masked]>
Date: Sat, 17 Nov 2007 07:59:59 +0100

> I'd be willing to work for it, if the MBONED community thinks it's

Sounds like a good idea. I think many of us in MBONED (I'm certainly
one of them), have not followed the IMG work and would find this
useful. I think MBONED community would have interest and opinions on
this. Well, only speaking for myself, but think I'm not the only one.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sat, 17 Nov 2007 07:59:59 +0100

Stig