Hi Christer, "First, you mandate SDP parameters to be in a specific order." I've made two proposals, so I am not quite sure if your concern about specific order is about the rtpmap parameters in my first proposal, or the a=ptime following the a=rtpmap in my second proposal. If your concern is about the specific order of <max recv ptime> <preferred send recv ptime> in the a=rtpmap:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>] <max recv ptime> <preferred send recv ptime> Then I would say that one should also be concerned about the specific order of <payload type> <encoding name> in the rtpmap :) If your concern is about requiring specific ptime order following the rtpmap I agree that is not the best approach, but that seems to be the only approach that does not require us to define new attributes, or modify existing ones and it also ensures more or less backward compatibility. "Second, you mandate the usage of rtpmap. Rtpmap is currently not required if you use static codecs." I agree, but at the same time it appears all decent SIP endpoints I've seen do send complete rtpmaps for all codecs they support regardless of whether the RTP map is static or dynamic. Adding two more parameter at the end is an "incremental" change and should not break existing implementation (I hope). The ptime and maxptime describe the RTP packets and as such logically belong to the rtpmap attribute line. I would rather have all parameters that describe a codec and its rtpmap in a single line, rather than in two or more lines. It simply requires less code to process, parse and gather all parameters describing a codec rtpmap. As far as your proposal is concerned: a=ptime: <PT> <ptime value> This would break existing implementations that expect <ptime value>, not <PT> after "ptime:" a=fmtp: 10 ptime=<ptime value> This seems better, but again if we are going to define new attributes why not put everything in one line if there is one to one relation between the codec and the attributes? "I beleive work has been done on such attributes, but I don't remember the details." I am trying hard to find all relevant pieces of information. If you could point me where this work is done I would appreciate it. I don't want to reinvent the wheel and if there is something that works and is supported by most of the vendors I would gladly start using it. I am newcomer to SIP and I am a little bit frustrated that such basic things are not clearly defined. I was hoping SIP would be more mature by now, but it appears interoperability of SIP audio endpoints is achieved by relying on the default packet times only. Lastly, since you originally raised (in previous discussions) the same question as me, how did your research end up on whether more than one "a=ptime" line per "m=" line is allowed by RFC3264 and RFC2327? Regards, Danail -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 9:00 AM To: 'Attila Sipos'; Danail Kirov; [EMAIL PROTECTED] Subject: RE: [Sip-implementors] Does RFC3264 allow different ptime for dif ferent audio codecs? 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
