Subject: [rtcweb] Use case addition: Interoperable calling

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Jun 2011 14:35:45 +0200

At the interim meeting discussion, the point was brought up that the use 
cases document at the moment doesn't contain any example where 
interoperability between clients driven by different Web applications 
could be an issue.

Rather than leaving this for later, I'll try to suggest some text below, 
in a form that should be easy to insert into draft-holmberg.

Comments on the below? Too little? Too much? Wrong? Just right?

                 Harald

----------------------------------------------------------------------

4.X. Use-case: Simple video communication service with inter-operator 
calling

4.X.1.  Description

Two users have logged into two different web applications, provided by 
different
service providers.

The service providers are interconnected by some means, but exchange no 
more information about the users than what can be carried using SIP. 
(Note: More profiling of what this means may be needed.)

Each web service publishes information about user login status for users 
that have a relationship with the other user; how this is established is 
out of scope.

The same functionality as in the "Simple Video Communication Service" is 
available.
The same issues with connectivity apply.

4.X.2 Derived requirements

(This describes requirements adding to the existing requirements)

FX1 The browser MUST be able to initiate and accept a media session 
using a common, standard protocol where the data needed for 
establishment can be carried in SIP.

FX2 The browser MUST support a baseline audio and video codec

FX3 There SHOULD be a mapping of the minimum needed data for setting up 
connections into SIP, so that the restriction to SIP-carriable data can 
be verified.

(There might be more here)

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 16 Jun 2011 15:26:23 +0200

I think this additional use case makes a lot of sense. Some comments in 
line.
> Comments on the below? Too little? Too much? Wrong? Just right?
Do you by "common, standard protocol" mean http,  WS or something else?
> FX2 The browser MUST support a baseline audio and video codec
Related to the current F18. Video is added, and then I guess it is up 
for discussion if the telephony codec is sufficient as baseline audio.
> connections into SIP, so that the restriction to SIP-carriable data can
Do you mean a mapping document the WG produces? Or do you mean that the 
browser should have some "SIP-validator" function implemented?

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Jun 2011 15:53:18 +0200

On 06/16/11 15:26, Stefan Håkansson LK wrote:
> I think this additional use case makes a lot of sense. Some comments 
> in line.
I was actually thinking "common" as in "both parties implement it", and 
thinking of the browser-to-browser connection, not the 
browser-to-webserver connection.

ICE + RTP is the combination I was thinking about, but naming protocols 
in requirements isn't nice if we can avoid it.
> for discussion if the telephony codec is sufficient as baseline audio.
Good argument to have. I think U-Law falls way short of a good baseline, 
but it's not obvious that this falls out of any present usecase.
> Do you mean a mapping document the WG produces? Or do you mean that 
> the browser should have some "SIP-validator" function implemented?

A mapping document that the WG produces would satisfy me as a way to 
show that it can be mapped.
Code is even better, of course.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 16 Jun 2011 16:09:25 +0200

> in requirements isn't nice if we can avoid it.
Aha, then I get it. The new part is "data needed for establishment can 
be carried in SIP"; the rest is already covered (F2 - F4).

Maybe it should be slightly re-phrased; when I read it "using a common, 
standard protocol" confuses, perhaps those words could just be removed?

If there is a need to state that the media session should use "a common, 
standard protocol" it is much earlier, this is relevant already to the 
first use case.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 Jun 2011 17:40:04 +0200

On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand <[email-masked]>wrote:

> that have a relationship with the other user; how this is established is out
> of scope.
>

I am not sure if I am understanding this part correctly. To me it sounds
like some sort of presence exchanged between users and, if so, I was
wondering if it was really necessary for inter-operator communication.

Emil

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Jun 2011 18:20:44 +0200

On 06/16/11 17:40, Emil Ivov wrote:
>
>
> On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Each web service publishes information about user login status for
>     users that have a relationship with the other user; how this is
>     established is out of scope.
>
>
> I am not sure if I am understanding this part correctly. To me it 
> sounds like some sort of presence exchanged between users and, if so, 
> I was wondering if it was really necessary for inter-operator 
> communication.
I don't know - all chat networks and web-based calling networks use 
network presence pretty heavily; the phone network's able to live 
without it, assuming that "everyone's there all the time".

The only reason for mentioning it here is that it's out of our scope to 
standardize it - if we don't mention it, some people might believe it's 
in scope, others that it's out of scope.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 17 Jun 2011 14:17:00 -0400

On Thu, Jun 16, 2011 at 2:35 PM, Harald Alvestrand <[email-masked]>
wrote:

I don't know - all chat networks and web-based calling networks use network
presence pretty heavily; the phone network's able to live without it,
assuming that "everyone's there all the time".

Mobile networks have their own presence.  HLR/VLR or HSS in IMS terms.

The only reason for mentioning it here is that it's out of our scope to
standardize it - if we don't mention it, some people might believe it's in
scope, others that it's out of scope.

So if this is out of scope and its seems it is , then this entire WEB-RTC
exercise seems to perpetuate the kind of silos we seen in Instant Messaging
and other forms of RTC.

Pardon me for sounding overly cynical..

---

From: Randell Jesup <[email-masked]>
Date: Fri, 17 Jun 2011 14:49:56 -0400

On 6/16/2011 12:20 PM, Harald Alvestrand wrote:
>>     Each web service publishes information about user login status
>>     for users that have a relationship with the other user; how this
>>     is established is out of scope.
>>

I don't even think that's necessary - the user could indicate he wants 
to talk to [email-masked], without having to know if Joe is 
currently on and registered with Facebook or not.  Also, a web service 
may implement the equivalent to network answering machines (forward to 
voice/videomail on not registered or no answer, or forward to another 
user, etc).

> without it, assuming that "everyone's there all the time".

Well, the PSTN network doesn't really assume that.   It knows where a 
number will get routed (which provider), but the device in question may 
not be reachable (especially for cellphones and VoIP phones).

> The only reason for mentioning it here is that it's out of our scope 
> to standardize it - if we don't mention it, some people might believe 
> it's in scope, others that it's out of scope.

Sure.

-- 
Randell Jesup
[email-masked]