From dmeyer at tzi.de  Thu Oct  1 06:26:20 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 01 Oct 2009 13:26:20 +0200
Subject: [Jingle] Fwd: Application referrals - GROBJ
In-Reply-To: <9555.1254345549.761395@puncture> (Dave Cridland's message of
	"Wed, 30 Sep 2009 22:19:09 +0100")
References: <9555.1254345549.761395@puncture>
Message-ID: <87hbujicdf.fsf@tzi.de>

Dave Cridland wrote:
> FYI, I thought this might be interesting from the point of view of
> XMPP/Jingle, whether filesharing or VOIP or whatever.
>
> It's also got an impressive sounding name.

I have no time to read the draft right now, but isn't that the reason we
have HIP (Host Identification Protocol)?


Dirk

-- 
It's the same old story; boy meets beer, boy drinks beer... boy gets
another beer.
		-- Cheers

From stpeter at stpeter.im  Tue Oct  6 08:45:29 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 06 Oct 2009 07:45:29 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0251 (Jingle Session
	Transfer)]
Message-ID: <4ACB49F9.2060305@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

- -------- Original Message --------
Subject: [Standards] UPDATED: XEP-0251 (Jingle Session Transfer)
Date: Mon, 05 Oct 2009 17:41:57 -0500
From: XMPP Extensions Editor <editor at xmpp.org>
Reply-To: XMPP Standards <standards at xmpp.org>
To: standards at xmpp.org

Version 0.2 of XEP-0251 (Jingle Session Transfer) has been released.

Abstract: This specification defines an extension to XMPP Jingle for
transferring a session (such as a voice call) from one person to another.

Changelog: Updated examples; added reference to RFC 5359; added security
considerations regarding unattended transfer. (psa)

Diff:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0251.xml?r1=3251&r2=3494

URL: http://xmpp.org/extensions/xep-0251.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrLSfkACgkQNL8k5A2w/vyWEQCdFToe6B614JEOJV/pJ3+koHuR
IQQAoKl5H1B/EnzrBOBS21CSaHDZBI/5
=ZzH4
-----END PGP SIGNATURE-----

From ml at update.uu.se  Tue Oct  6 15:49:46 2009
From: ml at update.uu.se (Marcus Lundblad)
Date: Tue, 06 Oct 2009 22:49:46 +0200
Subject: [Jingle] S5B and MUCs
Message-ID: <1254862186.1423.4.camel@sagittarius>

There was some discussions about the inability of using S5B (jingle or
SI) within MUCs, since the receiver will not see the other party's
actual JID, thus they will generate different "hostnames" for the stream
connection (SHA1 hash of SID+Iniator JID+Receiver JID).

Could we not just specify that the hash of the Jingle session ID (sid)
should be used in the case of XEP-0260?
This would make it unambigious as what to send and expect for both
parties, AFAICS.
Or am I missing something here?

//Marcus


From justin at affinix.com  Tue Oct  6 16:29:23 2009
From: justin at affinix.com (Justin Karneges)
Date: Tue, 6 Oct 2009 14:29:23 -0700
Subject: [Jingle] S5B and MUCs
In-Reply-To: <1254862186.1423.4.camel@sagittarius>
References: <1254862186.1423.4.camel@sagittarius>
Message-ID: <200910061429.23314.justin@affinix.com>

On Tuesday 06 October 2009 13:49:46 Marcus Lundblad wrote:
> There was some discussions about the inability of using S5B (jingle or
> SI) within MUCs, since the receiver will not see the other party's
> actual JID, thus they will generate different "hostnames" for the stream
> connection (SHA1 hash of SID+Iniator JID+Receiver JID).
>
> Could we not just specify that the hash of the Jingle session ID (sid)
> should be used in the case of XEP-0260?
> This would make it unambigious as what to send and expect for both
> parties, AFAICS.
> Or am I missing something here?

Obviously if we change the way to generate the hash then the problem is 
solved.  You are not missing anything there.  I guess nobody cared to propose 
such a solution yet.

You propose hashing the sid instead of sid+jids.  This would fix it, but I 
wonder what drawback that has.  Certainly the jids were hashed for a reason.

-Justin

From olivier.crete at collabora.co.uk  Thu Oct  8 16:38:33 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Thu, 08 Oct 2009 17:38:33 -0400
Subject: [Jingle] Call forking
Message-ID: <1255037913.2787.15.camel@TesterTop3.tester.ca>

Hi,

If a contact I'm trying to call has multiple online resources. I want to
call it, currently Gabble, our XMPP implementation, just picks one more
or less randomly and tries to call it. I think the right approach is to
do something like SIP forking, that is, try to call both and when one
answers, cancel the other calls. The problem is that the non-answering
resources will see it as a missed call. Maybe we should add a
"answered-somewhere-else" reason for that case. Or is it what "cancel"
or "success" are for ?


-- 
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: <http://mail.jabber.org/pipermail/jingle/attachments/20091008/838a2b5e/attachment.pgp>

From xramtsov at gmail.com  Thu Oct  8 19:35:18 2009
From: xramtsov at gmail.com (Evgeniy Khramtsov)
Date: Fri, 09 Oct 2009 10:35:18 +1000
Subject: [Jingle] Call forking
In-Reply-To: <1255037913.2787.15.camel@TesterTop3.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
Message-ID: <4ACE8546.9060305@gmail.com>

Olivier Cr?te wrote:
> If a contact I'm trying to call has multiple online resources. I want to
> call it, currently Gabble, our XMPP implementation, just picks one more
> or less randomly and tries to call it.

Why not just call to a high priority resource?
> I think the right approach is to do something like SIP forking

SIP forking sucks. We do not need it in XMPP: we have resources and 
priorities.

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.


From olivier.crete at collabora.co.uk  Thu Oct  8 21:10:08 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Thu, 08 Oct 2009 22:10:08 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4ACE8546.9060305@gmail.com>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACE8546.9060305@gmail.com>
Message-ID: <1255054208.14132.7.camel@TesterBox.tester.ca>

On Fri, 2009-10-09 at 10:35 +1000, Evgeniy Khramtsov wrote:
> Olivier Cr?te wrote:
> > If a contact I'm trying to call has multiple online resources. I want to
> > call it, currently Gabble, our XMPP implementation, just picks one more
> > or less randomly and tries to call it.
> 
> Why not just call to a high priority resource?

Ok, I have a phone that does XMPP and a computer on my desk.. which one
should you call ? Any random one ?

> > I think the right approach is to do something like SIP forking
> 
> SIP forking sucks. We do not need it in XMPP: we have resources and 
> priorities.

Forking is required because I have multiple devices.

-- 
Olivier Cr?te
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- 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: <http://mail.jabber.org/pipermail/jingle/attachments/20091008/133cd1c9/attachment.pgp>

From florian.zeitz at gmx.de  Thu Oct  8 22:26:02 2009
From: florian.zeitz at gmx.de (Florian Zeitz)
Date: Fri, 09 Oct 2009 05:26:02 +0200
Subject: [Jingle] Call forking
In-Reply-To: <1255054208.14132.7.camel@TesterBox.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4ACE8546.9060305@gmail.com>
	<1255054208.14132.7.camel@TesterBox.tester.ca>
Message-ID: <4ACEAD4A.7070407@gmx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Cr?te schrieb:
> On Fri, 2009-10-09 at 10:35 +1000, Evgeniy Khramtsov wrote:
>> Olivier Cr?te wrote:
>>> If a contact I'm trying to call has multiple online resources. I want to
>>> call it, currently Gabble, our XMPP implementation, just picks one more
>>> or less randomly and tries to call it.
>> Why not just call to a high priority resource?
> 
> Ok, I have a phone that does XMPP and a computer on my desk.. which one
> should you call ? Any random one ?
> 
He answered that already. The one with the higher priority.
Normal use would be to set the phone to the higher priority, because
you'll only be online with that when you're not on your desktop I guess.

If what you're saying is that you want chat messages to go to your
desktop PC and calls to your phone, because the user-experience is
better we might have to find another solution for that indeed (the easy
one would be to just not advertise support from your desktop computer).

>>> I think the right approach is to do something like SIP forking
>> SIP forking sucks. We do not need it in XMPP: we have resources and 
>> priorities.
> 
> Forking is required because I have multiple devices.
> 
That's just not true as such.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrOrUoACgkQ0JXcdjR+9YT5IwCgtaCrTb/9HmKBcGb4KUOxe5Pf
8f8AnjE+o1ivwDwGviYqnPj/titPQjYx
=Wkge
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Thu Oct  8 22:48:55 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 08 Oct 2009 21:48:55 -0600
Subject: [Jingle] Call forking
In-Reply-To: <1255037913.2787.15.camel@TesterTop3.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
Message-ID: <4ACEB2A7.3000003@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/8/09 3:38 PM, Olivier Cr?te wrote:
> Hi,
> 
> If a contact I'm trying to call has multiple online resources. I want to
> call it, currently Gabble, our XMPP implementation, just picks one more
> or less randomly and tries to call it. 

Randomly? Without first determining which resources support Jingle?

> I think the right approach is to
> do something like SIP forking, that is, try to call both and when one
> answers, cancel the other calls. 

And how well has forking worked out? Most SIP experts I've talked with
have said "avoid forking in Jingle if you possibly can".

> The problem is that the non-answering
> resources will see it as a missed call. Maybe we should add a
> "answered-somewhere-else" reason for that case. Or is it what "cancel"
> or "success" are for ?

That's one possibility. Another is XEP-0168, although people don't seem
to like that approach.

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrOsqcACgkQNL8k5A2w/vzn5wCfXHe/J1sY3TMRdhwWXmKPM1xQ
uLQAn1VOuhm1+IhaMf2H5pg5l4lbb7OE
=plaf
-----END PGP SIGNATURE-----

From olivier.crete at collabora.co.uk  Thu Oct  8 23:19:16 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Fri, 09 Oct 2009 00:19:16 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4ACEB2A7.3000003@stpeter.im>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>
Message-ID: <1255061956.9653.4.camel@TesterBox.tester.ca>

On Thu, 2009-10-08 at 21:48 -0600, Peter Saint-Andre wrote:
> On 10/8/09 3:38 PM, Olivier Cr?te wrote:
> > Hi,
> > 
> > If a contact I'm trying to call has multiple online resources. I want to
> > call it, currently Gabble, our XMPP implementation, just picks one more
> > or less randomly and tries to call it. 
> 
> Randomly? Without first determining which resources support Jingle?

Well, randomly between all the resources that support jingle, but for
the end user, it seems pretty random. If my mom has a N900 and any user
friendly XMPP client (like Google Talk), she has no idea what these
priority things are.

> > I think the right approach is to
> > do something like SIP forking, that is, try to call both and when one
> > answers, cancel the other calls. 
> 
> And how well has forking worked out? Most SIP experts I've talked with
> have said "avoid forking in Jingle if you possibly can".

I'm not advocating doing forking, just calling all the possible
resources. But yes, it is a bit like forking, without the madness (since
the caller would  really be doing separate calls).

> > The problem is that the non-answering
> > resources will see it as a missed call. Maybe we should add a
> > "answered-somewhere-else" reason for that case. Or is it what "cancel"
> > or "success" are for ?
> 
> That's one possibility. Another is XEP-0168, although people don't seem
> to like that approach.

Priority seems like a crap idea because it forces user configuration and
doesn't solve the problem of having multiple hardware devices with the
same account.

