A forward from Diana Cionoiu of the YATE project. I've cc'd her on this message and allowed her to post despite the fact that (I think) she's not on the list.
/psa -------- Original Message -------- Date: Wed, 04 Jun 2008 16:06:44 +0300 From: Diana Cionoiu <[EMAIL PROTECTED]> To: Peter Saint-Andre <[EMAIL PROTECTED]> CC: XMPP Extension Discussion List <standards@xmpp.org> Subject: Re: Jingle: one RTP application type to bind them all? Hello Peter, I've looked at Olivier's e-mail. Jingle ICE-UDP, Protocol Description. I totally agree on this with Olivier, it's easier to implement in his way. The only note i have here, is that when you send content-accept you should send it just for the candidates that have been accepted. This can bit a more complicated to implement depending on the jingle implementation (Yate doesn't have that problem). Jingle audio, Application format. I totally agree with that. Jingle audio. I also agree with Olivier, in SDP the answer to a request, it's the intersection of the both parties payloads. To make myself more clear. A sends alaw, g729, g726; B knows g729,g723, mulaw; in this case SDP answer of B will be g729 payload only. I also agree with Olivier that alaw and mulaw shoudn't be mandatory. Jingle video. I will prefer to have the video codecs in a different namespace and to keep the width and height. In jingle audio you have this situation: "To track changes to XEP-0166, modified busy scenario and removed unsupported-codecs error." Jingle DTMF. I agree on that with Olivier. Regards, Diana Peter Saint-Andre wrote: > Back in April, Olivier Crête questioned whether we really need separate > application types for RTP audio (XEP-0167) and RFC video (XEP-0180): > > http://mail.jabber.org/pipermail/standards/2008-April/018554.html > > Olivier suggested that we could simply negotiate one RTP "channel" and > use it for anything that RTP can do -- voice, video, real-time text (RFC > 4103), etc. I have not seen a lot of enthusiasm for this idea, but I > would like to make sure that we have consensus on keeping things as-is > before moving forward with the Jingle specs. If you have feedback on > this issue, please weigh in on the standards@xmpp.org list. > > Thanks! > > Peter > >
smime.p7s
Description: S/MIME Cryptographic Signature
