Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 6 Sep 2011 00:46:08 +0530

Bernard,

Sorry for the delay reply.

There is a huge difference between tunneling the protocol and converting
the protocol from one format to another. The tunneling works well only
in case the destination support the tunneled data without negotiation.
It will be bad assumption in case the standard does not defined so.  For
example, 

1)      Browser A supports Jingle (XMPP for real-time data) and
encapsulates the data in HTTP and send it to webserver1

2)      RTCwebserver1 tunnel jingle data in SIP and sends it to
RTCwebserver2

3)      RTCwebserver2 does not support Jingle towards browser but it
support some other variant of HTTP based metadata to the browser. 

My question is how webserver2 do perform the interop correctly in case
Jingle is not mandated as metadata standard mechanism. Please let me
know your opinion here.

My understanding was that RTCwebserver1 may use some proprietary
mechanism (may be jingle) to communicate between browser and webserver
which will be converted into RFC 3261 SIP at webserver1 and forwarded to
RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary
metadata to communicate with browser. This mechanism works well but
still better mechanism exists.

Thanks

Partha

 

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, August 26, 2011 12:35 AM
To: Ravindran Parthasarathi; [email-masked]; [email-masked]
Subject: RE: [rtcweb] Some misunderstandings about <Usecase &
architecture: Browser application with separate webserver & voipserver>

> The issue in case webserver acts as new RTCWEB & SIP GW for VoIP
> communication, there is a need of protocol mapping between the
protocol
> used between browser & RTCWebserver (say RTCweb protocol) to SIP. 
 
[BA] Not necessarily.  For example, in the case of XMPP, BOSH can be
used
to encapsulate XMPP over HTTP.  The BOSH Connection Manager/Web server
does not do "mapping", it just encapsulates/decapsulates XMPP stanzas, 
enabling communication between XMPP clients supporting BOSH and 
XMPP servers.   This be handled entirely in Javascript with no native
support for XMPP. 
 
For detailed examples of how this works (with sample code), please see:
http://professionalxmpp.com/

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 05 Sep 2011 20:37:26 -0700

On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:
> There is a huge difference between tunneling the protocol and 
> converting the protocol from one format to another. The tunneling 
> works well only in case the destination support the tunneled data 
> without negotiation. It will be bad assumption in case the standard 
> does not defined so.  For example,
>
> 1)Browser A supports Jingle (XMPP for real-time data) and encapsulates 
> the data in HTTP and send it to webserver1
>

That isn't how it works. Browser A supports WebRTC. Do you mean browser 
A is running Javascript that implements Jingle or something similar for 
its signaling (over HTTP and/or Websockets) to its associated web server?

> 2)RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2
>

Federation between webserver1 and webserver2 is up to the operators of 
those sites. Presumably SIP is a good (but not only) choice for 
federation. Many sites won't have a desire or need to federate.

> 3)RTCwebserver2 does not support Jingle towards browser but it support 
> some other variant of HTTP based metadata to the browser.
>

Do you mean that webserver2 and its clients are running compatible code 
that exchanges signaling via a mechanism other than Jingle? That's fine, 
and up to the operator of that site.

> Jingle is not mandated as metadata standard mechanism. Please let me 

Every site that wishes to federate with others will need to choose a 
signaling protocol that is agreed between them.

> which will be converted into RFC 3261 SIP at webserver1 and forwarded 
> to RTCwebserver2. RTCWebserver2 converts back SIP to its own 
> proprietary metadata to communicate with browser. This mechanism works 
> well but still better mechanism exists.
>

That understanding appears to be correct. This is exactly the same as 
"Hotmail talks some proprietary protocol over HTTP between its 
HTML/Javascript client and its servers which is then converted to SMTP 
for sending to Gmail, where Gmail talks a different proprietary protocol 
over HTTP between its HTML/Javascript client and its servers." It 
appears to have resulted in some significant innovations in the email 
service space, while still allowing federation between domains using a 
standard protocol.