-- 
Olivier Cr?te
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- 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: <http://mail.jabber.org/pipermail/jingle/attachments/20091009/c08c1b0f/attachment.pgp>

From juberti at google.com  Thu Oct  8 23:57:56 2009
From: juberti at google.com (Justin Uberti)
Date: Thu, 8 Oct 2009 21:57:56 -0700
Subject: [Jingle] Call forking
In-Reply-To: <1255061956.9653.4.camel@TesterBox.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca> 
	<4ACEB2A7.3000003@stpeter.im>
	<1255061956.9653.4.camel@TesterBox.tester.ca>
Message-ID: <bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>

My experience is that in practice, forking is the only comprehensive
solution. I was against forking for a long time but I really think it is
what the user expects to happen.
Our current approach at Google is to identify the most recently active
capable client and send the call there, but we sometimes we get it wrong,
perhaps because the user has just left their desk/switched browser tabs/etc.

Calling all endpoints and then sending a terminate message with a "cancel"
reason to the other endpoints seems like a reasonable approach. Doing ICE in
this situation may be very complicated though.

--justin

2009/10/8 Olivier Cr?te <olivier.crete at collabora.co.uk>

> On Thu, 2009-10-08 at 21:48 -0600, Peter Saint-Andre wrote:
> > On 10/8/09 3:38 PM, Olivier Cr?te wrote:
> > > Hi,
> > >
> > > If a contact I'm trying to call has multiple online resources. I want
> to
> > > call it, currently Gabble, our XMPP implementation, just picks one more
> > > or less randomly and tries to call it.
> >
> > Randomly? Without first determining which resources support Jingle?
>
> Well, randomly between all the resources that support jingle, but for
> the end user, it seems pretty random. If my mom has a N900 and any user
> friendly XMPP client (like Google Talk), she has no idea what these
> priority things are.
>
> > > I think the right approach is to
> > > do something like SIP forking, that is, try to call both and when one
> > > answers, cancel the other calls.
> >
> > And how well has forking worked out? Most SIP experts I've talked with
> > have said "avoid forking in Jingle if you possibly can".
>
> I'm not advocating doing forking, just calling all the possible
> resources. But yes, it is a bit like forking, without the madness (since
> the caller would  really be doing separate calls).
>
> > > The problem is that the non-answering
> > > resources will see it as a missed call. Maybe we should add a
> > > "answered-somewhere-else" reason for that case. Or is it what "cancel"
> > > or "success" are for ?
> >
> > That's one possibility. Another is XEP-0168, although people don't seem
> > to like that approach.
>
> Priority seems like a crap idea because it forces user configuration and
> doesn't solve the problem of having multiple hardware devices with the
> same account.
>
> --
> Olivier Cr?te
> olivier.crete at collabora.co.uk
> Collabora Ltd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091008/063fd320/attachment.htm>

From diana-liste at null.ro  Mon Oct 12 12:10:56 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Mon, 12 Oct 2009 20:10:56 +0300
Subject: [Jingle] Call forking
In-Reply-To: <bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
Message-ID: <4AD36320.7060005@null.ro>

Hello,

I do agree that forking is what user is expecting, but instead of doing 
something like SIP fork, we are using inteligent jabber servers.
If i want to support fork, i will prefer to keep a list of user devices 
and call each one.
The real problem is not with the jabber server and the user, the real 
problem is with the other end.
Let's assume i call you Justin and you have 2 devices. One device is 
suppose to send me some early media telling me that you just went on a 
very long kayaking trip and the second one doesn't have early media and 
is sending ringing. Which one my client will play the important one or 
the ringing one?
Think about that when I'm calling you from a PSTN phone, where i don't 
get any other indication than ringing.

I do believe that forking it's a great idea, but implemented in the 
server where the user can have a smart web interface to make decisions, 
not a dumb fork in the protocol.

Regards,
Diana

P.S. -1 for forking in jingle.

Justin Uberti wrote:
> My experience is that in practice, forking is the only comprehensive 
> solution. I was against forking for a long time but I really think it 
> is what the user expects to happen.
>
> Our current approach at Google is to identify the most recently active 
> capable client and send the call there, but we sometimes we get it 
> wrong, perhaps because the user has just left their desk/switched 
> browser tabs/etc.
>
> Calling all endpoints and then sending a terminate message with a 
> "cancel" reason to the other endpoints seems like a reasonable 
> approach. Doing ICE in this situation may be very complicated though.
>
> --justin
>
> 2009/10/8 Olivier Cr?te <olivier.crete at collabora.co.uk 
> <mailto:olivier.crete at collabora.co.uk>>
>
>     On Thu, 2009-10-08 at 21:48 -0600, Peter Saint-Andre wrote:
>     > On 10/8/09 3:38 PM, Olivier Cr?te wrote:
>     > > Hi,
>     > >
>     > > If a contact I'm trying to call has multiple online resources.
>     I want to
>     > > call it, currently Gabble, our XMPP implementation, just picks
>     one more
>     > > or less randomly and tries to call it.
>     >
>     > Randomly? Without first determining which resources support Jingle?
>
>     Well, randomly between all the resources that support jingle, but for
>     the end user, it seems pretty random. If my mom has a N900 and any
>     user
>     friendly XMPP client (like Google Talk), she has no idea what these
>     priority things are.
>
>     > > I think the right approach is to
>     > > do something like SIP forking, that is, try to call both and
>     when one
>     > > answers, cancel the other calls.
>     >
>     > And how well has forking worked out? Most SIP experts I've
>     talked with
>     > have said "avoid forking in Jingle if you possibly can".
>
>     I'm not advocating doing forking, just calling all the possible
>     resources. But yes, it is a bit like forking, without the madness
>     (since
>     the caller would  really be doing separate calls).
>
>     > > The problem is that the non-answering
>     > > resources will see it as a missed call. Maybe we should add a
>     > > "answered-somewhere-else" reason for that case. Or is it what
>     "cancel"
>     > > or "success" are for ?
>     >
>     > That's one possibility. Another is XEP-0168, although people
>     don't seem
>     > to like that approach.
>
>     Priority seems like a crap idea because it forces user
>     configuration and
>     doesn't solve the problem of having multiple hardware devices with the
>     same account.
>
>     --
>     Olivier Cr?te
>     olivier.crete at collabora.co.uk <mailto:olivier.crete at collabora.co.uk>
>     Collabora Ltd
>
>


From olivier.crete at collabora.co.uk  Mon Oct 12 12:31:24 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Mon, 12 Oct 2009 13:31:24 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4AD36320.7060005@null.ro>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD36320.7060005@null.ro>
Message-ID: <1255368684.17363.44.camel@TesterTop3.tester.ca>

On Mon, 2009-10-12 at 20:10 +0300, Diana Cionoiu wrote:
> Hello,
> 
> I do agree that forking is what user is expecting, but instead of doing 
> something like SIP fork, we are using inteligent jabber servers.
> If i want to support fork, i will prefer to keep a list of user devices 
> and call each one.

I agree

> Let's assume i call you Justin and you have 2 devices. One device is 
> suppose to send me some early media telling me that you just went on a 
> very long kayaking trip and the second one doesn't have early media and 
> is sending ringing. Which one my client will play the important one or 
> the ringing one?

Shouldn't the device that has something important to say just answer the
call?.. Or maybe you want the user to be able to still answer from a
different device? I guess you still have the problem if you get
early-media ringing tone from more than one peer.

> I do believe that forking it's a great idea, but implemented in the 
> server where the user can have a smart web interface to make decisions, 
> not a dumb fork in the protocol.

How do you suggest implementing it in the server? Should the server just
pick on device or should it notify both devices that there is a call?
How exactly? Etc.

> Regards,
> Diana
> 
> P.S. -1 for forking in jingle.
> 
> Justin Uberti wrote:
> > My experience is that in practice, forking is the only comprehensive 
> > solution. I was against forking for a long time but I really think it 
> > is what the user expects to happen.
> >
> > Our current approach at Google is to identify the most recently active 
> > capable client and send the call there, but we sometimes we get it 
> > wrong, perhaps because the user has just left their desk/switched 
> > browser tabs/etc.
> >
> > Calling all endpoints and then sending a terminate message with a 
> > "cancel" reason to the other endpoints seems like a reasonable 
> > approach. Doing ICE in this situation may be very complicated though.
> >
> > --justin
> >
> > 2009/10/8 Olivier Cr?te <olivier.crete at collabora.co.uk 
> > <mailto:olivier.crete at collabora.co.uk>>
> >
> >     On Thu, 2009-10-08 at 21:48 -0600, Peter Saint-Andre wrote:
> >     > On 10/8/09 3:38 PM, Olivier Cr?te wrote:
> >     > > Hi,
> >     > >
> >     > > If a contact I'm trying to call has multiple online resources.
> >     I want to
> >     > > call it, currently Gabble, our XMPP implementation, just picks
> >     one more
> >     > > or less randomly and tries to call it.
> >     >
> >     > Randomly? Without first determining which resources support Jingle?
> >
> >     Well, randomly between all the resources that support jingle, but for
> >     the end user, it seems pretty random. If my mom has a N900 and any
> >     user
> >     friendly XMPP client (like Google Talk), she has no idea what these
> >     priority things are.
> >
> >     > > I think the right approach is to
> >     > > do something like SIP forking, that is, try to call both and
> >     when one
> >     > > answers, cancel the other calls.
> >     >
> >     > And how well has forking worked out? Most SIP experts I've
> >     talked with
> >     > have said "avoid forking in Jingle if you possibly can".
> >
> >     I'm not advocating doing forking, just calling all the possible
> >     resources. But yes, it is a bit like forking, without the madness
> >     (since
> >     the caller would  really be doing separate calls).
> >
> >     > > The problem is that the non-answering
> >     > > resources will see it as a missed call. Maybe we should add a
> >     > > "answered-somewhere-else" reason for that case. Or is it what
> >     "cancel"
> >     > > or "success" are for ?
> >     >
> >     > That's one possibility. Another is XEP-0168, although people
> >     don't seem
> >     > to like that approach.
> >
> >     Priority seems like a crap idea because it forces user
> >     configuration and
> >     doesn't solve the problem of having multiple hardware devices with the
> >     same account.
> >
> >     --
> >     Olivier Cr?te
> >     olivier.crete at collabora.co.uk <mailto:olivier.crete at collabora.co.uk>
> >     Collabora Ltd
> >
> >
> 
-- 
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: <http://mail.jabber.org/pipermail/jingle/attachments/20091012/d54e5742/attachment.pgp>

From diana-liste at null.ro  Tue Oct 13 10:53:42 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Tue, 13 Oct 2009 18:53:42 +0300
Subject: [Jingle] Call forking
In-Reply-To: <1255368684.17363.44.camel@TesterTop3.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>	<4AD36320.7060005@null.ro>
	<1255368684.17363.44.camel@TesterTop3.tester.ca>
Message-ID: <4AD4A286.7050801@null.ro>

Hello Olivier,

On Mon, 12 Oct 2009, Olivier Cr?te wrote:

