Subject: Re: [MMUSIC] 2 and a half SDP questions

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Sep 2010 17:11:02 +0200

Hi Rod,

I am a bit surprised that none has answered you before.

[email-masked] skrev 2010-06-28 19:06:
> Hi All
> 
> 1. Can someone clarify bandwidth modifier usage with slash notation. 
> i.e. AS and TIAS meaning at session and media level are well enough 
> specified, but SDP use of slash notation (IP/TTL/number_of_IPs, 
> port/number_of_ports) leads to an ambiguous situation. e.g. if an SDP 
> has 2 m= lines, the first has one port and one IP address (on a c= line) 
> but the second uses slash notation to specify two IP addresses then we 
> have 3 media flows. AS or TIAS at media level can specify bandwidth for 
> the first but for the 2nd and 3rd we have no specification text to 
> disambiguate! The most obvious option is to make the AS or TIAS specify 
> the maximum summation of the 2nd and 3rd flows. But is there any example 
> that deals with separately specifying bandwidth per flow of a media line?

In relation to the AS modifier I would like to quote the definition of it:

   AS The bandwidth is interpreted to be application specific (it will
      be the application's concept of maximum bandwidth).  Normally,
      this will coincide with what is set on the application's "maximum
      bandwidth" control if applicable.  For RTP-based applications, AS
      gives the RTP "session bandwidth" as defined in Section 6.2 of
      [19].

Thus, the definition is soft for a FLUTE session. IF the flute session
is divided over multiple streams you have to consider what you need. You
could define that AS applies for the full aggregate. I guess your need
is to indicate for each individual stream so that a client can decide
which to join. Thus I would consider the need to define a new SDP
bandwidth modifier that can take multiple values for each stream.

> 
> 2 (& 2.5). SDP provides guidence that session identifiers should not be 
> reused until 30 minutes after the session t= end time (and likewise from 
> before the start time). Is this considered best practice and widely 
> used? What is the underlying assumption on clock synchronisation between 
> source and sink? When the time is unbounded at start or end (i.e. = 0), 
> how - if at all - is that 30 minute guidance used?

Well, why would you reuse the session identifier in SDP at all? The
space is big enough that you can avoid collisions quite easily.
Secondly, unbounded has been frequently used in RTSP and also SIP. The
reasons it works well in these environments is that you have another
protocol controlling creation and termination of the actual delivery
sessions. In the case of flute you can't do that. You actually need to
include the time the session will be available.

When it comes to clock synchronization I would say that you will have to
assume reasonable clock sync. The t= value will really tell when the
sender will provide the session over a particular multicast group. Thus
assuming senders with NTP clients doesn't seem unreasonable. The
receivers will need to have reasonable clocks, a bit depending on the
session type, but descent wrist watch (within 1 min) or better sync.
Both entities really should run NTP clients to ensure that they keep
track of time well. I would included these assumptions in the
specification. I know that for MBMS in 3GPP we ensured that clients
could maintain a descent clock using simple NTP so that the SDP t=
values could be used for when to join multicast sessions and the timers
in FLUTE.

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]
----------------------------------------------------------------------