Subject: Re: [dispatch] SIP Problem Statement

From: "Anton Tveretin" <[email-masked]>
Date: Mon, 2 Sep 2013 23:59:59 +0600

Hello All,
Thanks to everybody who answered.
Let me go into details.
I define "telephony" as real-time inter-personal communication. By SIP, I
mean a protocol family, not the protocol.
>[MB]  There have been proposals for call park and call pickup. You can see
here why the work was not progressed:
http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html
As I understand that message, authors of some I-D withdrew their proposal. 
The same for another I-D. I
don't think that binds me.
"No one implements" does not sound as a reasonable argument for me. I cannot
use it because no one implements, no one implements because no one uses.
For conferences, SIP requires conference URI. For that, there must be
routing function recognizing them and routing requests to appropriate focus,
focus service itself, conference factory that allocates and assigns
conference URIs, at least. In P2P scenarios, nothing of this would be
available.
Suppose someone (Alice?)  starts a conference. Anyone wishing to join knows
only Alice's address. Currently, in H.323, this is sufficient, but not in
SIP, as there is no way to indicate "join".
More to come...
Sincerely yours, Anton.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Sep 2013 19:47:22 -0400

> SIP, as there is no way to indicate "join".

Ummm... RFC 3911?
http://tools.ietf.org/html/rfc3911

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 12:08:01 -0400

> http://tools.ietf.org/html/rfc3911

Join does require the joiner to know the dialog id of the dialog it 
wishes to join, in addition to the URL.

But that is a fundamental problem if you want to join a conference, 
unless you assume the UA you are calling can only be in one call at a 
time. And its more complex if there are multiple UAs at the same AOR.

If somehow you are in the situation where you know somebody you want to 
call is already in a call that you want to join, but you don't know the 
dialog id, then you can subscribe to the dialog event package of your 
callee, look at the existing dialogs, and choose one to join. Of course 
this isn't something that you would want to allow everyone to do.

Hadriel can comment on the difficulty of using dialog ids when there are 
B2BUAs in use.

If you want to address a real problem, that may be the one. SIP was 
designed to work in a different environment than it is currently deployed.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Sep 2013 14:45:50 -0400

Hey I didn't say it was ever used or usable - just that SIP has such a concept. :)

In practice it's unnecessary.  Alice is in a SIP call with Bob; Carol calls Alice to join that Alice-Bob call using a normal SIP call; Alice sees Carol's incoming call; Alice puts Bob on hold and answers Carol, who says "can I join?"; Alice then can decide to join Carol to the Alice-Bob call by pressing a UI button for that purpose on her phone; the phone keeps them as distinct SIP dialogs, but bridges the media.

In other words, one doesn't actually need the SIP protocol level to indicate this joining, since the higher-layer application can do it by itself (with Alice's knowledge/input).  That model works for any call scenario, including one where Carol is actually in the PSTN and called Alice through a gateway, for example.

Arguably that's also why conference-server scenarios are frequently implemented without the special SIP-layer RFC 4579 stuff.

-hadriel

On Sep 3, 2013, at 12:08 PM, Paul Kyzivat <[email-masked]> wrote:

> Join does require the joiner to know the dialog id of the dialog it wishes to join, in addition to the URL.
> 
> But that is a fundamental problem if you want to join a conference, unless you assume the UA you are calling can only be in one call at a time. And its more complex if there are multiple UAs at the same AOR.
> 
> If somehow you are in the situation where you know somebody you want to call is already in a call that you want to join, but you don't know the dialog id, then you can subscribe to the dialog event package of your callee, look at the existing dialogs, and choose one to join. Of course this isn't something that you would want to allow everyone to do.
> 
> Hadriel can comment on the difficulty of using dialog ids when there are B2BUAs in use.
> 
> If you want to address a real problem, that may be the one. SIP was designed to work in a different environment than it is currently deployed.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 3 Sep 2013 14:51:53 -0400

Hadriel,

I agree that what you describe is commonly implemented for fixed line devices.  For mobiles it's another story.  The mobile operator typically doesn't want the device to perform this bridging function, because it wastes spectrum.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, September 03, 2013 1:46 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [dispatch] SIP Problem Statement

-hadriel

On Sep 3, 2013, at 12:08 PM, Paul Kyzivat <[email-masked]> wrote:

>>> Suppose someone (Alice?)  starts a conference. Anyone wishing to 
>>> join knows only Alice's address. Currently, in H.323, this is 
>>> sufficient, but not in SIP, as there is no way to indicate "join".
>> 
>> Ummm... RFC 3911?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Sep 2013 15:39:05 -0400

> I agree that what you describe is commonly implemented for fixed line devices.  For mobiles it's another story.  The mobile operator typically doesn't want the device to perform this bridging funct…

The device doesn't need to actually do the bridging.
But it can orchestrate - decide to form the conference, and recruit a 
server to do the media processing.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 3 Sep 2013 21:21:33 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

Even with ordinary SIP, it can use REFERs and 302 responses to INVITEs
to route all the call legs to a conference it has set up elsewhere.

Dale

---

From: "Anton Tveretin" <[email-masked]>
Date: Wed, 4 Sep 2013 21:42:30 +0600

RFC 3911 requires a conference URI. This implies that
1) there is one;
2) this URI is known to the caller beforehand.

My original idea was to send Join: without URI (and normatively update RFC 
3911 for that).
Anyway, IMO some (syntax level) indication needed to indicate that an INVITE 
is a request to join rather than just a call. Even though such an INVITE 
contains no session description. Actually, this might mean 3pcc.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 04 Sep 2013 13:36:10 -0500

On 9/4/13 10:42 AM, Anton Tveretin wrote:
> RFC 3911 requires a conference URI. 
No, it doesn't really.
I can see how you draw that from the text, but if you look at the 
mechanics, there is nothing in it that makes the URI itself special.
It was always the intent to allow ad-hoc conferences/mixing at the UA 
using this mechanism, and I've seen it implemented.

RjS
> This implies that
> My original idea was to send Join: without URI (and normatively update 
> RFC 3911 for that).
> Anyway, IMO some (syntax level) indication needed to indicate that an 
> INVITE is a request to join rather than just a call. Even though such 
> an INVITE contains no session description. Actually, this might mean 
> 3pcc.
>
> ----- Original Message ----- From: "Hadriel Kaplan" 
> <[email-masked]>
>>> join knows