> On Mon, 2009-10-12 at 20:10 +0300, Diana Cionoiu wrote:
>> Hello,
>>
>> I do agree that forking is what user is expecting, but instead of doing
>> something like SIP fork, we are using inteligent jabber servers.
>> If i want to support fork, i will prefer to keep a list of user devices
>> and call each one.
>
> I agree
>
>> Let's assume i call you Justin and you have 2 devices. One device is
>> suppose to send me some early media telling me that you just went on a
>> very long kayaking trip and the second one doesn't have early media and
>> is sending ringing. Which one my client will play the important one or
>> the ringing one?
>
> Shouldn't the device that has something important to say just answer the
> call?.. Or maybe you want the user to be able to still answer from a
> different device? I guess you still have the problem if you get
> early-media ringing tone from more than one peer.

The real problem is that for example in Yate a user can have a Jingle 
device and a SIP device or multiple SIP devices including a PSTN number.

So we setup those priorities allowing the user to connect to a web 
interface and setup how him wants his devices to be called.
This allows the user to have different ringing algorithms like call 
jingle first, than sip and than pstn for example.

>> I do believe that forking it's a great idea, but implemented in the
>> server where the user can have a smart web interface to make decisions,
>> not a dumb fork in the protocol.
>
> How do you suggest implementing it in the server? Should the server just
> pick on device or should it notify both devices that there is a call?
> How exactly? Etc.

The point is to split the call in case you want to do that. And to keep 
2 call legs in the jabber server.
The major problem is not only early media, but what happends when 2 
devices are ringing for example and one it's answering. Then the other 
end which started the call will have to send a CANCEL (in SIP) to all 
the other devices. But the one that started the mess is the other Jabber 
server, so the initial Jingle client or gateway will have to implement 
the actual forking.

This is why in SIP forking it's almost always in the end implemented 
with inteligent servers, because the SIP gateways (like Yate) will have 
to implement forking while forking is the fault of a SIP proxy.


>> Regards,
>> Diana
>>
>> P.S. -1 for forking in jingle.
>>
> -- 
> Olivier Cr?te
> olivier.crete at collabora.co.uk

Diana

From sjoerd.simons at collabora.co.uk  Tue Oct 13 12:06:07 2009
From: sjoerd.simons at collabora.co.uk (Sjoerd Simons)
Date: Tue, 13 Oct 2009 13:06:07 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4AD36320.7060005@null.ro>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>
	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD36320.7060005@null.ro>
Message-ID: <20091013170607.GA5942@night.luon.net>


On Mon, Oct 12, 2009 at 08:10:56PM +0300, Diana Cionoiu wrote:
> Justin Uberti wrote:
> >My experience is that in practice, forking is the only
> >comprehensive solution. I was against forking for a long time but
> >I really think it is what the user expects to happen.
> >
> >Our current approach at Google is to identify the most recently
> >active capable client and send the call there, but we sometimes we
> >get it wrong, perhaps because the user has just left their
> >desk/switched browser tabs/etc.

That's what Gabble does as well. Unfortunately when phones come into the mix
this falls apart. A phone is usually available all the time, but usually not
very active (or at least not the most active client).

At least for my personal use-case i don't think it's solvable without call
forking (or fork-like) behaviour. I tend to use my laptop in various places,
also i expect to basically always have my phone with me which is signed into
XMPP. Both of this seems reasonably and quite common. Now which device i want
to take phonecalls on depends mostly on whether i have a headset attached to my
laptop or not (if i have, then the laptop is preferred, otherwise the phone).
On the other hand some calls i might want to take on the phone so i can
easily walk away to a more private area then my desk in the office.

What this means is that you basically can't decide things beforehand, so
neither priorities nor resource application priority would work..

> >Calling all endpoints and then sending a terminate message with a
> >"cancel" reason to the other endpoints seems like a reasonable
> >approach. Doing ICE in this situation may be very complicated
> >though.

You need to start setting up ICE sessions to all end-points, which isn't
necessarily complicated imho, just a lot of extra potentially non-necessary
work and packets flowing around :(

> I do agree that forking is what user is expecting, but instead of
> doing something like SIP fork, we are using inteligent jabber
> servers.

The xmpp server shouldn't plan any part in the setup of a jingle session.

> If i want to support fork, i will prefer to keep a list of user devices and
> call each one.  The real problem is not with the jabber server and the user,
> the real problem is with the other end.  Let's assume i call you Justin and
> you have 2 devices. One device is suppose to send me some early media telling
> me that you just went on a very long kayaking trip and the second one doesn't
> have early media and is sending ringing. Which one my client will play the
> important one or the ringing one?

That seems quite far-fetched. First of all, not all jingle clients support
early-media (i'm not sure any does atm), so having information in
your early media doesn't seem like a great idea. I would assume that if Justin
went on a long kayaking trip, he'd set his status to extended away with a
status message indicating this :)

In case you do call multiple clients in parallel, things will generally be
unsolvable when multiple ones send earlier-media, you'll just have to pick.

> Think about that when I'm calling you from a PSTN phone, where i
> don't get any other indication than ringing.
> 
> I do believe that forking it's a great idea, but implemented in the
> server where the user can have a smart web interface to make
> decisions, not a dumb fork in the protocol.

Things i really don't want to do while calling or being called includes going
to a website to decide on which device to use :)

  Sjoerd
-- 
The devil finds work for idle circuits to do.

From diana-liste at null.ro  Tue Oct 13 15:27:47 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Tue, 13 Oct 2009 23:27:47 +0300 (EEST)
Subject: [Jingle] Call forking
In-Reply-To: <20091013170607.GA5942@night.luon.net>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>
	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD36320.7060005@null.ro> <20091013170607.GA5942@night.luon.net>
Message-ID: <Pine.LNX.4.64.0910132327160.21293@dragoshel>

Hello,

On Tue, 13 Oct 2009, Sjoerd Simons wrote:

> 
> On Mon, Oct 12, 2009 at 08:10:56PM +0300, Diana Cionoiu wrote:
> > Justin Uberti wrote:
> > > My experience is that in practice, forking is the only
> > > comprehensive solution. I was against forking for a long time but
> > > I really think it is what the user expects to happen.
> > > 
> > > Our current approach at Google is to identify the most recently
> > > active capable client and send the call there, but we sometimes we
> > > get it wrong, perhaps because the user has just left their
> > > desk/switched browser tabs/etc.
> 
> That's what Gabble does as well. Unfortunately when phones come into the
> mix
> this falls apart. A phone is usually available all the time, but usually
> not
> very active (or at least not the most active client).
> 
> At least for my personal use-case i don't think it's solvable without call
> forking (or fork-like) behaviour. I tend to use my laptop in various
> places,
> also i expect to basically always have my phone with me which is signed
> into
> XMPP. Both of this seems reasonably and quite common. Now which device i
> want
> to take phonecalls on depends mostly on whether i have a headset attached
> to my
> laptop or not (if i have, then the laptop is preferred, otherwise the
> phone).
> On the other hand some calls i might want to take on the phone so i can
> easily walk away to a more private area then my desk in the office.
> 
> What this means is that you basically can't decide things beforehand, so
> neither priorities nor resource application priority would work..

You seems to ignore the situation of the phone that has to handle a fork
from the other end.
What's happening when the person answers to one of the devices on the other
end?
What's happening if i don't want to call all the devices or I have a device
that is not XMPP?

> > > Calling all endpoints and then sending a terminate message with a
> > > "cancel" reason to the other endpoints seems like a reasonable
> > > approach. Doing ICE in this situation may be very complicated
> > > though.
> 
> You need to start setting up ICE sessions to all end-points, which isn't
> necessarily complicated imho, just a lot of extra potentially
> non-necessary
> work and packets flowing around :(
> 
> > I do agree that forking is what user is expecting, but instead of
> > doing something like SIP fork, we are using inteligent jabber
> > servers.
> 
> The xmpp server shouldn't plan any part in the setup of a jingle session.

That's for each implementation to decide.

> > If i want to support fork, i will prefer to keep a list of user devices
> > and
> > call each one.  The real problem is not with the jabber server and the
> > user,
> > the real problem is with the other end.  Let's assume i call you Justin
> > and
> > you have 2 devices. One device is suppose to send me some early media
> > telling
> > me that you just went on a very long kayaking trip and the second one
> > doesn't
> > have early media and is sending ringing. Which one my client will play
> > the
> > important one or the ringing one?
> 
> That seems quite far-fetched. First of all, not all jingle clients support
> early-media (i'm not sure any does atm), so having information in
> your early media doesn't seem like a great idea. I would assume that if
> Justin
> went on a long kayaking trip, he'd set his status to extended away with a
> status message indicating this :)

There is at least one, Yate which supports early media. Without early media
you can't make any PSTN phone calls, because you will not catch nice
messages like "the user is not in the covered area" or "the user is busy at
the moment".

> In case you do call multiple clients in parallel, things will generally be
> unsolvable when multiple ones send earlier-media, you'll just have to
> pick.

Therefor the end user has to be able to make a decision for his devices, it
shouldn't be a default behavior.

> > Think about that when I'm calling you from a PSTN phone, where i
> > don't get any other indication than ringing.
> > 
> > I do believe that forking it's a great idea, but implemented in the
> > server where the user can have a smart web interface to make
> > decisions, not a dumb fork in the protocol.
> 
> Things i really don't want to do while calling or being called includes
> going
> to a website to decide on which device to use :)

Website was just an example on how we do it. I'm sure you can do it over
XMPP or using any other control form for algorithms and priorities.

>  Sjoerd
> -- 
> The devil finds work for idle circuits to do.

Diana
--
The devil is in the details.

From stpeter at stpeter.im  Wed Oct 14 21:02:28 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 14 Oct 2009 19:02:28 -0700
Subject: [Jingle] S5B and MUCs
In-Reply-To: <200910061429.23314.justin@affinix.com>
References: <1254862186.1423.4.camel@sagittarius>
	<200910061429.23314.justin@affinix.com>
Message-ID: <4AD682B4.5040201@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/6/09 2:29 PM, Justin Karneges wrote:
> On Tuesday 06 October 2009 13:49:46 Marcus Lundblad wrote:
>> There was some discussions about the inability of using S5B (jingle or
>> SI) within MUCs, since the receiver will not see the other party's
>> actual JID, thus they will generate different "hostnames" for the stream
>> connection (SHA1 hash of SID+Iniator JID+Receiver JID).
>>
>> Could we not just specify that the hash of the Jingle session ID (sid)
>> should be used in the case of XEP-0260?
>> This would make it unambigious as what to send and expect for both
>> parties, AFAICS.
>> Or am I missing something here?
> 
> Obviously if we change the way to generate the hash then the problem is 
> solved.  You are not missing anything there.  I guess nobody cared to propose 
> such a solution yet.
> 
> You propose hashing the sid instead of sid+jids.  This would fix it, but I 
> wonder what drawback that has.  Certainly the jids were hashed for a reason.

If I recall correctly, the idea was that even if a MITM gains access to
the SID, he can't fake the target's "from" address when sending to the
proxy. Using only the SID weakens the security profile a bit. Whether we
are deeply concerned about MITM attacks here is another question. Maybe
we could use the SID but specify that you should encrypt the signalling
to ensure that a MITM could not masquerade as the target. That does not
help during bootstrapping of an XTLS session, though. Another approach
would be to say that you hash either the SID+Initiator+Target or the
mere SID, and the proxy needs to check both. (Another potential security
problem is the lack of hash agility here...)

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrWgrQACgkQNL8k5A2w/vwGsACgh85z8kcLqhmKOz+S/CHfLme0
TPIAn02Qr8Q/9D0ssicnGSBudcRz37BK
=XZiw
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Wed Oct 14 21:07:09 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 14 Oct 2009 19:07:09 -0700
Subject: [Jingle] Call forking
In-Reply-To: <bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
Message-ID: <4AD683CD.30008@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/8/09 9:57 PM, Justin Uberti wrote:
> My experience is that in practice, forking is the only comprehensive
> solution. I was against forking for a long time but I really think it is
> what the user expects to happen.
> 
> Our current approach at Google is to identify the most recently active
> capable client and send the call there, but we sometimes we get it
> wrong, perhaps because the user has just left their desk/switched
> browser tabs/etc.
> 
> Calling all endpoints and then sending a terminate message with a
> "cancel" reason to the other endpoints seems like a reasonable approach.