If you think this is a bad idea, provide an alternative we might discuss.

Matthew Kaufman

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 6 Sep 2011 23:36:35 +0530

Matthew,

Please read inline.

Thanks

Partha

From: Matthew Kaufman [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 9:07 AM
To: Ravindran Parthasarathi
Cc: Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [rtcweb] Usecase & architecture: Browser application with
separate webserver & voipserver

Bernard,

Browser A supports Jingle (XMPP for real-time data) and encapsulates the
data in HTTP and send it to webserver1

That isn't how it works. Browser A supports WebRTC. Do you mean browser
A is running Javascript that implements Jingle or something similar for
its signaling (over HTTP and/or Websockets) to its associated web
server?

[Partha]Browser A supports WebRTC Javascript API which is mapped to
Jingle. Browser A is not required to have native support of Jingle. I
guess that we mean the same thing.

RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2

[Partha] Here is the problem, it is expected that webserver1 has to
converts its proprietary stuff into SIP or other equivalent. So, RTCweb
to SIP gateway is mandated in your proposed architecture for the basic
dialog between two users in two webservers. It will be tough for each
webserver developer to create the proprietary protocol and mapping.
Instead, the basic SIP functionality provided in browser will make sure
the basic call works between any users across webserver without limiting
the innovative application build by individual webservers.

RTCwebserver2 does not support Jingle towards browser but it support
some other variant of HTTP based metadata to the browser. 

[Partha] it is bad network design because SIP is well accepted in
real-time applications (telecom or unified communication) and also there
is no need of contract with each site (company) and implement their
protocol to interop with them.

[Partha] This paradigm will not exactly fit for real-time communication
because there is a need of communication between browser to browser
apart from webserver to webserver communication. Still I could not under
the reason why SIP will stop the innovation whereas HTTP will allow.

If you think this is a bad idea, provide an alternative we might
discuss.

[Partha] I'm thinking of the solution which is in line of
draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which
makes real-time communication with other browser using SIP. The
configuration data required for browser SIP client is received through
Javascript and/or received metadata from webserver using HTTP
connection. Making SIP as a protocol for real-time communication will
make sure that browser not only communicates with another browser but
also ensure that it works with existing SIP implementation. It was my
original usecase wherein browser directly communicates with VoIP-server.
VoIP server may communicates with browser which does not matter for the
originating browser.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 11:33:41 -0700

On 9/6/11 11:06 AM, Ravindran Parthasarathi wrote:
>
> Matthew,
>
> Please read inline.
>
> Thanks
>
> Partha
>
> *From:*Matthew Kaufman [mailto:[email-masked]]
> *Sent:* Tuesday, September 06, 2011 9:07 AM
> *To:* Ravindran Parthasarathi
> *Cc:* Bernard Aboba; [email-masked]; [email-masked]
> *Subject:* Re: [rtcweb] Usecase & architecture: Browser application 
> with separate webserver & voipserver
>
> Browser A supports Jingle (XMPP for real-time data) and encapsulates 
> That isn't how it works. Browser A supports WebRTC. Do you mean 
> browser A is running Javascript that implements Jingle or something 
> similar for its signaling (over HTTP and/or Websockets) to its 
> associated web server?
>
> */[Partha]Browser A supports WebRTC Javascript API which is mapped to 
> guess that we mean the same thing./*
>
>

Sounds like we mean the same thing.

> */[Partha] Here is the problem, it is expected that webserver1 has to 
> converts its proprietary stuff into SIP or other equivalent. So, 
> RTCweb to SIP gateway is mandated in your proposed architecture for 
> the basic dialog between two users in two webservers. It will be tough 
> for each webserver developer to create the proprietary protocol and 
> mapping. Instead, the basic SIP functionality provided in browser will 
> make sure the basic call works between any users across webserver 
> without limiting the innovative application build by individual 
> webservers./*
>
>

Disagree. It is expected that webserver1 usually *doesn't* convert its 
proprietary stuff into SIP. That only happens when you want to federate 
with another service that uses SIP.

If it is "tough" to create a mapping between your proprietary stuff and 
SIP then perhaps you didn't design your proprietary stuff properly... 
that isn't my problem however.

Basic SIP functionality provided in the browser would likely limit the 
API in ways that block innovation.

> Do you mean that webserver2 and its clients are running compatible 
> code that exchanges signaling via a mechanism other than Jingle? 
> That's fine, and up to the operator of that site.
>
>
> */[Partha] it is bad network design because SIP is well accepted in 
> real-time applications (telecom or unified communication) and also 
> there is no need of contract with each site (company) and implement 
> their protocol to interop with them./*
>
>

SIP is well accepted in *some* real-time applications. I would note that 
the most popular real-time applications don't actually use SIP.

And yet there is SIP, for when you wish to interop without lengthy 
contract or discussion. The best of both worlds.

> for sending to Gmail, where Gmail talks a different proprietary 
> protocol over HTTP between its HTML/Javascript client and its 
> servers." It appears to have resulted in some significant innovations 
> in the email service space, while still allowing federation between 
> domains using a standard protocol.
>
> */[Partha] This paradigm will not exactly fit for real-time 
> communication because there is a need of communication between browser 
> to browser apart from webserver to webserver communication. Still I 
> could not under the reason why SIP will stop the innovation whereas 
> HTTP will allow./*
>

Because SIP requires standards activities before adding any useful 
functionality. I'll point to one of my favorites here: bridged line 
appearances. Despite lots of effort to fix this, there still isn't a way 
to do this reliably. And yet, if I created a web application using HTTP 
signaling and Javascript APIs on a web browser that provides a 
*platform* and not just a "phone", I could create a system in which 
bridged line appearances work well if I so desired with just a little 
bit of programming.

> */[Partha] I'm thinking of the solution which is in line of 
> original usecase wherein browser directly communicates with 
> VoIP-server. VoIP server may communicates with browser which does not 
> matter for the originating browser./*
>
>

So you want the browser to be a phone, and not a platform for innovation 
in the area of real-time applications. It is already a platform for 
innovation in many other areas, why limit it here?

Matthew Kaufman

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 7 Sep 2011 00:51:56 +0530

Matthew,

Please read inline.

Thanks

Partha

Sent: Wednesday, September 07, 2011 12:04 AM

Matthew,

Please read inline.

Thanks

Partha

Bernard,

Basic SIP functionality provided in the browser would likely limit the
API in ways that block innovation.
[Partha] we discussed in another mail thread for providing Javascript
API which helps to add SIP proprietary headers.

[Partha] Those mentioned popular real-time applications will never
interop with any other popular real-time application and also IETF or
other standard is not required for those real-time applications.

 

[Partha] In case you write some bridged line appearance which will not
work my implementation of bridged line appearance. Hope you agree here.
My point is that atleast basic scenario is taken as part of IETF bliss
WG. Even I have mentioned earlier for the basic call in SIP because I
know that supplementary services are not going to work easily. But most
of the user uses basic call.

[Partha] My intention is not to make browser as SIP phone. SIP is a
real-time communication protocol which helps to innovate application
which obsoletes legacy phones using browser. I'm asking why not take
advantage of SIP in the browser.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2011 13:10:52 +0200

On 09/06/11 20:33, Matthew Kaufman wrote:
> appearances. Despite lots of effort to fix this, there still isn't a 
> way to do this reliably. And yet, if I created a web application using 
> HTTP signaling and Javascript APIs on a web browser that provides a 

Since more people than I may be confused, I'm forking a subthread...

what is a bridged line appearance, and why is it hard to do in SIP?

My terminology cache is totally blank.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 07:16:24 -0700

> My terminology cache is totally blank.

Key system (and home phone) emulation requires two things that are hard 
to do (because there's no final specification, not because it is 
impossible) (and because there's 3+ alternatives, and almost no phones 
implement more than one of them) in SIP:

1. Shared line appearance

This is where you can be on a call on one handset, see that the line is 
in use at the other handset. Place the call on hold at the first, pick 
it up at the second.

In business PBX cases, this is used for executive/assistant cases. In 
key system emulation it is used for "Bob, pick up the call holding on 
line 3". And for home phones it is the usual "put the phone on hold in 
the kitchen, pick it up in the den." (My wife wanted this functionality, 
so I had to add proprietary support for shared line appearance on my 
home PBX.)

2. Bridged line appearance

This is where you can be on a call on one handset, see that line is in 
use at the other handset, and pick up the second handset to join the call.

In the business PBX and key system case this is sometimes used for 
supervisors to join a call to help, but the real common case is the home 
phones... "kids, go pick up the extension in the living room and talk to 
grandma."

With POTS, this works by simply paralleling two handsets on the same 
copper pair. For SIP it requires everything shared line appearance does 
*plus* automatic barge-in + conference on pickup.

The BLISS WG has been working, for a long time, on taking the various 
interim proposals and creating a standard out of them, but we're still 
not there... and yet without it, there's no way to use phones from two 
different vendors to accomplish this.

Whereas with WebRTC implemented *without SIP*, it is fairly easy to 
build a web app that runs on multiple browsers from multiple vendors and 
implements this.

So this type of ability to innovate and implement applications without 
going through the standards process is why we *definitely* don't want 
SIP baked in to the browser.

Not to be confused with the arguments against SDP offer/answer, which is 
only slightly affected by the above use cases (in that you can do 
smarter things at the bridge for bridged line appearance if you aren't 
doing a reinvite/re-offer/re-answer but instead have on hand all the 
capabilities of the first device when the second goes to join).

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 07:18:55 -0700

On 9/7/2011 7:16 AM, Matthew Kaufman wrote:
> build a web app that runs on multiple browsers from multiple vendors 
> and implements this.
>

And note that this is directly parallel to the "innovate like Gmail" 
discussion. It is trivial for Gmail to change the look and feel and 
behavior of the "delete" button to implement an email paradigm of "keep 
everything, search to find it" (and have it work the same way no matter 
who the browser vendor is)... but this wouldn't have been the case if 
Gmail were forced to use the browser's built-in IMAP implementation.

Matthew Kaufman

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Sep 2011 08:59:31 -0600

On Sep 7, 2011, at 8:16 AM, Matthew Kaufman wrote:

> Key system (and home phone) emulation requires two things that are hard to do (because there's no final specification, not because it is impossible) (and because there's 3+ alternatives, and almost no phones implement more than one of them) in SIP:
> 
> This is where you can be on a call on one handset, see that the line is in use at the other handset. Place the call on hold at the first, pick it up at the second.
> 
> In business PBX cases, this is used for executive/assistant cases. In key system emulation it is used for "Bob, pick up the call holding on line 3". And for home phones it is the usual "put the phone on hold in the kitchen, pick it up in the den." (My wife wanted this functionality, so I had to add proprietary support for shared line appearance on my home PBX.)
> 
> This is where you can be on a call on one handset, see that line is in use at the other handset, and pick up the second handset to join the call.
> 
> In the business PBX and key system case this is sometimes used for supervisors to join a call to help, but the real common case is the home phones... "kids, go pick up the extension in the living room and talk to grandma."
> 
> With POTS, this works by simply paralleling two handsets on the same copper pair. For SIP it requires everything shared line appearance does *plus* automatic barge-in + conference on pickup.
> 
> The BLISS WG has been working, for a long time, on taking the various interim proposals and creating a standard out of them, but we're still not there... and yet without it, there's no way to use phones from two different vendors to accomplish this.
> 
> Whereas with WebRTC implemented *without SIP*, it is fairly easy to build a web app that runs on multiple browsers from multiple vendors and implements this.

I've sort of been humoring you but I'm going to push this one a bit. I think you are wrong. 

Give me one reasons why it would be any harder to do if the browser did SIP than if it did the type of API you are talking about. I think you are just wrong here. The web app in the JS and in the web server would still just use SIP to set up media the way it wanted - just like you would do with the other API. No one is proposing we use the BLISS shared line appearance or anything like that - we are proposing that when A wants to say what codecs to use for sending media to B, use that part of SIP. 

(oh, and you could replace SIP with the word Jingle in the above paragraph and it would equally true)

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Sep 2011 09:00:52 -0600

On Sep 7, 2011, at 8:18 AM, Matthew Kaufman wrote:

>> So this type of ability to innovate and implement applications without going through the standards process is why we *definitely* don't want SIP baked in to the browser.
> 
> And note that this is directly parallel to the "innovate like Gmail" discussion. It is trivial for Gmail to change the look and feel and behavior of the "delete" button to implement an email paradigm of "keep everything, search to find it" (and have it work the same way no matter who the browser vendor is)... but this wouldn't have been the case if Gmail were forced to use the browser's built-in IMAP implementation.

again - as I have mentioned before, that a silly analogy. I know it is rhetorically nice but seriously, why do you think it is a reasonable parallel?

---

From: Tim Panton <[email-masked]>
Date: Wed, 7 Sep 2011 16:17:42 +0100

> (oh, and you could replace SIP with the word Jingle in the above paragraph and it would equally true)

But try that paragraph with BRI or 'RFC 5456' or 'Freeswitch's XML socket' or ASCF's ICE over HTTPS  and it sounds a bit weird. Why ? 
what is the difference between being locked into one of them vs SIP?

Arguably SIP comes with more expectations and baggage than any of the above and there is the risk. Folks will embed a full SIP stack
before we know it - and the mere existence of a market in SBCs shows why that would be 'a bad thing' (tm)

Tim. (speaking for himself).

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Sep 2011 11:18:28 -0400

Matthew,

Good summary.

I agree that webrtc provides flexibility in how to implement the UI 
portions of these features with generic webrtc clients. But it doesn't 
make these features trivial to implement. In particular, the bridged 
line appearance still requires that a conference be established. With 
generic rtcweb clients, that probably means a central mixer. Setting 
that up is relatively easy if there is a central media termination point 
in rtcweb server, and it *has* mixer capabilities.

My point is not that rtcweb doesn't help with this case - just that 
these features that are so trivial in analog telephony just aren't so 
simple with voip, no matter how you do it.

	Thanks,
	Paul

On 9/7/11 10:16 AM, Matthew Kaufman wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 7 Sep 2011 13:24:01 -0500

Just one comment below [MB].

Mary.

On Wed, Sep 7, 2011 at 10:18 AM, Paul Kyzivat <[email-masked]> wrote:

> portions of these features with generic webrtc clients. But it doesn't make
> these features trivial to implement. In particular, the bridged line
> appearance still requires that a conference be established. With generic
> rtcweb clients, that probably means a central mixer. Setting that up is
> relatively easy if there is a central media termination point in rtcweb
> server, and it *has* mixer capabilities.
>
> My point is not that rtcweb doesn't help with this case - just that these
> features that are so trivial in analog telephony just aren't so simple with
> voip, no matter how you do it.
>
[MB] These features we not trivial in analog telephony by any means
(speaking as someone who wrote LOTS of code for these ancient telephony
systems).  IMHO, it's this misconception that the services and functionality
in analog telephony systems was simple that's led to the difficulty in
getting any operability for these services defined for SIP.  Many of the
legacy telephone systems were no more designed for a host of complex
services than SIP was.  However, it would have been nice if services had
been considered in the initial design for SIP.  While there is the concept
that many services can be accomplished with basic SIP building
blocks/headers, we have way too many situations where this has proven to not
be at all simple.  But, I don't think SIP/VoIP is any worse off than were
the legacy systems. And, I agree with Paul there isn't any magic dust that
will make it any easier for RTCWEB to support these features.  [/MB]

>> ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
>>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:04:11 -0700

> Give me one reasons why it would be any harder to do if the browser did SIP than if it did the type of API you are talking about. I think you are just wrong here. The web app in the JS and in the w…

The problem with using "that part of SIP" is that you're at the top of a 
very very slippery slope. You want "just SIP"? With early media? PRACK? 
Refer? ...?

And then what happens when people try to write applications that have a 
real SIP server at the far end that doesn't know what to do with 
something that supports "just SIP" without any of its 
essentially-mandatory extensions?

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:05:40 -0700

> again - as I have mentioned before, that a silly analogy. I know it is rhetorically nice but seriously, why do you think it is a reasonable parallel?
"Baking a phone into the browser" is exactly the same as "baking an IMAP 
client into the browser".

What some have asked for is an API as simple as "sipPhone.call(<sip 
address>)" and "sipPhone.hangup()", and that's what I'm addressing.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 07 Sep 2011 15:10:23 -0700

On 9/7/11 8:18 AM, Paul Kyzivat wrote:
> make these features trivial to implement.

I didn't say that it did. But the flexibility does allow the feature to 
be implemented in whatever combination of client-side Javascript and 
server-side programming you wish.

> In particular, the bridged line appearance still requires that a 
> conference be established. With generic rtcweb clients, that probably 
> means a central mixer. Setting that up is relatively easy if there is 
> a central media termination point in rtcweb server, and it *has* mixer 
> capabilities.

Agree.

> simple with voip, no matter how you do it.

Also agree.

The real difference comes with the programming model. With a SIP phone, 
to add bridged line appearance support you need to write a new spec 
(that doesn't exist), get consensus around that spec, and then upgrade 
the phone firmware. With an SCCP (Skinny) phone, to add bridged line 
appearance support you simply write some additional code that runs at 
the server end that changes when the lights are commanded to turn on and 
off, controls what happens when a lit line button is pushed, and 
commands the phone to send the right kind of media to the right place.

There is no reason why we should make a web browser, which has the added 
advantage of a local execution environment for Javascript, *less* 
capable than the aforementioned server-controlled phone.

Matthew Kaufman

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Sep 2011 19:38:25 -0400

Mary,

My assertion that the analog implementation of these features was easy 
was in reference to support of multiple "extensions" on a single analog 
line, as Matthew mentioned earlier, where shared line appearances and 
bridging come "for free", though with some limitations.

I realize that it got considerably more complex with analog PBXs.

	Thanks,
	Paul

On 9/7/11 2:24 PM, Mary Barnes wrote:
> On Wed, Sep 7, 2011 at 10:18 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Matthew,
>
>     Good summary.
>
>     portions of these features with generic webrtc clients. But it
>     doesn't make these features trivial to implement. In particular, the
>     bridged line appearance still requires that a conference be
>     established. With generic rtcweb clients, that probably means a
>     central mixer. Setting that up is relatively easy if there is a
>     central media termination point in rtcweb server, and it *has* mixer
>     capabilities.
>
>     these features that are so trivial in analog telephony just aren't
>     so simple with voip, no matter how you do it.
>
> systems).  IMHO, it's this misconception that the services and
> functionality in analog telephony systems was simple that's led to the
> difficulty in getting any operability for these services defined for
> SIP.  Many of the legacy telephone systems were no more designed for a
> host of complex services than SIP was.  However, it would have been nice
> if services had been considered in the initial design for SIP.  While
> there is the concept that many services can be accomplished with basic
> SIP building blocks/headers, we have way too many situations where this
> has proven to not be at all simple.  But, I don't think SIP/VoIP is any
> worse off than were the legacy systems. And, I agree with Paul there
> isn't any magic dust that will make it any easier for RTCWEB to support
> these features.  [/MB]
>
>
>             Thanks,
>             Paul
>
>
>         _________________________________________________
>         rtcweb mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>     _________________________________________________
>     rtcweb mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 11:22:45 -0400

> commands the phone to send the right kind of media to the right place.

I think what you are saying is that with rtcweb you can build a 
replacement for Cisco Call Manager - with rtcweb replacking SCCP, and 
the call manager itself subsumed into a web server. This then allows any 
rtcweb enabled user device to be used instead of a Cisco proprietary 
phone. I agree with that, and its likely to be a good thing. (But maybe 
not for Cisco.)

At a macro level that thing seems to have the same centralized 
architecture as the Call Manager. Call Manager never bought into the sip 
vision that the phones should be largely autonomous, and this approach 
using rtcweb doesn't either.

The complexity of standardizing features like bridged line appearance 
arises if you try to follow that sip vision and allow autonomous sip 
devices to cooperate in that feature.

I've been pondering this for a long time. I have realized its not 
practical to standardize all the features that span multiple devices 
attached to the same AOR - that having a server for the AOR coordinate 
the features across the multiple devices is more practical. And that 
rtcweb is a great way to do that without locking down the choice of devices.

But I think the situation is different for coordinating features that 
span the multiple endpoints of a realtime communication session. Then it 
comes down to a case by case analysis of how important it is for a 
particular feature to be ubiquitous. For instance, maybe you want to use 
Facebook as your "call agent" for realtime communications. But does that 
mean you can't communicate with me because I'm not a Facebook user? 
Ideally you can still reach me while using Facebook as your call agent. 
Then there are *some* features that will ideally still work, while there 
might be other features that only work when both ends are facebook users.

Those features that are to be more ubiquitous will require more 
standardization effort than those that aren't. (No free lunch.)

Rtcweb ought to work with both sorts.

> capable than the aforementioned server-controlled phone.

Note that Call Manager can use SIP phones as well as SCCP phones. And 
when those sip phones have the Cisco secret sauce (which deviates only 
mildly from *real* sip) they have all the functionality of the SCCP phones.

I would expect that whatever way this debate ends (sip in the browser or 
not) the web browser should have the same level of functionality.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 8 Sep 2011 11:45:47 -0400

Some questions/comments inline...

Thanks,
Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Paul Kyzivat
> Sent: Thursday, September 08, 2011 11:23 AM
> To: Matthew Kaufman
> Cc: [email-masked]
> Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase &
> architecture: Browser application with separate webserver &
voipserver)
> >> portions of these features with generic webrtc clients. But it
doesn't
> >> these features that are so trivial in analog telephony just aren't
so
> mean you can't communicate with me because I'm not a Facebook user?
[TOLGA] Yes, I think so if the service provided by Facebook is
"capability to establish a call to another Facebook user". If it is
"capability to call any phone number", then one would be able to call
any phone number, and if it the ability to call a Service-X identity, it
will do so. I guess the notion of "capability to call anybody" is very
vague. It all depends on the "identity context" + "identity to call" and
that will be determined by the service AFAICS. 
> not) the web browser should have the same level of functionality.
[TOLGA] Can I assume that you mean "webbrowser + JS" instead of
"webbrowser as is"?
I am not entirely sold on the idea that SIP endpoint is equivalent to a
webbrowser from architectural point of view (even with JS).

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 13:09:16 -0400

On 9/8/11 11:45 AM, Asveren, Tolga wrote:
>> Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase&
>> architecture: Browser application with separate webserver&
> voipserver)
>>

> that will be determined by the service AFAICS.

Agreed - clearly either sort of service could be provided.

At the moment its a battle for dominance between a number of these 
services, so often they have negative motivation to federate. But this 
too shall pass, and it will be acknowledged that Facebook users can have 
friends on LinkedIn, and that LinkedIn users can have Contacts on Facebook.

> [TOLGA] Can I assume that you mean "webbrowser + JS" instead of

Yes. What else could I mean? A web browser without an JS can't really do 
much interesting.

	Thanks,
	Paul