RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt

["Ingemar Johansson S \(LU/EAB\)" <[e-mail]>]

Hi

And thanks for the reply, in my opinion alternative 2 below is the most
attractive although I must admit that at first glance I did not
understand it at all :-), is it possible to have such an example in a
future version of draft-ietf-mmusic-sdp-media-capabilities or do you
believe that it is too much of a special case ?

I am not sure if I am driving a non-issue her, reason why is simply put
as you point out below that many codecs have an abundance of possible
parameters and in order to offer all permutations can easily produce
really large SDP's esp. if the attributes are not mutually exclusive.

Using SIP compression there is always a possibility that one don't gain
that much by trying to squeeze down the SDP's in this way but this
assumes that the compressor is loaded with the correct glossary. So I
believe that there are benefits from trying to keep the SDP's reasonably
small.

Ingemar

> -----Original Message-----
> From: Robert R. Gilman [mailto:[e-mail]] 
> Sent: den 24 februari 2007 00:21
> To: Ingemar Johansson S (LU/EAB)
> Cc: [e-mail]
> Subject: Re: [MMUSIC] I-D 
> ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt
> 
> Ingemar-
> Thanks for your comments.  Let me try to explain the approach we took.
> Our intent was to associate each cfmt attribute with a codec 
> in a cmed attribute, in just the same way that the fmtp 
> attribute is associated with a codec (via payload type) in 
> the media line.  We didn't consider a mix-and-match at the 
> codec level within the pcfg attribute.  I'll most likely mess 
> this up, but I believe the following is equivalent to your 
> SDP (you didn't seem to use the cmft:5 and cfmt:6 lines in 
> your description; doing so would cause the following example 
> to perhaps be even larger):
> 
> a=creq:1
> a=cmed:1 AMR AMR AMR AMR AMR AMR
> a=cmft:1 mode-change-capability=1; max-red-220; mode-set=0,2,4,7
> a=cfmt:2 mode-change-capability=1; max-red=220; mode-set=0,3,5,6
> a=cfmt:3 mode-change-capability=1; max-red-220; 
> octet-align=1; mode-set=0,2,4,7
> a=cfmt:4 mode-change-capability=1; max-red=220; 
> octet-align=1; mode-set=0,3,5,6
> a=cfmt:5 mode-change-capability=2; octet-align=1; mode-set=0,2,4,7
> a=cfmt:6 mode-change-capability=2; octet-align=1; mode-set=0,3,5,6
> a=cenc:1 16000/1
> a=cenc:2 8000/1
> a=cenc:3 16000/1
> a=cenc:4 8000/1
> a=cenc:5 16000/1
> a=cenc:6 8000/1
> m=audio 49152 RTP/AVP 97
> a=rtpmap:97 AMR/16000/1
> a=fmtp:97 mode-change-capability=2; max-red=220
> pcfg:1 m=1|2 pt=1:98,2:99
> pcfg:2 m=3|4 pt=3:98,4:99
> pcfg:3 m=5|6 pt=5:98,5:99
> 
> My version takes about half again as many characters as 
> yours.  There might be a third way to do this as well - 
> suppose the cfmt and cenc attributes were applicable to 
> multiple codecs, and multiple lines were applicable to one 
> codec (equivalent to your assumption).  Then we might say 
> something like:
> 
> a=creq:1
> a=cmed:1 AMR AMR AMR AMR AMR AMR
> a=cenc:1,3,5 16000/1
> a=cenc:2,4,6 8000/1
> a=cfmt:1,2,3,4 mode-change-capability=1
> a=cfmt:5,6 mode-change-capability=2
> a=cfmt:1,2,3,5 max-red=220
> a=cfmt:3,4,5,6 octet-align=1
> a=cfmt:???? mode-change-neighbor=1
> a=cfmt:???? mode-change-period=2
> a=cfmt:1,3,5 mode-set=0,2,4,7
> a=cfmt:2,4,6 mode-set=0,3,5,6
> m=audio 49152 RTP/AVP 97
> a=rtpmap:97 AMR/16000/1
> a=fmtp:97 mode-change-capability=2; max-red=220
> pcfg:1 m=1|2 pt=1:98,2:99
> pcfg:2 m=3|4 pt=3:98,4:99
> pcfg:3 m=5|6 pt=5:98,5:99
> 
> This form takes slightly fewer characters than yours (I left 
> in the two format parameters you didn't seem to use), but I'm 
> not sure which one is more useful or readable.  Both permit 
> the SDP generator to code format parameters on multiple 
> lines, rather than force one long line, but still permit it 
> if desired.  Codecs with lots of formatting parameters and 
> options are always problematic in capability announcements - 
> unless you can declare lot of "don't-care" values or use 
> popular defaults.
> It seems almost any method will do if there is little reuse 
> of parameters.
> What do you think?
> -Bob
> ----------------------------------------------------
> Bob Gilman       [e-mail]      [phone]
> 
> Ingemar Johansson S (LU/EAB) wrote:
> > Hi
> > 
> > Reading the draft I have the following simple question Would it be 
> > possible, based on all the possible attributes given in 
> > http://tools.ietf.org/id/draft-ietf-avt-rtp-amr-bis-06.txt
> > to formulate an SDP offer like the one below. 
> > I am not sure that it is possible to combine several cmft's in the 
> > pcfg in the f=x,y,z.. way that I written below, it is 
> possible that it 
> > is sematically incorrect, anyway comments welcome.
> > Regards
> > Ingemar
> > ========================
> > a=creq:v1
> > a=cmed:1 AMR
> > a=cfmt:1 mode-change-capability=1;
> > a=cfmt:2 mode-change-capability=2;
> > a=cfmt:3 max-red=220;
> > a=cfmt:4 octet-align=1;
> > a=cfmt:5 mode-change-neighbor=1;
> > a=cfmt:6 mode-change-period=2;
> > a=cfmt:7 mode-set=0,2,4,7;
> > a=cfmt:8 mode-set=0,3,5,6;
> > a=cenc:1 16000/1
> > a=cenc:2 8000/1
> > m=audio 49152 RTP/AVP 97
> > a=rtpmap:97 AMR/16000/1
> > a=fmtp:97 mode-change-capability=2; max-red=220
> > pcfg:1 m=(1 f=1,3,7 e=1 pt=98)|(1 f=1,3,8 e=2 pt=99)
> > pcfg:2 m=(1 f=1,3,4,7 e=1 pt=98)|(1 f=1,3,4,8 e=2 pt=99)
> > pcfg:3 m=(1 f=2,4,7 e=1 pt=98)|(1 f=2,4,8 e=2 pt=99) 
> > ========================
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]]
> >>Sent: den 21 februari 2007 16:50
> >>To: [e-mail]
> >>Cc: [e-mail]
> >>Subject: [MMUSIC] I-D
> >>ACTION:draft-ietf-mmusic-sdp-media-capabilities-01.txt
> >>
> >>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 media capabilities Negotiation
> >>	Author(s)	: F. Andreasen, et al.
> >>	Filename	: 
> >>draft-ietf-mmusic-sdp-media-capabilities-01.txt
> >>	Pages		: 22
> >>	Date		: 2007-2-21
> >>	
> >>Session Description Protocol (SDP) capability negotiation provides a
> >>   general framework for negotiating capabilities in SDP.  The base
> >>   framework defines only capabilities for negotiating transport
> >>   protocols and attributes.  In this document, we extend the 
> >>framework
> >>   by defining media capabilities that can be used to 
> negotiate media
> >>   types and their associated parameters.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-medi
> >>a-capabilities-01.txt
> >>
> >>To remove yourself from the I-D Announcement list, send a 
> message to 
> >>[e-mail] with the word unsubscribe in 
> the body of 
> >>the message.
> >>You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>to change your subscription settings.
> >>
> >>Internet-Drafts are also available by anonymous FTP. Login with the 
> >>username "anonymous" and a password of your e-mail address. After 
> >>logging in, type "cd internet-drafts" and then "get 
> >>draft-ietf-mmusic-sdp-media-capabilities-01.txt".
> >>
> >>A list of Internet-Drafts directories can be found in 
> >>http://www.ietf.org/shadow.html or 
> >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>Internet-Drafts can also be obtained by e-mail.
> >>
> >>Send a message to:
> >>	[e-mail].
> >>In the body type:
> >>	"FILE
> >>/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-01.txt".
> >>	
> >>NOTE:	The mail server at ietf.org can return the document in
> >>	MIME-encoded form by using the "mpack" utility.  To use this
> >>	feature, insert the command "ENCODING mime" before the "FILE"
> >>	command.  To decode the response(s), you will need "munpack" or
> >>	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> >>	exhibit different behavior, especially when dealing with
> >>	"multipart" MIME messages (i.e. documents which have been split
> >>	up into multiple messages), so check your local documentation on
> >>	how to manipulate these messages.
> >>
> >>Below is the data which will enable a MIME compliant mail reader 
> >>implementation to automatically retrieve the ASCII version of the 
> >>Internet-Draft.
> >>
> > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 

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