Well this is basically what Google Talk does for messages, too, right?

> Doing ICE in this situation may be very complicated though.

Not necessarily complicated, I think, just an awful lot of packets. :)

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrWg80ACgkQNL8k5A2w/vzcjACfYh5cpc77i5NwGDDmW1GEQXGy
PbsAnifxumZLAbGvzvUwL5yPNCkHzYfv
=J//y
-----END PGP SIGNATURE-----


From stpeter at stpeter.im  Wed Oct 14 21:09:48 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 14 Oct 2009 19:09:48 -0700
Subject: [Jingle] [Fwd: Re: [MMUSIC] I-D
	Action:draft-ietf-mmusic-ice-tcp-08.txt]
Message-ID: <4AD6846C.2040404@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI. Feel free to speak up on the mmusic list if you care about ICE-TCP
(it might be useful for Jingle file transfer).

/psa

- -------- Original Message --------
Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-08.txt
Date: Tue, 13 Oct 2009 20:58:48 -0400
From: Simon Perreault <simon.perreault at viagenie.ca>
Organization: Viag?nie
To: mmusic at ietf.org
References: <20091014004501.654213A685D at core3.amsl.com>

On Tuesday 13 October 2009 20:45:01 Internet-Drafts at ietf.org wrote:
> 	Title           : TCP Candidates with Interactive Connectivity
> Establishment (ICE) Author(s)       : S. Perreault, J. Rosenberg
> 	Filename        : draft-ietf-mmusic-ice-tcp-08.txt
> 	Pages           : 19
> 	Date            : 2009-10-13

This new revision is an effort to gauge what is the interest in ICE-TCP and
where it should go. There is only one change, the addition of this
paragraph:

      Note: It has been reported that the simultaneous-open technique
      has a low success rate (~40%) with the population of NAT devices
      in use as of this writing.  Therefore, it is RECOMMENDED that
      implementations of this specification acquire and use IPv6 host
      candidates.  Means of doing so across NATs include Tunnel Setup
      Protocol [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380],
      IPSec NAT-T [RFC3947], and others.


Two questions for this WG:

- - Should this effort be dropped or continue?

- - What is needed for this draft to get WG consensus?

Thanks, and sorry for not posting this sooner,
Simon
- --
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrWhGwACgkQNL8k5A2w/vzE9ACgouKRn3xZbwA8uDpyGH3Pk4hM
qHgAn1uFh5cptRWuAK/ZcFCPPZP+vbRq
=7KFj
-----END PGP SIGNATURE-----


From juberti at google.com  Wed Oct 14 23:08:56 2009
From: juberti at google.com (Justin Uberti)
Date: Wed, 14 Oct 2009 21:08:56 -0700
Subject: [Jingle] Call forking
In-Reply-To: <4AD683CD.30008@stpeter.im>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>
	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD683CD.30008@stpeter.im>
Message-ID: <bd0c36130910142108v424cdaa0r11eb743723b2791b@mail.gmail.com>

Yeah, it can probably be worked out; while you will need to be careful
not to saturate the outbound pipe with stun pings, I can't recall the
other complications I was worried about.

On Wednesday, October 14, 2009, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/8/09 9:57 PM, Justin Uberti wrote:
>> My experience is that in practice, forking is the only comprehensive
>> solution. I was against forking for a long time but I really think it is
>> what the user expects to happen.
>>
>> Our current approach at Google is to identify the most recently active
>> capable client and send the call there, but we sometimes we get it
>> wrong, perhaps because the user has just left their desk/switched
>> browser tabs/etc.
>>
>> Calling all endpoints and then sending a terminate message with a
>> "cancel" reason to the other endpoints seems like a reasonable approach.
>
> Well this is basically what Google Talk does for messages, too, right?
>
>> Doing ICE in this situation may be very complicated though.
>
> Not necessarily complicated, I think, just an awful lot of packets. :)
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrWg80ACgkQNL8k5A2w/vzcjACfYh5cpc77i5NwGDDmW1GEQXGy
> PbsAnifxumZLAbGvzvUwL5yPNCkHzYfv
> =J//y
> -----END PGP SIGNATURE-----
>
>

From diana-liste at null.ro  Thu Oct 15 03:20:27 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Thu, 15 Oct 2009 11:20:27 +0300
Subject: [Jingle] Call forking
In-Reply-To: <4AD683CD.30008@stpeter.im>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD683CD.30008@stpeter.im>
Message-ID: <4AD6DB4B.404@null.ro>

Hello Peter,

>>
>> Calling all endpoints and then sending a terminate message with a
>> "cancel" reason to the other endpoints seems like a reasonable approach.
>>     
>
> Well this is basically what Google Talk does for messages, too, right?
>
>   
For a message it's ok to fork it to several clients. For a session you 
have to handle the situation when one endpoint answers the session.
The problem is that the cancel has to be sent by the client that made 
the initial session request which has no idea that will receive more 
than one answer.

>> Doing ICE in this situation may be very complicated though.
>>     
>
> Not necessarily complicated, I think, just an awful lot of packets. :)
>
>   
This approach ignores what's happening when a gateway from a different 
protocol like SIP or H.323 has to do a lot of ICE requests for every 
call it's making. The problem is the actual load of the gateway. This 
will lead to a slower adoption of the Jingle protocol from the equipment 
vendors.
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>   
Diana

From diana-liste at null.ro  Thu Oct 15 04:34:28 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Thu, 15 Oct 2009 12:34:28 +0300
Subject: [Jingle] Call forking
In-Reply-To: <4AD6DB4B.404@null.ro>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>	<4AD683CD.30008@stpeter.im>
	<4AD6DB4B.404@null.ro>
Message-ID: <4AD6ECA4.4060006@null.ro>

Hello,

I have a proposal on how to implement call forking in the jabber way 
instead of the SIP way.

A jingle client wants to call B jingle client

A jingle server probes the B jingle user to find B's resources where B 
can setup his voice priorities.

A jingle client calls all the B jingle client resources

I don't have an exact protocol proposal, but that's the basic concept.

This doesn't work in SIP because SIP doesn't have the concept of 
resource, but in Jabber resource exists, so we should use it wisely.

Regards,
Diana

From dmeyer at tzi.de  Thu Oct 15 04:46:49 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Thu, 15 Oct 2009 11:46:49 +0200
Subject: [Jingle] [Fwd: Re: [MMUSIC] I-D
	Action:draft-ietf-mmusic-ice-tcp-08.txt]
In-Reply-To: <4AD6846C.2040404@stpeter.im> (Peter Saint-Andre's message of
	"Wed, 14 Oct 2009 19:09:48 -0700")
References: <4AD6846C.2040404@stpeter.im>
Message-ID: <87zl7tkn06.fsf@tzi.de>

Peter Saint-Andre wrote:
> FYI. Feel free to speak up on the mmusic list if you care about ICE-TCP
> (it might be useful for Jingle file transfer).

IMHO XEP-0260 provides everything Jingle file transfer needs to get
implemented. ICE-TCP may be a good future Jingle transport, but it is
not needed.

> -------- Original Message --------
>       Note: It has been reported that the simultaneous-open technique
>       has a low success rate (~40%) with the population of NAT devices
>       in use as of this writing.

simultaneous-open is not supported by XEP-0260 and it looks like it does
not really work anyway.

>       Therefore, it is RECOMMENDED that implementations of this
>       specification acquire and use IPv6 host candidates.  Means of
>       doing so across NATs include Tunnel Setup Protocol
>       [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380], IPSec
>       NAT-T [RFC3947], and others.

XEP-0260 supports Teredo and IPv6 and even has IPv6 in an example.


Dirk, who would love to see Jingle file transfer based on XEP-0260

-- 
It's not Area 51 I'm worried about- it's Areas 1 through 50.

From ml at update.uu.se  Thu Oct 15 05:43:05 2009
From: ml at update.uu.se (Marcus Lundblad)
Date: Thu, 15 Oct 2009 12:43:05 +0200
Subject: [Jingle] [Fwd: Re: [MMUSIC] I-D
 Action:draft-ietf-mmusic-ice-tcp-08.txt]
In-Reply-To: <87zl7tkn06.fsf@tzi.de>
References: <4AD6846C.2040404@stpeter.im>  <87zl7tkn06.fsf@tzi.de>
Message-ID: <1255603385.6428.2.camel@andromeda.sth.curalia.se>

tor 2009-10-15 klockan 11:46 +0200 skrev Dirk Meyer:
> Peter Saint-Andre wrote:
> > FYI. Feel free to speak up on the mmusic list if you care about ICE-TCP
> > (it might be useful for Jingle file transfer).
> 
> IMHO XEP-0260 provides everything Jingle file transfer needs to get
> implemented. ICE-TCP may be a good future Jingle transport, but it is
> not needed.
> 
I mostly agree, although, one advantage I can see with ICE-TCP is that
it would be possible to use it with a future TURN-TCP instead of the
current S5B proxies, which are XMPP-specific.

But, yeah, for the time being 0260+0261 is enough to get a working
solution.

//Marcus

> > -------- Original Message --------
> >       Note: It has been reported that the simultaneous-open technique
> >       has a low success rate (~40%) with the population of NAT devices
> >       in use as of this writing.
> 
> simultaneous-open is not supported by XEP-0260 and it looks like it does
> not really work anyway.
> 
> >       Therefore, it is RECOMMENDED that implementations of this
> >       specification acquire and use IPv6 host candidates.  Means of
> >       doing so across NATs include Tunnel Setup Protocol
> >       [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380], IPSec
> >       NAT-T [RFC3947], and others.
> 
> XEP-0260 supports Teredo and IPv6 and even has IPv6 in an example.
> 
> 
> Dirk, who would love to see Jingle file transfer based on XEP-0260
> 
-- 
Marcus Lundblad
Phone +46 (0)18 250582    | Cell +46 (0)733 386299
XMPP mlundblad at jabber.org | ICQ 11604698
MSN ml at update.uu.se       | Y!M marcuslundblad
--


From olivier.crete at collabora.co.uk  Thu Oct 15 10:33:37 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Thu, 15 Oct 2009 11:33:37 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4AD6ECA4.4060006@null.ro>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD683CD.30008@stpeter.im> <4AD6DB4B.404@null.ro>
	<4AD6ECA4.4060006@null.ro>
Message-ID: <1255620817.25092.6.camel@TesterBox.tester.ca>

Hello,

Yes this is exactly what we had in mind!

Olivier

On Thu, 2009-10-15 at 12:34 +0300, Diana Cionoiu wrote:
> Hello,
> 
> I have a proposal on how to implement call forking in the jabber way 
> instead of the SIP way.
> 
> A jingle client wants to call B jingle client
> 
> A jingle server probes the B jingle user to find B's resources where B 
> can setup his voice priorities.
> 
> A jingle client calls all the B jingle client resources
> 
> I don't have an exact protocol proposal, but that's the basic concept.
> 
> This doesn't work in SIP because SIP doesn't have the concept of 
> resource, but in Jabber resource exists, so we should use it wisely.
> 
> Regards,
> Diana
-- 
Olivier Cr?te
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- 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: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/7c24cfaf/attachment.pgp>

From diana-liste at null.ro  Thu Oct 15 10:38:37 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Thu, 15 Oct 2009 18:38:37 +0300
Subject: [Jingle] Call forking
In-Reply-To: <1255620817.25092.6.camel@TesterBox.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>	<4AD683CD.30008@stpeter.im>
	<4AD6DB4B.404@null.ro>	<4AD6ECA4.4060006@null.ro>
	<1255620817.25092.6.camel@TesterBox.tester.ca>
Message-ID: <4AD741FD.1000306@null.ro>

Hello Olivier,

But you don't need support in protocol for that.
You can do it anyway.

Regards,
Diana

Olivier Cr?te wrote:
> Hello,
>
> Yes this is exactly what we had in mind!
>
> Olivier
>
> On Thu, 2009-10-15 at 12:34 +0300, Diana Cionoiu wrote:
>   
>> Hello,
>>
>> I have a proposal on how to implement call forking in the jabber way 
>> instead of the SIP way.
>>
>> A jingle client wants to call B jingle client
>>
>> A jingle server probes the B jingle user to find B's resources where B 
>> can setup his voice priorities.
>>
>> A jingle client calls all the B jingle client resources
>>
>> I don't have an exact protocol proposal, but that's the basic concept.
>>
>> This doesn't work in SIP because SIP doesn't have the concept of 
>> resource, but in Jabber resource exists, so we should use it wisely.
>>
>> Regards,
>> Diana
>>     


From olivier.crete at collabora.co.uk  Thu Oct 15 10:44:40 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Thu, 15 Oct 2009 11:44:40 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4AD741FD.1000306@null.ro>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD683CD.30008@stpeter.im> <4AD6DB4B.404@null.ro>
	<4AD6ECA4.4060006@null.ro>
	<1255620817.25092.6.camel@TesterBox.tester.ca>
	<4AD741FD.1000306@null.ro>
Message-ID: <1255621480.25092.8.camel@TesterBox.tester.ca>

Hi,

On Thu, 2009-10-15 at 18:38 +0300, Diana Cionoiu wrote:
> Hello Olivier,
> 
> But you don't need support in protocol for that.
> You can do it anyway.

If user A calls user B who has resources B1 and B2 and B1 picks up, it
has to close the stream to B2 which an appropriate error message so that
B2 knows that it is not a missed call. That error message is what's
missing.

Olivier

> Regards,
> Diana
> 
> Olivier Cr?te wrote:
> > Hello,
> >
> > Yes this is exactly what we had in mind!
> >
> > Olivier
> >
> > On Thu, 2009-10-15 at 12:34 +0300, Diana Cionoiu wrote:
> >   
> >> Hello,
> >>
> >> I have a proposal on how to implement call forking in the jabber way 
> >> instead of the SIP way.
> >>
> >> A jingle client wants to call B jingle client
> >>
> >> A jingle server probes the B jingle user to find B's resources where B 
> >> can setup his voice priorities.
> >>
> >> A jingle client calls all the B jingle client resources
> >>
> >> I don't have an exact protocol proposal, but that's the basic concept.
> >>
> >> This doesn't work in SIP because SIP doesn't have the concept of 
> >> resource, but in Jabber resource exists, so we should use it wisely.
> >>
> >> Regards,
> >> Diana
> >>     
> 
-- 
Olivier Cr?te
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- 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: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/d5ef82dd/attachment.pgp>

From diana-liste at null.ro  Thu Oct 15 10:55:57 2009
From: diana-liste at null.ro (Diana Cionoiu)
Date: Thu, 15 Oct 2009 18:55:57 +0300
Subject: [Jingle] Call forking
In-Reply-To: <1255621480.25092.8.camel@TesterBox.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>	<4AD683CD.30008@stpeter.im>
	<4AD6DB4B.404@null.ro>	<4AD6ECA4.4060006@null.ro>	<1255620817.25092.6.camel@TesterBox.tester.ca>	<4AD741FD.1000306@null.ro>
	<1255621480.25092.8.camel@TesterBox.tester.ca>
Message-ID: <4AD7460D.4020406@null.ro>

Hello Olivier,

Actually first A finds if there is B1 and B2 and than it launches 2 
calls, one to B1 and one to B2.
If B1 answers, A should send back a session-terminate to B2.

There is no need for an error message. Or is it?

Diana

Olivier Cr?te wrote:
> Hi,
>
> On Thu, 2009-10-15 at 18:38 +0300, Diana Cionoiu wrote:
>   
>> Hello Olivier,
>>
>> But you don't need support in protocol for that.
>> You can do it anyway.
>>     
>
> If user A calls user B who has resources B1 and B2 and B1 picks up, it
> has to close the stream to B2 which an appropriate error message so that
> B2 knows that it is not a missed call. That error message is what's
> missing.
>
> Olivier
>
>   
>> Regards,
>> Diana
>>
>> Olivier Cr?te wrote:
>>     
>>> Hello,
>>>
>>> Yes this is exactly what we had in mind!
>>>
>>> Olivier
>>>
>>> On Thu, 2009-10-15 at 12:34 +0300, Diana Cionoiu wrote:
>>>   
>>>       
>>>> Hello,
>>>>
>>>> I have a proposal on how to implement call forking in the jabber way 
>>>> instead of the SIP way.
>>>>
>>>> A jingle client wants to call B jingle client
>>>>
>>>> A jingle server probes the B jingle user to find B's resources where B 
>>>> can setup his voice priorities.
>>>>
>>>> A jingle client calls all the B jingle client resources
>>>>
>>>> I don't have an exact protocol proposal, but that's the basic concept.
>>>>
>>>> This doesn't work in SIP because SIP doesn't have the concept of 
>>>> resource, but in Jabber resource exists, so we should use it wisely.
>>>>
>>>> Regards,
>>>> Diana
>>>>     
>>>>         


From olivier.crete at collabora.co.uk  Thu Oct 15 11:23:43 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Thu, 15 Oct 2009 12:23:43 -0400
Subject: [Jingle] Call forking
In-Reply-To: <4AD7460D.4020406@null.ro>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4ACEB2A7.3000003@stpeter.im>	<1255061956.9653.4.camel@TesterBox.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD683CD.30008@stpeter.im> <4AD6DB4B.404@null.ro>
	<4AD6ECA4.4060006@null.ro>	<1255620817.25092.6.camel@TesterBox.tester.ca>
	<4AD741FD.1000306@null.ro>
	<1255621480.25092.8.camel@TesterBox.tester.ca>
	<4AD7460D.4020406@null.ro>
Message-ID: <1255623823.1116.0.camel@TesterTop3.tester.ca>

On Thu, 2009-10-15 at 18:55 +0300, Diana Cionoiu wrote:
> Hello Olivier,
> 
> Actually first A finds if there is B1 and B2 and than it launches 2 
> calls, one to B1 and one to B2.
> If B1 answers, A should send back a session-terminate to B2.
> 
> There is no need for an error message. Or is it?

Sorry, by error I meant <reason>.. Because you don't want B2 to log a
missed call.

-- 
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: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/a39973c9/attachment.pgp>

From juberti at google.com  Thu Oct 15 12:56:34 2009
From: juberti at google.com (Justin Uberti)
Date: Thu, 15 Oct 2009 10:56:34 -0700
Subject: [Jingle] Call forking
In-Reply-To: <1255623823.1116.0.camel@TesterTop3.tester.ca>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca> 
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com> 
	<4AD683CD.30008@stpeter.im> <4AD6DB4B.404@null.ro>
	<4AD6ECA4.4060006@null.ro> 
	<1255620817.25092.6.camel@TesterBox.tester.ca>
	<4AD741FD.1000306@null.ro> 
	<1255621480.25092.8.camel@TesterBox.tester.ca>
	<4AD7460D.4020406@null.ro> 
	<1255623823.1116.0.camel@TesterTop3.tester.ca>
Message-ID: <bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>

Are there any issues with <cancel/>? That seems like what we want here.

2009/10/15 Olivier Cr?te <olivier.crete at collabora.co.uk>

> On Thu, 2009-10-15 at 18:55 +0300, Diana Cionoiu wrote:
> > Hello Olivier,
> >
> > Actually first A finds if there is B1 and B2 and than it launches 2
> > calls, one to B1 and one to B2.
> > If B1 answers, A should send back a session-terminate to B2.
> >
> > There is no need for an error message. Or is it?
>
> Sorry, by error I meant <reason>.. Because you don't want B2 to log a
> missed call.
>
> --
> Olivier Cr?te
> olivier.crete at collabora.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/15f18c95/attachment.htm>

From stpeter at stpeter.im  Thu Oct 15 13:03:42 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 15 Oct 2009 12:03:42 -0600
Subject: [Jingle] Call forking
In-Reply-To: <bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>
	<4AD683CD.30008@stpeter.im>
	<4AD6DB4B.404@null.ro>	<4AD6ECA4.4060006@null.ro>
	<1255620817.25092.6.camel@TesterBox.tester.ca>	<4AD741FD.1000306@null.ro>
	<1255621480.25092.8.camel@TesterBox.tester.ca>	<4AD7460D.4020406@null.ro>
	<1255623823.1116.0.camel@TesterTop3.tester.ca>
	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>
Message-ID: <4AD763FE.8020608@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 11:56 AM, Justin Uberti wrote:
> Are there any issues with <cancel/>? That seems like what we want here.

+1

/psa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrXY/4ACgkQNL8k5A2w/vz5mQCZAbynwGWqDVkz39zcrB+7ux4Q
2KEAoLjBeVLIHfbv3ZswC0jxDkEB+SC0
=g1Pc
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Thu Oct 15 13:04:45 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 15 Oct 2009 12:04:45 -0600
Subject: [Jingle] Call forking
In-Reply-To: <4AD763FE.8020608@stpeter.im>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<bd0c36130910082157mf020df7l4cff616bdf0cd79a@mail.gmail.com>	<4AD683CD.30008@stpeter.im>	<4AD6DB4B.404@null.ro>	<4AD6ECA4.4060006@null.ro>	<1255620817.25092.6.camel@TesterBox.tester.ca>	<4AD741FD.1000306@null.ro>	<1255621480.25092.8.camel@TesterBox.tester.ca>	<4AD7460D.4020406@null.ro>	<1255623823.1116.0.camel@TesterTop3.tester.ca>	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>
	<4AD763FE.8020608@stpeter.im>
Message-ID: <4AD7643D.7020707@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 12:03 PM, Peter Saint-Andre wrote:
> On 10/15/09 11:56 AM, Justin Uberti wrote:
>> Are there any issues with <cancel/>? That seems like what we want here.
> 
> +1

I mean, we can define a special reason for <session-accepted-elsewhere/>
or something like that if we really want to, but I don't really see the
need.

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrXZD0ACgkQNL8k5A2w/vzMawCfZ39Du7Z6SlAS3n5SVFeX/jBU
3TAAn1TBopAK2IVMCG2k1EoTjkQpZV9y
=QbAT
-----END PGP SIGNATURE-----

From juberti at google.com  Thu Oct 15 13:09:37 2009
From: juberti at google.com (Justin Uberti)
Date: Thu, 15 Oct 2009 11:09:37 -0700
Subject: [Jingle] Call forking
In-Reply-To: <4AD7643D.7020707@stpeter.im>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca> 
	<4AD6ECA4.4060006@null.ro>
	<1255620817.25092.6.camel@TesterBox.tester.ca> 
	<4AD741FD.1000306@null.ro>
	<1255621480.25092.8.camel@TesterBox.tester.ca> 
	<4AD7460D.4020406@null.ro>
	<1255623823.1116.0.camel@TesterTop3.tester.ca> 
	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com> 
	<4AD763FE.8020608@stpeter.im> <4AD7643D.7020707@stpeter.im>
Message-ID: <bd0c36130910151109h2f370988n8f468c3dc3a5b42b@mail.gmail.com>

That's my opinion as well.

On Thu, Oct 15, 2009 at 11:04 AM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/15/09 12:03 PM, Peter Saint-Andre wrote:
> > On 10/15/09 11:56 AM, Justin Uberti wrote:
> >> Are there any issues with <cancel/>? That seems like what we want here.
> >
> > +1
>
> I mean, we can define a special reason for <session-accepted-elsewhere/>
> or something like that if we really want to, but I don't really see the
> need.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrXZD0ACgkQNL8k5A2w/vzMawCfZ39Du7Z6SlAS3n5SVFeX/jBU
> 3TAAn1TBopAK2IVMCG2k1EoTjkQpZV9y
> =QbAT
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/3b249ee9/attachment.htm>

From florian.zeitz at gmx.de  Thu Oct 15 13:45:01 2009
From: florian.zeitz at gmx.de (Florian Zeitz)
Date: Thu, 15 Oct 2009 20:45:01 +0200
Subject: [Jingle] Call forking
In-Reply-To: <bd0c36130910151109h2f370988n8f468c3dc3a5b42b@mail.gmail.com>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<4AD6ECA4.4060006@null.ro>	<1255620817.25092.6.camel@TesterBox.tester.ca>
	<4AD741FD.1000306@null.ro>	<1255621480.25092.8.camel@TesterBox.tester.ca>
	<4AD7460D.4020406@null.ro>	<1255623823.1116.0.camel@TesterTop3.tester.ca>
	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>
	<4AD763FE.8020608@stpeter.im> <4AD7643D.7020707@stpeter.im>
	<bd0c36130910151109h2f370988n8f468c3dc3a5b42b@mail.gmail.com>
Message-ID: <4AD76DAD.1080007@gmx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Uberti wrote:
> That's my opinion as well.
> 
> On Thu, Oct 15, 2009 at 11:04 AM, Peter Saint-Andre <stpeter at stpeter.im
> <mailto:stpeter at stpeter.im>> wrote:
> 
> On 10/15/09 12:03 PM, Peter Saint-Andre wrote:
>> On 10/15/09 11:56 AM, Justin Uberti wrote:
>>> Are there any issues with <cancel/>? That seems like what we want
> here.
> 
>> +1
> 
> I mean, we can define a special reason for <session-accepted-elsewhere/>
> or something like that if we really want to, but I don't really see the
> need.
> 
> Peter
> 
<insert rant about evil top posters here />

I personally think we want <alternative-session/> if we use anything
that is already there.
I think a reason of cancel would suggest that the caller was waiting to
long and decided to hang up (i.e. it would log a missed call which we
don't want to happen here).
"The party prefers to use an existing session with the peer rather than
initiate a new session" sounds pretty much like what's the case here...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrXbagACgkQ0JXcdjR+9YTMxQCgv2ocKEuf5qKU0mwMJkx8D1rg
xmwAnR5CmblbSR8tWz/vLUWHiYxW8+RE
=juat
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Thu Oct 15 14:06:21 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 15 Oct 2009 13:06:21 -0600
Subject: [Jingle] Call forking
In-Reply-To: <4AD76DAD.1080007@gmx.de>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>	<4AD6ECA4.4060006@null.ro>	<1255620817.25092.6.camel@TesterBox.tester.ca>	<4AD741FD.1000306@null.ro>	<1255621480.25092.8.camel@TesterBox.tester.ca>	<4AD7460D.4020406@null.ro>	<1255623823.1116.0.camel@TesterTop3.tester.ca>	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>	<4AD763FE.8020608@stpeter.im>
	<4AD7643D.7020707@stpeter.im>	<bd0c36130910151109h2f370988n8f468c3dc3a5b42b@mail.gmail.com>
	<4AD76DAD.1080007@gmx.de>
Message-ID: <4AD772AD.3080806@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 12:45 PM, Florian Zeitz wrote:
> Justin Uberti wrote:
>> That's my opinion as well.
> 
>> On Thu, Oct 15, 2009 at 11:04 AM, Peter Saint-Andre <stpeter at stpeter.im
>> <mailto:stpeter at stpeter.im>> wrote:
> 
>> On 10/15/09 12:03 PM, Peter Saint-Andre wrote:
>>> On 10/15/09 11:56 AM, Justin Uberti wrote:
>>>> Are there any issues with <cancel/>? That seems like what we want
>> here.
> 
>>> +1
>> I mean, we can define a special reason for <session-accepted-elsewhere/>
>> or something like that if we really want to, but I don't really see the
>> need.
> 
>> Peter
> 
> <insert rant about evil top posters here />

Agreed. :)

