[Standards] Jingle and RTCP

Peter Saint-Andre stpeter at jabber.org
Thu Mar 29 02:49:16 UTC 2007

Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> I don't think so. We have a note in XEP-0166 about RTCP but it needs to
>> be defined more fully. IIRC, in our very old discussions about Jingle we
>> thought that you would have a separate content type for RTCP vs. RTP,
>> but we have not revisited the issue in quite a while. We'll need to look
>> at the link that Aki posted and figure out what some of the best
>> practices among people who have implemented RTCP more widely than we have.
> I wouldn't advocate a seperate stream type. This is the intention of
> "components" to a stream, so a RTP stream could also have an RTCP stream
> along with it. I think ICE defines that if it's being used for RTP,
> component 0 is the RTP stream, and if component 1 is present, it's the
> RTCP. ICE optimises its state machine for components (doesn't make
> connectity checks for the other ports in the candidates until one has
> shown to work, I think). Provided we have a way of doing/expressing
> components in the other transports (the UDP port +1 for example), this
> approach will work fine for traditional RTP+RTCP streams, and keep us
> SIP-wire-compatible.

Right. In XEP-0166 we define "Component" as follows:

"A component is a numbered stream of data which needs to be transmitted 
between the endpoints for a given content type in the context of a given 
session. It is up to the transport to negotiate the details of each 
component. Depending on the content type and the content description, 
one content description may require multiple components to be 
communicated (e.g., the audio content type might use two components: one 
to transmit an RTP stream and another to transmit RTCP timing information)."

So you're right that it's up to each transport spec to define this. We 
need to add something about it to XEP-0177 (UDP port + 1) but I think 
it's taken care of via ICE for XEP-0176. I'll double-check that.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070328/3eafce1b/attachment.bin>

More information about the Standards mailing list