Subject: [MMUSIC] RTSP transport header support for layered media data in unicast

From: Mukul Purohit <[email-masked]>
Date: Thu, 25 Sep 2003 19:11:26 +0530

Hi all,

In the transport header, client can specify multiple transport-specs, 
BUT server must reply with exactly one transport-spec that was chosen by 
it (Sec 13.40 of the new draft, 12.39 for RFC2326).

Consider the scenario when for one media stream, if the server encodes 
media(signal) in multiple layers, and client wants to receive one or 
more of such layers in unicast (and not multicast, then the layers cud 
have been specified).
I assume that client will send single SETUP for one media stream, but it 
may need to open separate RTP channels (one channel coresponding to one 
RTP-RTCP unicast port pair) for each layer it wants to receive in unicast.

How can this be communicated to the server. And what should server reply?

mukul

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Sep 2003 15:55:29 +0200

Hi,

I think this is a shortcoming if it really is necessary. For multicast 
addresses the "layers" parameters exist. However that is not intended 
for unicast as it results in a number of consecutive addresses.

For a unicast application there is normally no need for layers as this 
type of scalability is more inefficient than to actually switch to the 
different rates. Based on the restrictions for layered encodings that 
they should share SSRC space there is clear that the only available 
multiplexing for unicast is ports. Therefore there seem to be need to 
have an explicit signal telling client and server that media should be 
delivered on different ports for the given number of layers. I would 
guess that using the new "dst_addr" parameter to allow specifying 
different address ports for each layer is to prefer over consecutive ports.

If you have real need for this, please propose a solution to the list.

Best Regards

Magnus

-- 

Magnus Westerlund

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: Mukul Purohit <[email-masked]>
Date: Fri, 26 Sep 2003 19:35:08 +0530

Hi all
> for unicast as it results in a number of consecutive addresses.
Aggreed that it was not intended.

> different rates.
There should be no need indeed. But if the streaming server has its 
media encoded in layers ONLY and a client requests for that media in 
unicast mode, then what will be the behaviour of server?

Assuming that client has enough bandwidth to receive that data in 
separate unicast channels but its ISP does not support multicast mode 
for transportation. In that case how can client receive all the layers?

> Based on the restrictions for layered encodings that 
will try for sure.

thanks and regards
mukul

>> BUT server must reply with exactly one transport-spec that was chosen 
>> by it (Sec 13.40 of the new draft, 12.39 for RFC2326).
>>
>> I assume that client will send single SETUP for one media stream, but 
>> it may need to open separate RTP channels (one channel coresponding to 
>> one RTP-RTCP unicast port pair) for each layer it wants to receive in 
>> unicast.
>>