> I personally think we want <alternative-session/> if we use anything
> that is already there.
> I think a reason of cancel would suggest that the caller was waiting to
> long and decided to hang up (i.e. it would log a missed call which we
> don't want to happen here).
> "The party prefers to use an existing session with the peer rather than
> initiate a new session" sounds pretty much like what's the case here...

That seems sensible. IIRC we thought that <alternative-session/> would
be used for communications between the same full JID pair ("hey, why are
you starting a new session, we've already got one!") but I suppose it
could be used for bare JID pairs as well ("hey, sorry about that, I'd
like to retract the offer because you answered from a different resource").

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrXcq0ACgkQNL8k5A2w/vxA3gCfZ1BT9DLRWtS55SDzTqOBh/0y
YzQAoMVL8ABgjWoSbveAVUTuLRRbtopH
=Lge9
-----END PGP SIGNATURE-----

From juberti at google.com  Thu Oct 15 15:26:33 2009
From: juberti at google.com (Justin Uberti)
Date: Thu, 15 Oct 2009 13:26:33 -0700
Subject: [Jingle] Call forking
In-Reply-To: <4AD772AD.3080806@stpeter.im>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca> 
	<1255621480.25092.8.camel@TesterBox.tester.ca>
	<4AD7460D.4020406@null.ro> 
	<1255623823.1116.0.camel@TesterTop3.tester.ca>
	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com> 
	<4AD763FE.8020608@stpeter.im> <4AD7643D.7020707@stpeter.im> 
	<bd0c36130910151109h2f370988n8f468c3dc3a5b42b@mail.gmail.com> 
	<4AD76DAD.1080007@gmx.de> <4AD772AD.3080806@stpeter.im>
Message-ID: <bd0c36130910151326q223bd04cs8877fed523e86e16@mail.gmail.com>

On Thu, Oct 15, 2009 at 12:06 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/15/09 12:45 PM, Florian Zeitz wrote:
> > Justin Uberti wrote:
> >> That's my opinion as well.
> >
> >> On Thu, Oct 15, 2009 at 11:04 AM, Peter Saint-Andre <stpeter at stpeter.im
> >> <mailto:stpeter at stpeter.im>> wrote:
> >
> >> On 10/15/09 12:03 PM, Peter Saint-Andre wrote:
> >>> On 10/15/09 11:56 AM, Justin Uberti wrote:
> >>>> Are there any issues with <cancel/>? That seems like what we want
> >> here.
> >
> >>> +1
> >> I mean, we can define a special reason for <session-accepted-elsewhere/>
> >> or something like that if we really want to, but I don't really see the
> >> need.
> >
> >> Peter
> >
> > <insert rant about evil top posters here />
>
> Agreed. :)
>

Blame it on Gmail :-p

>
> > I personally think we want <alternative-session/> if we use anything
> > that is already there.
> > I think a reason of cancel would suggest that the caller was waiting to
> > long and decided to hang up (i.e. it would log a missed call which we
> > don't want to happen here).
>

I think that would be <success/>. It is a normal hang-up.

 > "The party prefers to use an existing session with the peer rather than
> > initiate a new session" sounds pretty much like what's the case here...
>
> That seems sensible. IIRC we thought that <alternative-session/> would
> be used for communications between the same full JID pair ("hey, why are
> you starting a new session, we've already got one!") but I suppose it
> could be used for bare JID pairs as well ("hey, sorry about that, I'd
> like to retract the offer because you answered from a different resource").
>


From juberti at google.com  Thu Oct 15 16:17:03 2009
From: juberti at google.com (Justin Uberti)
Date: Thu, 15 Oct 2009 14:17:03 -0700
Subject: [Jingle] Negotiating a RTP profile in XEP-0167
Message-ID: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com>

Looking at section 6 of XEP-0167, it seems the use of RTP/AVP profile is
implictly assumed:

*For example, consider a payload of 16-bit linear-encoded stereo audio
sampled at 16KHz associated with dynamic payload-type 96:*

*<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
  <payload-type id='96' name='speex' clockrate='16000'/>
</description>
  *

*That Jingle-formatted information would be mapped to SDP as follows:*

*m=audio 9999 RTP/AVP 96
a=rtpmap:96 speex/16000*


 So, how should one signal the use of a different profile, e.g. RTP/AVPF?
Does a profile= attribute make sense here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/255da0a3/attachment.htm>

From stpeter at stpeter.im  Thu Oct 15 16:47:33 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 15 Oct 2009 15:47:33 -0600
Subject: [Jingle] Negotiating a RTP profile in XEP-0167
In-Reply-To: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com>
References: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com>
Message-ID: <4AD79875.5030408@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 3:17 PM, Justin Uberti wrote:
> Looking at section 6 of XEP-0167, it seems the use of RTP/AVP profile is
> implictly assumed:
> 
> /For example, consider a payload of 16-bit linear-encoded stereo audio
> sampled at 16KHz associated with dynamic payload-type 96:/
> 
> /<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
>   <payload-type id='96' name='speex' clockrate='16000'/>
> </description>
>   /
> 
> /That Jingle-formatted information would be mapped to SDP as follows:/
> 
> /m=audio 9999 RTP/AVP 96
> a=rtpmap:96 speex/16000/
> 
> 
>  So, how should one signal the use of a different profile, e.g.
> RTP/AVPF? Does a profile= attribute make sense here?

In earlier revisions of XEP-0167 we indeed had a 'profile' attribute.
Consider the following text from version 0.22, which is archived at
<http://xmpp.org/extensions/attic/xep-0167-0.22.html> ...

***

The <description/> element SHOULD possess a 'profile' attribute that
specifies the profile of RTP in use as would be encapsulated in SDP
(e.g., "RTP/AVP" or "UDP/TLS/RTP/SAVP"). If not included, the default
value of "RTP/AVP" MUST be assumed.

***

The 'profile' attribute was removed in version 0.23 (2008-07-31) as part
of the simplifications resulting from XMPP Summit #5:

http://xmpp.org/extensions/attic/xep-0167-0.23.html

See also:

http://mail.jabber.org/pipermail/jingle/2008-July/000109.html

One of the Jingle-related topics for that Summit was "getting rid of
weird SIP hang-overs in jingle like profiles". Perhaps Robert McQueen
can elaborate.

I have no deep objections to bring 'profile' back if we need it, and
defaulting it to "RTP/AVP" as we did in the past.

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrXmHUACgkQNL8k5A2w/vy4GgCgt8QFhN/lw3r/fuPohl1s3I/Q
HMQAn2g8KusNgKr0F0FH8mrwJfldk5Sn
=mo3L
-----END PGP SIGNATURE-----

From olivier.crete at collabora.co.uk  Thu Oct 15 17:43:00 2009
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Thu, 15 Oct 2009 18:43:00 -0400
Subject: [Jingle] Negotiating a RTP profile in XEP-0167
In-Reply-To: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com>
References: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com>
Message-ID: <1255646580.1116.15.camel@TesterTop3.tester.ca>

On Thu, 2009-10-15 at 14:17 -0700, Justin Uberti wrote:
>  So, how should one signal the use of a different profile, e.g.
> RTP/AVPF? Does a profile= attribute make sense here?

Jingle already has a different way to signal SRTP instead of using
profiles. Maybe we want to do the same thing for AVPF? And we probably
want this to be in the caps so it can be discoverable. Also, with AVPF
we also want to signal the type of supported feedback with a=rtcp-fb. So
if we want to support it in jingle, I guess we can either add it to the
RTP xep or have another XEP to specify the XMPP way of getting that
information.

I'm not familiar with all the details of AVPF, but I believe that it is
mostly additive to AVP (ie, its mostly how RTCP is sent and processed).

-- 
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: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/1c3e767b/attachment.pgp>

From juberti at google.com  Thu Oct 15 18:38:17 2009
From: juberti at google.com (Justin Uberti)
Date: Thu, 15 Oct 2009 16:38:17 -0700
Subject: [Jingle] Negotiating a RTP profile in XEP-0167
In-Reply-To: <1255646580.1116.15.camel@TesterTop3.tester.ca>
References: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com> 
	<1255646580.1116.15.camel@TesterTop3.tester.ca>
Message-ID: <bd0c36130910151638g6c849580i66672f30a6393547@mail.gmail.com>

2009/10/15 Olivier Cr?te <olivier.crete at collabora.co.uk>

> On Thu, 2009-10-15 at 14:17 -0700, Justin Uberti wrote:
> >  So, how should one signal the use of a different profile, e.g.
> > RTP/AVPF? Does a profile= attribute make sense here?
>
> Jingle already has a different way to signal SRTP instead of using
> profiles. Maybe we want to do the same thing for AVPF? And we probably
> want this to be in the caps so it can be discoverable. Also, with AVPF
> we also want to signal the type of supported feedback with a=rtcp-fb. So
> if we want to support it in jingle, I guess we can either add it to the
> RTP xep or have another XEP to specify the XMPP way of getting that
> information.
>

Sure, although I don't want to have to invent something new every time a new
profile is needed (don't forget SAVPF too!)

Probably easiest to have it in a followup to XEP-0167.

>
> I'm not familiar with all the details of AVPF, but I believe that it is
> mostly additive to AVP (ie, its mostly how RTCP is sent and processed).
>

Yes, exactly. We use AVPF and only recently did we encounter a situation
where there was an issue with specifying AVP instead of AVPF.

>
> --
> Olivier Cr?te
> olivier.crete at collabora.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091015/be104588/attachment.htm>

From stpeter at stpeter.im  Thu Oct 15 21:02:17 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 15 Oct 2009 20:02:17 -0600
Subject: [Jingle] [Fwd: Re: [MMUSIC]
	I-D	Action:draft-ietf-mmusic-ice-tcp-08.txt]
In-Reply-To: <87zl7tkn06.fsf@tzi.de>
References: <4AD6846C.2040404@stpeter.im> <87zl7tkn06.fsf@tzi.de>
Message-ID: <4AD7D429.6090808@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 3:46 AM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> FYI. Feel free to speak up on the mmusic list if you care about ICE-TCP
>> (it might be useful for Jingle file transfer).
> 
> IMHO XEP-0260 provides everything Jingle file transfer needs to get
> implemented. ICE-TCP may be a good future Jingle transport, but it is
> not needed.

Agreed. Nice but not necessary. Although for us to really have good file
transfer with XEP-0260 we need to deploy more S5B relays...

>> -------- Original Message --------
>>       Note: It has been reported that the simultaneous-open technique
>>       has a low success rate (~40%) with the population of NAT devices
>>       in use as of this writing.
> 
> simultaneous-open is not supported by XEP-0260 and it looks like it does
> not really work anyway.
> 
>>       Therefore, it is RECOMMENDED that implementations of this
>>       specification acquire and use IPv6 host candidates.  Means of
>>       doing so across NATs include Tunnel Setup Protocol
>>       [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380], IPSec
>>       NAT-T [RFC3947], and others.
> 
> XEP-0260 supports Teredo and IPv6 and even has IPv6 in an example.

How exactly does XEP-0260 support Teredo?

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrX1CkACgkQNL8k5A2w/vzO0wCeOuCP8ePTAAtq18cvDXQIHWYW
1I0AoLdwe6UP06S3US9NxCvN2h6/ELi7
=6+GD
-----END PGP SIGNATURE-----

From dmeyer at tzi.de  Fri Oct 16 00:51:27 2009
From: dmeyer at tzi.de (Dirk Meyer)
Date: Fri, 16 Oct 2009 07:51:27 +0200
Subject: [Jingle] [Fwd: Re: [MMUSIC]
	I-D	Action:draft-ietf-mmusic-ice-tcp-08.txt]
In-Reply-To: <4AD7D429.6090808@stpeter.im> (Peter Saint-Andre's message of
	"Thu, 15 Oct 2009 20:02:17 -0600")
References: <4AD6846C.2040404@stpeter.im> <87zl7tkn06.fsf@tzi.de>
	<4AD7D429.6090808@stpeter.im>
Message-ID: <87y6nbkhsw.fsf@tzi.de>

Peter Saint-Andre wrote:
>>>       Therefore, it is RECOMMENDED that implementations of this
>>>       specification acquire and use IPv6 host candidates.  Means of
>>>       doing so across NATs include Tunnel Setup Protocol
>>>       [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380], IPSec
>>>       NAT-T [RFC3947], and others.
>>
>> XEP-0260 supports Teredo and IPv6 and even has IPv6 in an example.
>
> How exactly does XEP-0260 support Teredo?

Is it not in the XEP? Oops, it should be. And the IPv6 address in the
XEP is no Teredo address; my fault. 

You don't need to have much in a protocol to support Teredo -- it is
just an IPv6 address. Yet, it would be nice to know if the peer uses a
Teredo IPv6 address or not to check if we use a relay which will be
slower (e.g. I have a "native" IPv6 address on my laptop while most
people have Teredo IPv6 addresses)


Dirk

-- 
Don't trust reality. After all, it's only a collective hunch.

From stpeter at stpeter.im  Fri Oct 16 21:29:36 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Fri, 16 Oct 2009 20:29:36 -0600
Subject: [Jingle] [Fwd: Protocol Action: 'Traversal Using Relays around NAT
 (TURN): Relay	Extensions to Session Traversal Utilities for NAT (STUN)'
 to	Proposed Standard]
Message-ID: <4AD92C10.9040800@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI. This spec has been blocking the ICE spec, so we might see that one
become an RFC before too much longer. :)

/psa

- -------- Original Message --------
Subject: Protocol Action: 'Traversal Using Relays around NAT (TURN):
Relay	Extensions to Session Traversal Utilities for NAT (STUN)' to
Proposed Standard
Date: Fri, 16 Oct 2009 08:04:51 -0700 (PDT)
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce <ietf-announce at ietf.org>
CC: Internet Architecture Board <iab at iab.org>,	behave mailing list
<behave at ietf.org>,	behave chair <behave-chairs at tools.ietf.org>,	RFC
Editor <rfc-editor at rfc-editor.org>

The IESG has approved the following document:

- - 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session
   Traversal Utilities for NAT (STUN) '
   <draft-ietf-behave-turn-16.txt> as a Proposed Standard


This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-16.txt

Technical Summary

This specification defines a protocol that allows the host to control the
operation of a relay and to exchange IPv4/UDP packets with its peers
using the relay.  TURN differs from some other relay control protocols
in that it allows a client to communicate with multiple peers using a
single relay address.

The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal,
though it can be also used without ICE.

Working Group Summary

There is a strong consensus on publishing this document. Some details
have had significant discussion and there has been difficult to find the
right trade-off between maintaining transport functionality and the
desired implementability.

Protocol Quality

This specification is well reviewed. It also includes the experience of
implementations and their deployment.

Personell

The WG shepherd is Dan Wing and the Responsible AD Magnus Westerlund

Note to RFC Editor

Section 2.2, first paragraph:

OLD:

   To create an allocation on the server, the client uses an Allocate
   transaction.  The client sends a Allocate request to the server, and
   the server replies with an Allocate success response containing the
   allocated relayed transport address.  The client can include
   attributes in the Allocate request that describe the type of
   allocation it desires (e.g., the lifetime of the allocation).  Since
   relaying data may require lots of bandwidth, the server typically
   requires that the client authenticate itself using STUN's long-term
   credential mechanism, to show that it is authorized to use the
   server.

NEW:

   To create an allocation on the server, the client uses an Allocate
   transaction.  The client sends a Allocate request to the server, and
   the server replies with an Allocate success response containing the
   allocated relayed transport address.  The client can include
   attributes in the Allocate request that describe the type of
   allocation it desires (e.g., the lifetime of the allocation). Since
   relaying data has security implications, the server requires that the
   client authenticate itself, typically using STUN's long-term
   credential mechanism, to show that it is authorized to use the
   server.


Section 4, paragraph 3 (Page 20-21):

OLD:
   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server SHOULD
   demand that all requests from the client be authenticated using this
   mechanism, and the client MUST be prepared to authenticate requests
   if required.

      In general, it is strongly recommended that servers require
      requests to be authenticated, as the security of TURN can
      otherwise be quite weak.  One reason that a server might not
      require requests to be authenticated is that TURN is being used in
      a carefully controlled environment in which the risks of
      unauthenticated requests by hostile third-parties have been
      mitigated.  See Section 17 for more discussion on this point.


NEW:

   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server MUST
   demand that all requests from the client be authenticated using this
   mechanism, or that a equally strong or stronger mechanism for client
   authentication is used.

   [remove paragraph]

Section 6.2, First bullet point in paragraph 2:

OLD:

1.  The server SHOULD require that the request be authenticated using
       the Long-Term Credential mechanism of [RFC5389].

NEW:

1.  The server MUST require that the request be authenticated. Using
       the Long-Term Credential mechanism of [RFC5389] unless another
       mechanism is signaled.


Section 16, Third paragraph:

OLD:

   The server follows the recommended practice in this specification of
   requiring all requests to be authenticated.  Thus when the server
   receives the initial Allocate request, it rejects the request because
   the request does not contain the authentication attributes.
   Following the procedures of the Long-Term Credential Mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.


NEW:

   Servers requires any request to be authenticated. Thus when the
   server receives the initial Allocate request, it rejects the request
   because the request does not contain the authentication attributes.
   Following the procedures of the Long-Term Credential Mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.

Section 17, second paragraph:

OLD:

   Note: Most of the attacks on TURN are mitigated by the server
   requiring requests be authenticated using the Long-Term Credential
   mechanism of STUN.  Thus it is strongly recommended that servers
   demand that requests be authenticated.  However, in certain
   deployments, the use of this mechanism may be unnecessary.  An
   example might be a deployment where access to the TURN server is
   available only through a network where their are fairly tight
   controls over what devices can connect to the network (and by whom)
   and what software these devices can use.  Tightly-run corporate
   networks can arguably fall into this category.

NEW:

   Most of the attacks on TURN are mitigated by the server
   requiring requests be authenticated. Thus this specification requires
   the use of authentication. The mandatory to implement mechanism is the
   Long-Term Credential mechanism of STUN. Other authentication
   mechanisms of equal or stronger security properties may be used.
   However, it is important to ensure that they can be invoked in an
   inter-operable way.

_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrZLBAACgkQNL8k5A2w/vw96gCcD6mI8JBcwXQDG1o4r2nzG20i
H6UAoOgUegQGsntO8A0/Ic9LkLFrpDrN
=/G05
-----END PGP SIGNATURE-----

From xramtsov at gmail.com  Sat Oct 17 01:29:22 2009
From: xramtsov at gmail.com (Evgeniy Khramtsov)
Date: Sat, 17 Oct 2009 16:29:22 +1000
Subject: [Jingle] [Fwd: Protocol Action: 'Traversal Using Relays around
 NAT (TURN): Relay	Extensions to Session Traversal Utilities for NAT (STUN)'
 to	Proposed Standard]
In-Reply-To: <4AD92C10.9040800@stpeter.im>
References: <4AD92C10.9040800@stpeter.im>
Message-ID: <4AD96442.4040505@gmail.com>

Peter Saint-Andre wrote:
> FYI. This spec has been blocking the ICE spec, so we might see that one
> become an RFC before too much longer. :)
>   

Good news ;) The only thing that stops us from commiting an 
implementation in ejabberd's SVN is a lack of shared secret allocation 
procedure in XMPP. Details are in 
https://support.process-one.net/browse/EJAB-1017. I'm sorry to annoy 
you, but it would be great if you have a time to review XEP-0215 :)

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.


From stpeter at stpeter.im  Sat Oct 17 09:30:03 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sat, 17 Oct 2009 08:30:03 -0600
Subject: [Jingle] [Fwd: Protocol Action: 'Traversal Using Relays around
 NAT (TURN): Relay	Extensions to Session Traversal Utilities for NAT (STUN)'
 to	Proposed Standard]
In-Reply-To: <4AD96442.4040505@gmail.com>
References: <4AD92C10.9040800@stpeter.im> <4AD96442.4040505@gmail.com>
Message-ID: <4AD9D4EB.1080509@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/17/09 12:29 AM, Evgeniy Khramtsov wrote:
> Peter Saint-Andre wrote:
>> FYI. This spec has been blocking the ICE spec, so we might see that one
>> become an RFC before too much longer. :)
>>   
> 
> Good news ;) The only thing that stops us from commiting an
> implementation in ejabberd's SVN is a lack of shared secret allocation
> procedure in XMPP. Details are in
> https://support.process-one.net/browse/EJAB-1017. I'm sorry to annoy
> you, but it would be great if you have a time to review XEP-0215 :)

