From paulrw at codian.com Tue Dec 1 05:50:22 2009 From: paulrw at codian.com (Paul Witty) Date: Tue, 01 Dec 2009 11:50:22 +0000 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <200911301551.53516.justin@affinix.com> References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> Message-ID: <4B1502FE.1020304@codian.com> Justin Karneges wrote: > I'm not 100% sure, but I believe each component is assigned a profile. So > component 1 would always be "RTP/AVP" and component 2 would always > be "RTP/AVPF" (which I think is more or less synonymous with RTCP). > > This as opposed to the entire session being assigned a single profile. > > But probably an RTP guru should confirm this. > > -Justin > > That's not right: looking from the SDP world, the two streams together (RTP and RTCP) would be given a single profile e.g. RTP/AVP or RTP/AVPF. For example a line m=video 23300 RTP/AVP 34 would imply RTP on port 23300, with RTCP on 23301 (RFC 4566 actually specifies m=video 23300/2 to explicitly state that there are two ports in use, but in practice this is almost never seen). RTP/AVPF (as defined in RFC 4586) just extends the RTCP to provide better feedback, but again applies to both the RTP and RTCP channels. Within a call, different RTP profiles could be used for different media streams e.g. m=video 23300 RTP/AVPF and m=audio 23302 RTP/AVP. -- Paul Witty From olivier.crete at collabora.co.uk Tue Dec 1 07:28:47 2009 From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=) Date: Tue, 01 Dec 2009 18:58:47 +0530 Subject: [Jingle] ICE-CONTROLLING / CONTROLLED In-Reply-To: <200911301112.40802.justin@affinix.com> References: <200911291427.26117.justin@affinix.com> <2349.1259579722.014772@invsysm1> <200911301112.40802.justin@affinix.com> Message-ID: <1259674127.6619.9.camel@TesterTop3.tester.ca> On Mon, 2009-11-30 at 11:12 -0800, Justin Karneges wrote: > On Monday 30 November 2009 03:15:22 Dave Cridland wrote: > > On Sun Nov 29 22:27:26 2009, Justin Karneges wrote: > > > According to the ICE draft, these attributes are used in > > > connectivity checks > > > to resolve role conflicts. However, in XMPP there shouldn't ever > > > be a role > > > conflict, right? It is clear who is the initiator and the > > > responder. > > > > > > XEP-0176 mandates the usage of these attributes. Maybe this is > > > because the > > > ICE draft does also? Section 7.1.1.2 says: "The agent MUST > > > include the > > > ICE-CONTROLLED attribute in the request if it is in the controlled > > > role, and > > > MUST include the ICE-CONTROLLING attribute in the request if it is > > > in the > > > controlling role." > > > > > > Maybe we should drop this requirement from XEP-0176? Or maybe we > > > could say > > > something like "the attributes MUST be included for consistency > > > with the ICE > > > draft but their values don't matter and are not ever used" ? > > > > I'm assuming that ICE libraries would typically mandate these > > attributes anyway. I don't see the utility in specifying that they > > "don't matter", aside from creating confusion. > > If XEP-0176 was literally ICE reframed in XML stanzas, then I might agree. > But the XEP is more of an ICE variant, and it has different rules. For > example, the XEP specifies trickling candidates. This means you wouldn't (or > wouldn't want to) pair a generic ICE library with Jingle. Instead, you'd use > a XEP-0176-specific ICE library, or some multi-purpose ICE library that > supports the XEP-0176-isms. > > Because of this, I think it is entirely legit that someone (read: me) would > implement only the parts of ICE that matter for Jingle. Two Jingle clients > will do nothing with the ICE-CONTROLLING/CONTROLLED attributes, even though > they are mandated by the spec, and that confused me as an implementor. Here > I am setting the attributes but never reading them, and it causes me to > second guess my code and write to a mailing list. Really, I think you are being lazy. We should do our best to not differentiate from the ICE spec unless it really brings a lot of value. -- Olivier Cr?te olivier.crete at collabora.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From olivier.crete at collabora.co.uk Tue Dec 1 07:36:22 2009 From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=) Date: Tue, 01 Dec 2009 19:06:22 +0530 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <200911301551.53516.justin@affinix.com> References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> Message-ID: <1259674582.6619.14.camel@TesterTop3.tester.ca> On Mon, 2009-11-30 at 15:51 -0800, Justin Karneges wrote: > On Monday 30 November 2009 09:11:27 Peter Saint-Andre wrote: > > On 11/25/09 11:42 AM, Justin Karneges wrote: > > > I think the reason the RTP profile is not passed in the XML is because > > > the profile is defined rigidly in the Jingle RTP spec (or at least, it is > > > supposed to be). > > > > By that do you mean XEP-0167 allows only "RTP/AVP" and any other profile > > would need to be defined in a separate spec? > > Right. > > > > Probably the XEP should say that component 1 is "AVP" and component 2 > > > is "AVPF". > > > > XEP-0167 currently says: > > > > The component numbered "1" MUST be associated with RTP and the > > component numbered "2" MUST be associated with RTCP. > > > > Are you suggesting that we clarify the text to explicitly state that > > AVPF is a (or the only) component that's associated with RTCP, with a > > reference to RFC 4585? > > I'm not 100% sure, but I believe each component is assigned a profile. So > component 1 would always be "RTP/AVP" and component 2 would always > be "RTP/AVPF" (which I think is more or less synonymous with RTCP). > > This as opposed to the entire session being assigned a single profile. > > But probably an RTP guru should confirm this. Really, having profile per component doesn't make sense. Since the profile defines the components... Also, the profile specifies stuff like how the payload types are negotiated/specified, etc. It is definitely a per-content thing. -- Olivier Cr?te olivier.crete at collabora.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From robert.mcqueen at collabora.co.uk Tue Dec 1 09:16:37 2009 From: robert.mcqueen at collabora.co.uk (Robert McQueen) Date: Tue, 01 Dec 2009 15:16:37 +0000 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> <4B149552.1070102@stpeter.im> Message-ID: <4B153355.7090301@collabora.co.uk> Justin Uberti wrote: > I agree with Rob's general notion that we should not duplicate stuff in > our signaling, but RTCP does not automatically mean AVPF. AVPF defines > special rules for how RTCP can be transmitted, but it is still possible > to send RTCP using the old (AVP) rules. > > Therefore, I think we need some way in the signaling to indicate the use > of AVPF. +1 - this is what I was getting at. Signal the stuff we're actually missing, not throw in misc SDP stuff which is redundant to what we actually have. We just want a little handshake in the same way we do for encryption, I guess? One in the offer to say we want to use it, one in the answer to say we will? Cheers, Rob > On Mon, Nov 30, 2009 at 8:02 PM, Peter Saint-Andre > wrote: > > On 11/30/09 4:51 PM, Justin Karneges wrote: > > On Monday 30 November 2009 09:11:27 Peter Saint-Andre wrote: > >> On 11/25/09 11:42 AM, Justin Karneges wrote: > >>> I think the reason the RTP profile is not passed in the XML is > because > >>> the profile is defined rigidly in the Jingle RTP spec (or at > least, it is > >>> supposed to be). > >> By that do you mean XEP-0167 allows only "RTP/AVP" and any other > profile > >> would need to be defined in a separate spec? > > > > Right. > > > >>> Probably the XEP should say that component 1 is "AVP" and > component 2 > >>> is "AVPF". > >> XEP-0167 currently says: > >> > >> The component numbered "1" MUST be associated with RTP and the > >> component numbered "2" MUST be associated with RTCP. > >> > >> Are you suggesting that we clarify the text to explicitly state that > >> AVPF is a (or the only) component that's associated with RTCP, with a > >> reference to RFC 4585? > > > > I'm not 100% sure, but I believe each component is assigned a > profile. So > > component 1 would always be "RTP/AVP" and component 2 would always > > be "RTP/AVPF" (which I think is more or less synonymous with RTCP). > > In the context of RTP/AVP, yes. In the context of RTP/SAVP (which maps > to Jingle + element) the RTCP-associated component would > be RTP/SAVPF. And perhaps it's enough to say just that. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > -- Robert McQueen +44 7876 562 564 Director, Collabora Ltd. http://www.collabora.co.uk From justin at affinix.com Tue Dec 1 11:33:58 2009 From: justin at affinix.com (Justin Karneges) Date: Tue, 1 Dec 2009 09:33:58 -0800 Subject: [Jingle] ICE-CONTROLLING / CONTROLLED In-Reply-To: <1259674127.6619.9.camel@TesterTop3.tester.ca> References: <200911291427.26117.justin@affinix.com> <200911301112.40802.justin@affinix.com> <1259674127.6619.9.camel@TesterTop3.tester.ca> Message-ID: <200912010933.58231.justin@affinix.com> On Tuesday 01 December 2009 05:28:47 Olivier Cr?te wrote: > On Mon, 2009-11-30 at 11:12 -0800, Justin Karneges wrote: > > On Monday 30 November 2009 03:15:22 Dave Cridland wrote: > > > On Sun Nov 29 22:27:26 2009, Justin Karneges wrote: > > > > According to the ICE draft, these attributes are used in > > > > connectivity checks > > > > to resolve role conflicts. However, in XMPP there shouldn't ever > > > > be a role > > > > conflict, right? It is clear who is the initiator and the > > > > responder. > > > > > > > > XEP-0176 mandates the usage of these attributes. Maybe this is > > > > because the > > > > ICE draft does also? Section 7.1.1.2 says: "The agent MUST > > > > include the > > > > ICE-CONTROLLED attribute in the request if it is in the controlled > > > > role, and > > > > MUST include the ICE-CONTROLLING attribute in the request if it is > > > > in the > > > > controlling role." > > > > > > > > Maybe we should drop this requirement from XEP-0176? Or maybe we > > > > could say > > > > something like "the attributes MUST be included for consistency > > > > with the ICE > > > > draft but their values don't matter and are not ever used" ? > > > > > > I'm assuming that ICE libraries would typically mandate these > > > attributes anyway. I don't see the utility in specifying that they > > > "don't matter", aside from creating confusion. > > > > If XEP-0176 was literally ICE reframed in XML stanzas, then I might > > agree. But the XEP is more of an ICE variant, and it has different rules. > > For example, the XEP specifies trickling candidates. This means you > > wouldn't (or wouldn't want to) pair a generic ICE library with Jingle. > > Instead, you'd use a XEP-0176-specific ICE library, or some multi-purpose > > ICE library that supports the XEP-0176-isms. > > > > Because of this, I think it is entirely legit that someone (read: me) > > would implement only the parts of ICE that matter for Jingle. Two Jingle > > clients will do nothing with the ICE-CONTROLLING/CONTROLLED attributes, > > even though they are mandated by the spec, and that confused me as an > > implementor. Here I am setting the attributes but never reading them, > > and it causes me to second guess my code and write to a mailing list. > > Really, I think you are being lazy. We should do our best to not > differentiate from the ICE spec unless it really brings a lot of value. The ICE draft says that conflict resolution is needed for third-party call control cases. Whenever I see stuff like "third-party call control", my SIP alarms go off, and I don't think it's wrong to ask for clarification about it. Appendix B.11 describes a case where a call controller sends out invites to two different clients and attempts to bridge them. Both invited clients attempt to connect to each other simultaneously I guess, and both think they are in the controlling role. Can this happen with Jingle? Maybe it can, but it would be great if someone would say so. -Justin From dave at cridland.net Tue Dec 1 11:37:48 2009 From: dave at cridland.net (Dave Cridland) Date: Tue, 01 Dec 2009 17:37:48 +0000 Subject: [Jingle] ICE-CONTROLLING / CONTROLLED In-Reply-To: <200912010933.58231.justin@affinix.com> References: <200911291427.26117.justin@affinix.com> <200911301112.40802.justin@affinix.com> <1259674127.6619.9.camel@TesterTop3.tester.ca> <200912010933.58231.justin@affinix.com> Message-ID: <2349.1259689068.726902@invsysm1> On Tue Dec 1 17:33:58 2009, Justin Karneges wrote: > The ICE draft says that conflict resolution is needed for > third-party call > control cases. Whenever I see stuff like "third-party call > control", my SIP > alarms go off, and I don't think it's wrong to ask for > clarification about > it. Sure, but I'm not following the value in deviating from the standard spec here. Is this stuff particularly onerous? > Appendix B.11 describes a case where a call controller sends out > invites to > two different clients and attempts to bridge them. Both invited > clients > attempt to connect to each other simultaneously I guess, and both > think they > are in the controlling role. Can this happen with Jingle? Maybe > it can, but > it would be great if someone would say so. I don't see what expressly forbids this. And even if it's not possible now, I don't see why we'd wish to preclude this happening in the future. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From olivier.crete at collabora.co.uk Wed Dec 2 00:21:24 2009 From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=) Date: Wed, 02 Dec 2009 11:51:24 +0530 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B153355.7090301@collabora.co.uk> References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> <4B149552.1070102@stpeter.im> <4B153355.7090301@collabora.co.uk> Message-ID: <1259734884.6619.31.camel@TesterTop3.tester.ca> HOn Tue, 2009-12-01 at 15:16 +0000, Robert McQueen wrote: > Justin Uberti wrote: > > I agree with Rob's general notion that we should not duplicate stuff in > > our signaling, but RTCP does not automatically mean AVPF. AVPF defines > > special rules for how RTCP can be transmitted, but it is still possible > > to send RTCP using the old (AVP) rules. > > > > Therefore, I think we need some way in the signaling to indicate the use > > of AVPF. > > +1 - this is what I was getting at. Signal the stuff we're actually > missing, not throw in misc SDP stuff which is redundant to what we > actually have. We just want a little handshake in the same way > we do for encryption, I guess? One in the offer to say we want to use > it, one in the answer to say we will? Having a tag is probably not a bad idea because we need to negotiate more than just the use oif but may be interesting to have something like that because with AVPF you want to be able to negotiate what kind of feedback is supported. So only saying "we support AVPF" is not enough. This is all explained in RFC 4585 section 4. -- Olivier Cr?te olivier.crete at collabora.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From juberti at google.com Wed Dec 2 01:01:51 2009 From: juberti at google.com (Justin Uberti) Date: Tue, 1 Dec 2009 23:01:51 -0800 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <1259734884.6619.31.camel@TesterTop3.tester.ca> References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> <4B149552.1070102@stpeter.im> <4B153355.7090301@collabora.co.uk> <1259734884.6619.31.camel@TesterTop3.tester.ca> Message-ID: Makes sense. Anyone willing to take a stab at defining the contents of ? 2009/12/1 Olivier Cr?te > HOn Tue, 2009-12-01 at 15:16 +0000, Robert McQueen wrote: > > Justin Uberti wrote: > > > I agree with Rob's general notion that we should not duplicate stuff in > > > our signaling, but RTCP does not automatically mean AVPF. AVPF defines > > > special rules for how RTCP can be transmitted, but it is still possible > > > to send RTCP using the old (AVP) rules. > > > > > > Therefore, I think we need some way in the signaling to indicate the > use > > > of AVPF. > > > > +1 - this is what I was getting at. Signal the stuff we're actually > > missing, not throw in misc SDP stuff which is redundant to what we > > actually have. We just want a little handshake in the same way > > we do for encryption, I guess? One in the offer to say we want to use > > it, one in the answer to say we will? > > Having a tag is probably not a bad idea because we need to > negotiate more than just the use oif but may be interesting to have > something like that because with AVPF you want to be able to negotiate > what kind of feedback is supported. So only saying "we support AVPF" is > not enough. > > This is all explained in RFC 4585 section 4. > > > -- > Olivier Cr?te > olivier.crete at collabora.co.uk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil at gmail.com Wed Dec 2 04:19:13 2009 From: ali.sabil at gmail.com (Ali Sabil) Date: Wed, 2 Dec 2009 11:19:13 +0100 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> <4B149552.1070102@stpeter.im> <4B153355.7090301@collabora.co.uk> <1259734884.6619.31.camel@TesterTop3.tester.ca> Message-ID: <6b4de4d80912020219j7be8bd8fh99e0dfe3140a5487@mail.gmail.com> On Wed, Dec 2, 2009 at 8:01 AM, Justin Uberti wrote: > Makes sense. Anyone willing to take a stab at defining the contents of > ? > What about using instead of ? From stpeter at stpeter.im Wed Dec 2 10:57:52 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 02 Dec 2009 09:57:52 -0700 Subject: [Jingle] ICE-CONTROLLING / CONTROLLED In-Reply-To: <2349.1259689068.726902@invsysm1> References: <200911291427.26117.justin@affinix.com> <200911301112.40802.justin@affinix.com> <1259674127.6619.9.camel@TesterTop3.tester.ca> <200912010933.58231.justin@affinix.com> <2349.1259689068.726902@invsysm1> Message-ID: <4B169C90.6050504@stpeter.im> On 12/1/09 10:37 AM, Dave Cridland wrote: > On Tue Dec 1 17:33:58 2009, Justin Karneges wrote: >> The ICE draft says that conflict resolution is needed for third-party >> call >> control cases. Whenever I see stuff like "third-party call control", >> my SIP >> alarms go off, and I don't think it's wrong to ask for clarification >> about >> it. > > Sure, but I'm not following the value in deviating from the standard > spec here. Is this stuff particularly onerous? > >> Appendix B.11 describes a case where a call controller sends out >> invites to >> two different clients and attempts to bridge them. Both invited clients >> attempt to connect to each other simultaneously I guess, and both >> think they >> are in the controlling role. Can this happen with Jingle? Maybe it >> can, but >> it would be great if someone would say so. > > I don't see what expressly forbids this. And even if it's not possible > now, I don't see why we'd wish to preclude this happening in the future. Well, Jingle doesn't cover third-party call control now. Someone would need to define how that works. And it ain't me. :P 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: From stpeter at stpeter.im Wed Dec 2 11:01:05 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 02 Dec 2009 10:01:05 -0700 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> <4B149552.1070102@stpeter.im> <4B153355.7090301@collabora.co.uk> <1259734884.6619.31.camel@TesterTop3.tester.ca> Message-ID: <4B169D51.7000503@stpeter.im> On 12/2/09 12:01 AM, Justin Uberti wrote: > Makes sense. Anyone willing to take a stab at defining the contents of > ? 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. In the meantime, I'd like to get these fixes out... XEP-0166: Specified handling of duplicate name attributes on content element; clarified recommended usage of Jingle when exchanging multiple content-types; declared the principle that application types ought not to be mixed beyond necessity within a single session; clarified use of the reason element in cases other than termination. XEP-0167: Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination; defined handling of content-add when none of the offered payload-types are supported, where the signalling uses a content-reject message with a Jingle reason of and a list of the supported codecs. XEP-0177: Added type attribute to candidate element for consistency with XEP-0176. 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: From justin at affinix.com Wed Dec 2 11:39:05 2009 From: justin at affinix.com (Justin Karneges) Date: Wed, 2 Dec 2009 09:39:05 -0800 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B169D51.7000503@stpeter.im> References: <4B02F84A.4060404@stpeter.im> <4B169D51.7000503@stpeter.im> Message-ID: <200912020939.05368.justin@affinix.com> 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 > > ? > > 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. (This is based on Paul Witty's mail, clarifying that RTP profiles are per-content and not per-component.) Later on we can add new protocol elements to indicate different profiles as necessary. -Justin From juberti at google.com Wed Dec 2 12:03:53 2009 From: juberti at google.com (Justin Uberti) Date: Wed, 2 Dec 2009 10:03:53 -0800 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B169D51.7000503@stpeter.im> References: <4B02F84A.4060404@stpeter.im> <200911251042.43612.justin@affinix.com> <4B13FCBF.5060808@stpeter.im> <200911301551.53516.justin@affinix.com> <4B149552.1070102@stpeter.im> <4B153355.7090301@collabora.co.uk> <1259734884.6619.31.camel@TesterTop3.tester.ca> <4B169D51.7000503@stpeter.im> Message-ID: On Wed, Dec 2, 2009 at 9:01 AM, 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 > > ? > > 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. In the meantime, > I'd like to get these fixes out... > > XEP-0166: Specified handling of duplicate name attributes on content > element; clarified recommended usage of Jingle when exchanging multiple > content-types; declared the principle that application types ought not > to be mixed beyond necessity within a single session; clarified use of > the reason element in cases other than termination. > > XEP-0167: Added creator attribute to mute and unmute elements so that > these events can be correlated with a particular content type; clarified > use of the reason element in cases other than termination; defined > handling of content-add when none of the offered payload-types are > supported, where the signalling uses a content-reject message with a > Jingle reason of and a list of the supported codecs. > > XEP-0177: Added type attribute to candidate element for consistency with > XEP-0176. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > I don't see a reason to hold 1.1 for AVPF. We use AVPF/SAVPF extensively, but we need to finish our migration to XEP-0167 before we worry about the signaling of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at stpeter.im Wed Dec 2 12:22:03 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 02 Dec 2009 11:22:03 -0700 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <200912020939.05368.justin@affinix.com> References: <4B02F84A.4060404@stpeter.im> <4B169D51.7000503@stpeter.im> <200912020939.05368.justin@affinix.com> Message-ID: <4B16B04B.4080505@stpeter.im> 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 >>> ? >> 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 signals RTP/SAVP. But I'll add a sentence to clarify that. > (This is based on Paul Witty's mail, clarifying that RTP profiles are > per-content and not per-component.) > > Later on we can add new protocol elements to indicate different profiles as > necessary. Agreed. 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: From stpeter at stpeter.im Wed Dec 2 12:48:25 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 02 Dec 2009 11:48:25 -0700 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B16B04B.4080505@stpeter.im> References: <4B02F84A.4060404@stpeter.im> <4B169D51.7000503@stpeter.im> <200912020939.05368.justin@affinix.com> <4B16B04B.4080505@stpeter.im> Message-ID: <4B16B679.2070802@stpeter.im> 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 >>>> ? >>> 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 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 MUST be considered "RTP/AVP" as defined in RFC 3550. If the initiation request contains a element to specify security preconditions for the session, then the SDP 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. ### 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: From stpeter at stpeter.im Wed Dec 2 13:48:43 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 02 Dec 2009 12:48:43 -0700 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B16B679.2070802@stpeter.im> References: <4B02F84A.4060404@stpeter.im> <4B169D51.7000503@stpeter.im> <200912020939.05368.justin@affinix.com> <4B16B04B.4080505@stpeter.im> <4B16B679.2070802@stpeter.im> Message-ID: <4B16C49B.70402@stpeter.im> 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 >>>>> ? >>>> 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 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 MUST be considered "RTP/AVP" as defined > in RFC 3550. If the initiation request contains a element to > specify security preconditions for the session, then the SDP > 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 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 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 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= The SDP parameter is "audio" or "video" or some other media type as specified by the Jingle 'media' attribute, the parameter is the preferred port for such communications (which might be determined dynamically), the parameter corresponds to the RTP profile as described under Application Format, and the 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: From sureshkumar.pp at gmail.com Thu Dec 10 11:39:39 2009 From: sureshkumar.pp at gmail.com (Suresh Kumar) Date: Thu, 10 Dec 2009 19:39:39 +0200 Subject: [Jingle] Jingle e2e session establishment and security Message-ID: <4b21324c.02135e0a.422b.ffff8316@mx.google.com> Hello, A little background: I am studying the possibility of applying XMPP for a problem(the problem being connecting two entities, over the Internet, which are located in two different private networks, behind NATs). So XMPP + Jingle appears to be a natural solution for this kind of problem. The requirement is: end-to-end byte stream consisting of multiple transport options, along with end-to-end security. Since there is no ICE-TCP(i.e., "urn:xmpp:jingle:transports:ice-tcp"), I will define a custom transport method which will use its own NAT traversal, say that will be in "urn:xmpp:jingle:transports:my-transport:0" xmlns, for time being. I have been going through various XEPs and found that I have the following options * Define a new app type in, say "urn:xmpp:jingle:apps:my-app:0" and use the transport "urn:xmpp:jingle:transports:my-transport:0" with the security tag "urn:xmpp:jingle:security:xtls:0" as defined in XEP-0166[fn:1] and [fn:3]. If for some reason my-transport fails, it would call "transport-replace" with "urn:xmpp:jingle:transports:s5b:1" which in turn, on failure will fall back to "urn:xmpp:jingle:transports:ibb:0". This just follows the suggestions from XEP-0166[fn:2], defines new "what" type and "how" type, and uses Jingle notions for overall session management. Ex: ,---- | | | action='session-initiate | initiator='romeo at montague.lit/orchard' | sid='a73sjjvkla37jfea'> | | | | | RomeoX509CertSHA1Hash | | | | | `---- * Or just hack up the XEP-0234(Jingle File Transfer) to use a new transport method "urn:xmpp:jingle:transports:my-transport:0". I would appreciate if you can share your views on this approach, and also possibly suggestions on any other alternate methods which I failed to envisage. Thanks for your time, Suresh Footnotes: [fn:1] http://xmpp.org/extensions/xep-0166.html#preconditions [fn:2] http://xmpp.org/extensions/xep-0166.html#concepts [fn:3] http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02 From ml at update.uu.se Thu Dec 10 13:44:01 2009 From: ml at update.uu.se (Marcus Lundblad) Date: Thu, 10 Dec 2009 20:44:01 +0100 Subject: [Jingle] Jingle e2e session establishment and security In-Reply-To: <4b21324c.02135e0a.422b.ffff8316@mx.google.com> References: <4b21324c.02135e0a.422b.ffff8316@mx.google.com> Message-ID: <1260474241.27156.1.camel@sagittarius> tor 2009-12-10 klockan 19:39 +0200 skrev Suresh Kumar: > Ex: > ,---- > | | id='zyw6m167' > | to='juliet at capulet.lit/balcony' > | type='set'> > | > | action='session-initiate > | initiator='romeo at montague.lit/orchard' > | sid='a73sjjvkla37jfea'> > | > | > | | sid='vj3hs98y' /> > | > | RomeoX509CertSHA1Hash > | > | > | > | > | > `---- > > * Or just hack up the XEP-0234(Jingle File Transfer) to use a new > transport method "urn:xmpp:jingle:transports:my-transport:0". > Why not use XEP-0260 (Jingle Socks5 Bytestreams Transport)? > I would appreciate if you can share your views on this approach, and > also possibly suggestions on any other alternate methods which I > failed to envisage. > > Thanks for your time, > Suresh //Marcus > > Footnotes: > > [fn:1] http://xmpp.org/extensions/xep-0166.html#preconditions > > [fn:2] http://xmpp.org/extensions/xep-0166.html#concepts > > [fn:3] http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02 From sureshkumar.pp at gmail.com Thu Dec 10 18:12:07 2009 From: sureshkumar.pp at gmail.com (Suresh Kumar) Date: Fri, 11 Dec 2009 02:12:07 +0200 Subject: [Jingle] Jingle e2e session establishment and security In-Reply-To: <1260474241.27156.1.camel@sagittarius> References: <4b21324c.02135e0a.422b.ffff8316@mx.google.com> <1260474241.27156.1.camel@sagittarius> Message-ID: <615616950912101612v3a2a5118wf9ca56c9624a3165@mail.gmail.com> On Thu, Dec 10, 2009 at 9:44 PM, Marcus Lundblad wrote: > tor 2009-12-10 klockan 19:39 +0200 skrev Suresh Kumar: > > > * Or just hack up the XEP-0234(Jingle File Transfer) to use a new > > transport method "urn:xmpp:jingle:transports:my-transport:0". > > > > Why not use XEP-0260 (Jingle Socks5 Bytestreams Transport)? > > I want to avoid using relay as much as possible, because its going to be a long lived connection (The transport I am using is Host Identity Protocol, it gives me a TCP connection over UDP, which has a higher chance of traversing NAT) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmeyer at tzi.de Tue Dec 15 08:58:51 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Tue, 15 Dec 2009 15:58:51 +0100 Subject: [Jingle] Jingle e2e session establishment and security In-Reply-To: <615616950912101612v3a2a5118wf9ca56c9624a3165@mail.gmail.com> (Suresh Kumar's message of "Fri, 11 Dec 2009 02:12:07 +0200") References: <4b21324c.02135e0a.422b.ffff8316@mx.google.com> <1260474241.27156.1.camel@sagittarius> <615616950912101612v3a2a5118wf9ca56c9624a3165@mail.gmail.com> Message-ID: <87ocm0gu6s.fsf@tzi.de> Suresh Kumar wrote: > On Thu, Dec 10, 2009 at 9:44 PM, Marcus Lundblad wrote: > >> tor 2009-12-10 klockan 19:39 +0200 skrev Suresh Kumar: >> > > >> > * Or just hack up the XEP-0234(Jingle File Transfer) to use a new >> > transport method "urn:xmpp:jingle:transports:my-transport:0". >> > >> >> Why not use XEP-0260 (Jingle Socks5 Bytestreams Transport)? >> > I want to avoid using relay as much as possible, because its going to > be a long lived connection (The transport I am using is Host Identity > Protocol, it gives me a TCP connection over UDP, which has a higher > chance of traversing NAT) Someone is using HIP? Wow, never saw that coming :) For TCP over UDP in some way, XEP-0260 supports the usage of Teredo which in fact is based on UDP. If both clients have no "real" public IPv6 address, the traffic is routed directly with something similar to STUN between the hosts. Dirk -- Computer Science: solving today's problems tomorrow. From sureshkumar.pp at gmail.com Tue Dec 15 09:13:36 2009 From: sureshkumar.pp at gmail.com (Suresh Kumar) Date: Tue, 15 Dec 2009 17:13:36 +0200 Subject: [Jingle] Jingle e2e session establishment and security In-Reply-To: <87ocm0gu6s.fsf@tzi.de> References: <4b21324c.02135e0a.422b.ffff8316@mx.google.com> <1260474241.27156.1.camel@sagittarius> <615616950912101612v3a2a5118wf9ca56c9624a3165@mail.gmail.com> <87ocm0gu6s.fsf@tzi.de> Message-ID: <4b27a789.0f345e0a.324c.516d@mx.google.com> At Tue, 15 Dec 2009 15:58:51 +0100, Dirk Meyer wrote: > > Someone is using HIP? Wow, never saw that coming :) > :) I am working in a group that is closer to the one doing HIP work. > For TCP over UDP in some way, XEP-0260 supports the usage of Teredo > which in fact is based on UDP. If both clients have no "real" public > IPv6 address, the traffic is routed directly with something similar to > STUN between the hosts. > thanks, somehow I seem to have missed teredo option in XEP-0260. I will think about it. On the other hand, you seem to have spent quite a bit of time on this issue(e2e connectivity and security). Do you have any other suggestion in the method I am following? Thanks, Suresh From paulrw at codian.com Wed Dec 23 11:52:36 2009 From: paulrw at codian.com (Paul Witty) Date: Wed, 23 Dec 2009 17:52:36 +0000 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B02F84A.4060404@stpeter.im> References: <4B02F84A.4060404@stpeter.im> Message-ID: <4B3258E4.8030402@codian.com> Peter Saint-Andre wrote: > I've uploaded preliminary 1.1 versions of XEPs 166, 167, and 177: > Just spotted an incorrect link in 167: "IANA Session Description Protocol Parameters Registry" is linking to http://www.iana.org/assignments/ssh-parameters instead of "http://www.iana.org/assignments/sdp-parameters" -- Paul From stpeter at stpeter.im Wed Dec 23 12:06:39 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 23 Dec 2009 11:06:39 -0700 Subject: [Jingle] 1.1 XEPs (166, 167, 177) In-Reply-To: <4B3258E4.8030402@codian.com> References: <4B02F84A.4060404@stpeter.im> <4B3258E4.8030402@codian.com> Message-ID: <4B325C2F.5050208@stpeter.im> On 12/23/09 10:52 AM, Paul Witty wrote: > Peter Saint-Andre wrote: >> I've uploaded preliminary 1.1 versions of XEPs 166, 167, and 177: >> > > Just spotted an incorrect link in 167: "IANA Session Description > Protocol Parameters Registry" is linking to > http://www.iana.org/assignments/ssh-parameters instead of > "http://www.iana.org/assignments/sdp-parameters" Bad copy and paste in xep.ent. Fixed. -------------- 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: From stpeter at stpeter.im Wed Dec 23 16:15:50 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 23 Dec 2009 15:15:50 -0700 Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0166 (Jingle)] Message-ID: <4B329696.2020401@stpeter.im> Jingle bells! See also: http://mail.jabber.org/pipermail/standards/2009-December/022968.html http://mail.jabber.org/pipermail/standards/2009-December/022969.html -------- Original Message -------- Subject: [Standards] UPDATED: XEP-0166 (Jingle) Date: Wed, 23 Dec 2009 16:06:15 -0600 From: XMPP Extensions Editor Reply-To: XMPP Standards To: standards at xmpp.org Version 1.1 of XEP-0166 (Jingle) has been released. Abstract: This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file transfer) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports). Changelog: Specified handling of duplicate name attributes on content element; clarified recommended usage of Jingle when exchanging multiple content-types; declared the principle that application types ought not to be mixed beyond necessity within a single session; clarified use of the reason element in cases other than termination. (psa/jjh) Diff: temporarily unavailable URL: http://xmpp.org/extensions/xep-0166.html -------------- 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: