[Jingle] 1.1 XEPs (166, 167, 177)

Peter Saint-Andre stpeter at stpeter.im
Wed Dec 2 13:48:43 CST 2009


Corrections...

On 12/2/09 11:48 AM, Peter Saint-Andre wrote:
> On 12/2/09 11:22 AM, Peter Saint-Andre wrote:
>> On 12/2/09 10:39 AM, Justin Karneges wrote:
>>> On Wednesday 02 December 2009 09:01:05 Peter Saint-Andre wrote:
>>>> On 12/2/09 12:01 AM, Justin Uberti wrote:
>>>>> Makes sense. Anyone willing to take a stab at defining the contents of
>>>>> <avpf>?
>>>> My question is: do we need this for the 1.1 specs? The AVPF stuff seems
>>>> like a new feature that requires some further thought.
>>> Even if we don't put this in just yet, we still ought to get the current RTP 
>>> profile stuff squared away in 1.1.  That is, clarify that a content is only 
>>> ever RTP/AVP or RTP/SAVP.
>> I think that RTP/AVP as the default was assumed back when we had the
>> profile attribute, and <encryption/> signals RTP/SAVP. But I'll add a
>> sentence to clarify that.
> 
> I've added the following paragraph to the section on mapping to SDP:
> 
> ###
> 
> By default the SDP <transport> MUST be considered "RTP/AVP" as defined
> in RFC 3550. If the initiation request contains a <security/> element to
> specify security preconditions for the session, then the SDP <transport>
> MUST instead be considered "RTP/SAVP" as defined in RFC 3711. Future
> versions of this specification might define how to use other SDP
> transports, such as "RTP/AVPF" and "RTP/SAVPF" as defined in RFC 4585
> [14] and RFC 5124 [15] respectively.
> 
> ###

Justin Karneges reminded me via IM that the RTP profiles are not just an
SDP thing, so I have modified the text and moved it. Now 1.1rc4 has:

###

4. Application Format

<snip/>

RTP as defined in RFC 3550 is used in the context of various "profiles"
that are defined by other specifications. Jingle RTP treats RTP profiles
as follows:

   1. By default the RTP profile in Jingle RTP MUST be considered
"RTP/AVP" as defined in RFC 3551 [7].

   2. If the session initiation request contains an <encryption/>
element to specify use of SRTP as described under Negotiation of SRTP,
then the RTP profile MUST instead be considered "RTP/SAVP" as defined in
RFC 3711 [8].

   3. Future versions of this specification might define how to use
other RTP profiles, such as "RTP/AVPF" and "RTP/SAVPF" as defined in RFC
4585 [9] and RFC 5124 [10] respectively.

###

and....

###

6. Mapping to Session Description Protocol

<snip/>

If the payload type is static (payload-type IDs 0 through 95 inclusive),
it MUST be mapped to an m= line as defined in RFC 4566. The generic
format for this line is as follows:

m=<media> <port> <transport> <fmt list>


The SDP <media> parameter is "audio" or "video" or some other media type
as specified by the Jingle 'media' attribute, the <port> parameter is
the preferred port for such communications (which might be determined
dynamically), the <transport> parameter corresponds to the RTP profile
as described under Application Format, and the <fmt list> parameter is
the payload-type ID.

###

Bug reports and objections appreciated. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091202/1abe534f/attachment.bin>


More information about the Jingle mailing list