[Standards] [Fwd: Re: Jingle: one RTP application type to bind themall?]

[Peter Saint-Andre]

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 <diana (AT) null (DOT) ro>
To: Peter Saint-Andre <stpeter (AT) stpeter (DOT) im>
CC: XMPP Extension Discussion List <standards (AT) xmpp (DOT) 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 (AT) xmpp (DOT) org list.
>
> Thanks!
>
> Peter
>
>

[Peter Saint-Andre]

On 06/04/2008 9:07 AM, Peter Saint-Andre wrote:
> 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 <diana (AT) null (DOT) ro>
> To: Peter Saint-Andre <stpeter (AT) stpeter (DOT) im>
> CC: XMPP Extension Discussion List <standards (AT) xmpp (DOT) 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).

I think we removed sending content-accept, so your comment may not apply
anymore.

> 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.

Done. (Will publish updated XEP-0167 in a few minutes.)

> Jingle video. I will prefer to have the video codecs in a different
> namespace and to keep the width and height.

We changed this to include the height and width in payload-type parameters.

> In jingle audio you have this situation: "To track changes to XEP-0166,
> modified busy scenario and removed unsupported-codecs error."

Yes that's gone.

> Jingle DTMF. I agree on that with Olivier.

Done.

/psa