Hi, There are a number of problems with your proposal.
First, you mandate SDP parameters to be in a specific order. Second, you mandate the usage of rtpmap. Rtpmap is currently not required if you use static codecs. My proposal would be to use a "ptime like" attribute, used together with the payload type number. Example: a=ptime: <PT> <ptime value> ...or... a=fmtp: 10 ptime=<ptime value> ...or something similar. I beleive work has been done on such attributes, but I don't remember the details. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Attila > Sipos > Sent: 3. marraskuuta 2004 11:07 > To: Danail Kirov; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] Does RFC3264 allow different ptime for > different audio codecs? > > > > Hi Danail, > > I think your idea is OK. > > As you know, in SDP, we use the "m=" line to start each media > description. > So, your idea is to use the "a=rtpmap" line to signify the start > of each "codec description". I can't see anything wrong with this. > > I suggest you subscribe to the "Multiparty Multimedia Session > Control (mmusic)" > mailing list: > http://www.ietf.org/html.charters/mmusic-charter.html > > You can then submit your idea to: > mailto:[EMAIL PROTECTED] > > You could also make a quick check of the new draft for SDP but I > don't think it addresses your concerns: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-21.txt > > > Regards, > > Attila > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Danail > > Kirov > > Sent: 02 November 2004 23:15 > > To: Attila Sipos; [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] Does RFC3264 allow > different ptime for > > different audio codecs? > > > > > > Hi Attila, > > > > "Can you show me an example of how you would do this?" > > > > IMO to completely describe a codec one should provide the max > > packet time > > the codec can accept on receiving and also the desired > packet time for > > sending / receiving. Ideally and if it was up to me to define > > it, I would > > have combined all this information in the rtpmap attribute > as follows: > > > > a=rtpmap:<payload type> <encoding name>/<clock > > rate>[/<encoding parameters>] > > <max recv ptime> <preferred send recv ptime> > > > > For example my g.711 implementation by firmware limitation > > cannot receive > > more than 30ms packets and based on bandwidth restrictions > > and voice quality > > concerns I would like to send/receive at 10ms. I would > > indicate this as > > follows: > > > > a=rtpmap:0 PCMU/8000 30 10 > > > > But his is asking for changing the rtpmap attribute > > definition and as such > > is not likely to be taken easy. > > > > Instead, I think it is more likely to come to an agreement on > > a "better" use > > of the already "loosely" defined ptime and maxptime > > attributes to describe > > each individual codec as in the following example where > each ptime and > > maxptime describes the rtpmap above it: > > > > m=audio 5004 RTP/AVP 0 4 18 101 > > a=rtpmap:0 PCMU/8000 > > a=ptime:10 > > a=maxptime:30 > > a=rtpmap:4 G723/8000 > > a=ptime:30 > > a=maxptime:60 > > a=rtpmap:18 G729/8000 > > a=ptime:20 > > a=maxptime:80 > > a=rtpmap:101 telephone-event/8000 > > > > With this approach there is no need to specify ptime and > maxptime for > > rfc2283. > > > > Do you think something like that could be defined and agreed upon? > > > > Regards, > > Danail > > > > -----Original Message----- > > From: Attila Sipos [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 02, 2004 1:53 PM > > To: Danail Kirov; Danail Kirov; Linda Xiao; > > [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] Does RFC3264 allow > different ptime for > > different audio codecs? > > > > > > Hi Danail, > > >>2. How is the rfc2283 packet time presented if rfc2283 is > > listed in the > > >>"m=" line? > > As you know, the RFC2833 packet interval should be the same > > as that for the selected RTP. So, the RFC2833 packet time > > can't be fixed - and so a '-' is used. > > m=audio 5004 RTP/AVP 0 4 97 18 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:97 telephone-event/8000 > > a=mptime:10 30 - 20 > > > > >>3. The most important question. Can somebody definitely say > > that based on > > >>RFC3264 and RFC2327 one can not use more than one "a=ptime" line? > > I would say that it doesn't explicitly say you can't use more than > > one ptime line. It also does not explicitly say that multiple > > lines of ptime should be used to indicate separate packet times > > for the different codecs. > > > > >>The > > >>following is a question from Christer Holmberg which was > > left unanswered > > in > > >>your previous thread and is exactly my question as well: > > "Which "rules" > > are > > >>you refering to? > > > > When I said "the rules", I meant the rules in the SDP RFC 2327. > > The problem is that the ptime attribute, in my interpretation, > > is not related to a specific profile but to a specific media > > description. So this is a problem if you have multiple profiles > > with different packet times. > > > > >>RFC2327 does say ptime is a media attribute, but I can't > > >>find anywhere said that you can't specify separate values > > for specific > > >>codecs (using it together with rtpmap)." > > > > Can you show me an example of how you would do this? > > > > Regards, > > Attila > > > > > > -----Original Message----- > > From: Danail Kirov [mailto:[EMAIL PROTECTED] > > Sent: Tue 02/11/2004 19:36 > > To: Attila Sipos; Danail Kirov; Linda Xiao; > > [EMAIL PROTECTED] > > Cc: > > Subject: RE: [Sip-implementors] Does RFC3264 allow > > different ptime > > for different audio codecs? > > > > > > > > Attila, > > I've researched the archives and found you had > > similar discussions > > last > > year, but it appears there are questions still > > unanswered. Maybe you > > guys > > resolved them in some other form. > > 1. Where is the use of mptime defined? I looked at > > the PacketCable > > docs > > referenced at some threads and couldn't find it there. > > 2. How is the rfc2283 packet time presented if > > rfc2283 is listed in > > the "m=" > > line? > > 3. The most important question. Can somebody > > definitely say that > > based on > > RFC3264 and RFC2327 one can not use more than one > > "a=ptime" line? > > The > > following is a question from Christer Holmberg > which was left > > unanswered in > > your previous thread and is exactly my question as > > well: "Which > > "rules" are > > you refering to? RFC2327 does say ptime is a media > > attribute, but I > > can't > > find anywhere said that you can't specify separate > values for > > specific > > codecs (using it together with rtpmap)." > > > > I am surprised the SIP community would leave this > > unaddressed for > > such a > > long time? > > > > Regards, > > > > Danail Kirov > > > > > > -----Original Message----- > > From: Attila Sipos [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 02, 2004 1:05 AM > > To: Danail Kirov; Linda Xiao; > [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] Does RFC3264 allow > > different ptime > > for > > different audio codecs? > > > > > > This is still an officially unaddressed problem > (and I really > > don't understand why). > > > > We (and some others) support the mptime or (x-mptime) > > attribute. > > > > So your list would get compressed to: > > m=audio 5004 RTP/AVP 0 4 18 > > a=rtpmap:0 PCMU/8000 > > a=mptime:10 30 20 > > > > Some use x-mptime instead of mptime: > > a=x-mptime:10 30 20 > > > > We allow for both. > > > > Regards, > > > > Attila > > > > Software Engineer > > http://www.vegastream.com/ > > > > > > -----Original Message----- > > From: > > [EMAIL PROTECTED] on behalf of > > Danail > > Kirov > > Sent: Tue 02/11/2004 00:51 > > To: 'Linda Xiao'; [EMAIL PROTECTED] > > Cc: > > Subject: RE: [Sip-implementors] Does RFC3264 > > allow different > > ptime > > for different audio codecs? > > > > > > > > The problem with this approach is that I can > > not specify > > what is my > > codec > > preference 0, 4 or 18 - i.e all of them are equal. > > Also with this approach the "answerer" may > > choose to accept > > all "m=" > > streams > > and to start sending audio data on all 3 of > > them...while I > > really > > want a > > single audio stream. > > > > -----Original Message----- > > From: Linda Xiao > > [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 01, 2004 4:30 PM > > To: 'Danail Kirov'; > > [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] Does > > RFC3264 allow > > different > > ptime > > for dif ferent audio codecs? > > > > > > I think you can (or should) use multi-line of "m=". > > > > m=audio 5004 RTP/AVP 0 > > a=rtpmap:0 PCMU/8000 > > a=ptime:10 > > > > m=audio 5004 RTP/AVP 4 > > a=rtpmap:4 G723/8000 > > a=ptime:30 > > > > m=audio 5004 RTP/AVP 18 > > a=rtpmap:18 G729/8000 > > a=ptime:20 > > > > > > Regards/Linda > > > > -----Original Message----- > > From: Danail Kirov [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 01, 2004 4:14 PM > > To: [EMAIL PROTECTED] > > Subject: [Sip-implementors] Does RFC3264 > > allow different > > ptime for > > different > > audio codecs? > > > > > > Hi All, > > > > Is it allowed to add > > a=ptime:xx > > for every codec listed in a single m= line? > > For example: > > > > m=audio 5004 RTP/AVP 0 4 18 > > a=rtpmap:0 PCMU/8000 > > a=ptime:10 > > a=rtpmap:4 G723/8000 > > a=ptime:30 > > a=rtpmap:18 G729/8000 > > a=ptime:20 > > > > All the samples I've seen so far imply there > > is only one > > ptime per > > m= line, > > but this does not describe the "real world" > > where one would > > want to > > use > > different audio codecs with different > packet times and > > different > > codecs > > operate on different [ms] frames. > > G.711 - 1ms > > G.729 - 10ms > > G.723 - 30ms > > i.e - specifiying 10ms does not make any > > sense for G.723, > > but does > > for > > G.729 and G.711. > > > > Regards, > > > > Danail Kirov > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
