Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-20.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 3 Oct 2004 17:16:02 +0100

Hi,

On 27 Sep 2004, at 13:18, sunil bhargo wrote:
>     Doubts regarding the following sections :-
>
> 1.
> "an SDP parser MUST completely ignore any session
> description that contains a type letter that it does
> not understand"
>
>        Isn't the word MUST having very strong
> implications which might not be necessary. For example
> intermediate SDP parsers between the client and server
> if everything that is not understood is rejected then
> it might be problem. First thing that comes to mind
> are the proxies(caching or dumb) they would have to
> deny the service instead of proxying the presentation.

True.

>      But somewhere else we mention as well
> "An SDP parser MUST ignore any attribute it doesn't
> understand."
>      So do we mean to say that any type other than
> attribute if not understood then deny service or do we
> mean something else.

Correct. SDP is extended via attributes and it's likely that an 
attribute is not understood (and therefore ignored). New type letters 
are rarely if ever defined (none have been defined to date), so the 
correct response to them is to discard the session description.

> 2. bwtype has missing RR and RS in section 5.8 or are
> these intentionally missing.

This is intentional, since they're defined elsewhere (in the referenced 
drafts).

Colin

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 3 Oct 2004 17:20:03 +0100

I'm not sure I understand your question. For a layered encoding, "b=AS" 
would specify the bandwidth of the entire layered stream.

Colin

On 29 Sep 2004, at 11:25, sunil bhargo wrote:

> Hi,
>          If the presentation is encoded into number of
> streams(MBR) one expects to see equivalent number of
> m= sections if that is so then how can multiple
> streams refer to the same m= section as implied below
> :-
>
>       "For applications where hierarchically encoded
> streams are being sent to a unicast address, it may be
> necessary to specify multiple transport ports.  This
> is done using a similar notation to that used for IP
> multicast addresses in the "c=" field:
> m=<media> <port>/<number of ports> <transport> <fmt
> list>
>       In such a case, the ports used depend on the
> transport protocol.For RTP, the default is that only
> the even numbered ports are used for data with the
> corresponding one-higher odd ports used for the RTCP
> belonging to the RTP session, and the <number of
> ports>
> denoting the number of RTP sessions.  For example:
>           m=video 49170/2 RTP/AVP 31 "
>
>           If multiple streams don't refer to the same
> section then <port>/<number of ports>  might not be
> valid as each media section will give its own ports.
> If multiple streams are mapped to one m= section then
> how will the b=AS parameter be specified on per media
> basis. But I might be missing something.
>
> sunil bhargo
>
> --- Colin Perkins <[email-masked]> wrote:
>
>> On 20 Sep 2004, at 20:42, [email-masked]
>> wrote:
>>> A New Internet-Draft is available from the on-line
>> Internet-Drafts
>>> directories.
>>> This draft is a work item of the Multiparty
>> Multimedia Session Control
>>> Working Group of the IETF.
>>>
>>> 	Title		: SDP: Session Description Protocol
>>> 	Author(s)	: M. Handley, et al.
>>> 	Filename	: draft-ietf-mmusic-sdp-new-20.txt
>>> 	Pages		: 45
>>> 	Date		: 2004-9-20
>>> 	
>>> This memo defines the Session Description Protocol
>> (SDP). SDP is
>>> intended for describing multimedia sessions for
>> the purposes of
>>> session announcement, session invitation, and
>> other forms of
>>> multimedia session initiation.
>>>
>>> A URL for this Internet-Draft is:
>>>
>>
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-20.txt
>>
>> There's a single change in this version: to remove
>> the underspecified
>> "control" and "data" media types, aligning the SDP
>> media types with
>> MIME media types. If there's a use for these media
>> types they can be
>> registered separately. They've been removed here in
>> the interests of
>> getting the base spec out.
>>
>> Colin
>>
>>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
-- 
Colin Perkins
http://csperkins.org/