OK, I'll work on this again next week. :)

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrZ1OsACgkQNL8k5A2w/vyybACfYTDLap/Y6P388mdANz2XYTkj
tz8AnAxCl1PFaaMkFQtz3BCHBDWaVuss
=OXDW
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Sun Oct 18 19:39:19 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Sun, 18 Oct 2009 18:39:19 -0600
Subject: [Jingle] Call forking
In-Reply-To: <bd0c36130910151326q223bd04cs8877fed523e86e16@mail.gmail.com>
References: <1255037913.2787.15.camel@TesterTop3.tester.ca>
	<1255621480.25092.8.camel@TesterBox.tester.ca>	<4AD7460D.4020406@null.ro>
	<1255623823.1116.0.camel@TesterTop3.tester.ca>	<bd0c36130910151056s57abf1b2xa45ec3b78c3be8ec@mail.gmail.com>
	<4AD763FE.8020608@stpeter.im> <4AD7643D.7020707@stpeter.im>
	<bd0c36130910151109h2f370988n8f468c3dc3a5b42b@mail.gmail.com>
	<4AD76DAD.1080007@gmx.de> <4AD772AD.3080806@stpeter.im>
	<bd0c36130910151326q223bd04cs8877fed523e86e16@mail.gmail.com>
Message-ID: <4ADBB537.3030806@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 2:26 PM, Justin Uberti wrote:
> 
> 
> On Thu, Oct 15, 2009 at 12:06 PM, Peter Saint-Andre <stpeter at stpeter.im
> <mailto:stpeter at stpeter.im>> wrote:
> 
> On 10/15/09 12:45 PM, Florian Zeitz wrote:
>> Justin Uberti wrote:
>>> That's my opinion as well.
> 
>>> On Thu, Oct 15, 2009 at 11:04 AM, Peter Saint-Andre
> <stpeter at stpeter.im <mailto:stpeter at stpeter.im>
>>> <mailto:stpeter at stpeter.im <mailto:stpeter at stpeter.im>>> wrote:
> 
>>> On 10/15/09 12:03 PM, Peter Saint-Andre wrote:
>>>> On 10/15/09 11:56 AM, Justin Uberti wrote:
>>>>> Are there any issues with <cancel/>? That seems like what we want
>>> here.
> 
>>>> +1
>>> I mean, we can define a special reason for
> <session-accepted-elsewhere/>
>>> or something like that if we really want to, but I don't really
> see the
>>> need.
> 
>>> Peter
> 
>> <insert rant about evil top posters here />
> 
> Agreed. :)
> 
> 
>> Blame it on Gmail :-p
> 
> 
>> I personally think we want <alternative-session/> if we use anything
>> that is already there.
>> I think a reason of cancel would suggest that the caller was
> waiting to
>> long and decided to hang up (i.e. it would log a missed call which we
>> don't want to happen here).
> 
> 
>> I think that would be <success/>. It is a normal hang-up.
> 
>> "The party prefers to use an existing session with the peer rather
> than
>> initiate a new session" sounds pretty much like what's the case
> here...
> 
> That seems sensible. IIRC we thought that <alternative-session/> would
> be used for communications between the same full JID pair ("hey, why are
> you starting a new session, we've already got one!") but I suppose it
> could be used for bare JID pairs as well ("hey, sorry about that, I'd
> like to retract the offer because you answered from a different
> resource").
> 
> 
>> From the description of <alternative-session/>, it seems the callee will
>> try to lookup the alternative session and not find it, which seems
>> unclean. If we go this route I would rather have something like
>> <alternative-resource/>, and explicitly mention the resource that picked up.

+1

Shall we write up a small spec about this?

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrbtTcACgkQNL8k5A2w/vx+dwCeMLrhCKYnNrTSRU3AAAdgaJMj
zkEAoPi5iuZtdFLBrFfxidIix7E4D40p
=23jT
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Mon Oct 19 14:28:34 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 19 Oct 2009 13:28:34 -0600
Subject: [Jingle] [Fwd: Re:
	[MMUSIC]	I-D	Action:draft-ietf-mmusic-ice-tcp-08.txt]
In-Reply-To: <87y6nbkhsw.fsf@tzi.de>
References: <4AD6846C.2040404@stpeter.im>
	<87zl7tkn06.fsf@tzi.de>	<4AD7D429.6090808@stpeter.im>
	<87y6nbkhsw.fsf@tzi.de>
Message-ID: <4ADCBDE2.9010800@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 11:51 PM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>>>>       Therefore, it is RECOMMENDED that implementations of this
>>>>       specification acquire and use IPv6 host candidates.  Means of
>>>>       doing so across NATs include Tunnel Setup Protocol
>>>>       [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380], IPSec
>>>>       NAT-T [RFC3947], and others.
>>> XEP-0260 supports Teredo and IPv6 and even has IPv6 in an example.
>> How exactly does XEP-0260 support Teredo?
> 
> Is it not in the XEP? Oops, it should be. And the IPv6 address in the
> XEP is no Teredo address; my fault. 

Feel free to fix it in SVN or paste corrections here. We've been messing
around with SVN so your old login might not work at the moment.

> You don't need to have much in a protocol to support Teredo -- it is
> just an IPv6 address. Yet, it would be nice to know if the peer uses a
> Teredo IPv6 address or not to check if we use a relay which will be
> slower (e.g. I have a "native" IPv6 address on my laptop while most
> people have Teredo IPv6 addresses)

We have a type for "tunnel" and that's supposed to handle Teredo. I
forgot that we added those...

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrcveIACgkQNL8k5A2w/vwmSQCg0IwpaDd1rMFtVUtl25V1k/Md
XZMAoKV7rGQTHbdZBUMcDCySmtlOp1Q6
=6aWu
-----END PGP SIGNATURE-----

From stpeter at stpeter.im  Mon Oct 19 16:09:37 2009
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 19 Oct 2009 15:09:37 -0600
Subject: [Jingle] Negotiating a RTP profile in XEP-0167
In-Reply-To: <bd0c36130910151638g6c849580i66672f30a6393547@mail.gmail.com>
References: <bd0c36130910151417k557bcb19m4bcdaeaa62b66cef@mail.gmail.com>
	<1255646580.1116.15.camel@TesterTop3.tester.ca>
	<bd0c36130910151638g6c849580i66672f30a6393547@mail.gmail.com>
Message-ID: <4ADCD591.3090906@stpeter.im>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 5:38 PM, Justin Uberti wrote:
> 
> 
> 2009/10/15 Olivier Cr?te <olivier.crete at collabora.co.uk
> <mailto:olivier.crete at collabora.co.uk>>
> 
>     On Thu, 2009-10-15 at 14:17 -0700, Justin Uberti wrote:
>     >  So, how should one signal the use of a different profile, e.g.
>     > RTP/AVPF? Does a profile= attribute make sense here?
> 
>     Jingle already has a different way to signal SRTP instead of using
>     profiles. Maybe we want to do the same thing for AVPF? And we probably
>     want this to be in the caps so it can be discoverable. Also, with AVPF
>     we also want to signal the type of supported feedback with a=rtcp-fb. So
>     if we want to support it in jingle, I guess we can either add it to the
>     RTP xep or have another XEP to specify the XMPP way of getting that
>     information.
> 
> 
> Sure, although I don't want to have to invent something new every time a
> new profile is needed (don't forget SAVPF too!) 
> 
> Probably easiest to have it in a followup to XEP-0167. 
> 
> 
>     I'm not familiar with all the details of AVPF, but I believe that it is
>     mostly additive to AVP (ie, its mostly how RTCP is sent and processed).
> 
> 
> Yes, exactly. We use AVPF and only recently did we encounter a situation
> where there was an issue with specifying AVP instead of AVPF.

Do we need to bring back the 'profile' attribute in XEP-0167?

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrc1ZEACgkQNL8k5A2w/vx+kACgrgbZkh7FGk3tDVhn2Beg8X6q
z2IAni1bcIJoPSvwS5tj+xWX9u+j71S3
=5z/o
-----END PGP SIGNATURE-----