Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

[Roman Shpount <[e-mail]>]

Partha,

What I am failing to understand is what you plan to use SIP for. SIP would
be useful to call a SIP end point on the public IP or behind the same NAT.
If you want to call another SIP end point behind NAT, especially if you need
to use TCP to send ICE offers or security with TLS, you will need an
assistance of some type of server on the public IP. In order for this to
work both server and the client will need to implement something like RFC
5626. This will require building something fairly tricky to essentially
proxy all the SIP requests from the client to all the other SIP points.
Building this is no easier then implementing the same thing using an HTTP
server application which works with a client JavaScript library. If our
primary goal were implementation of Intranet SIP phones, that would be an
acceptable solution. For consumer oriented RTC service this is completely
useless.

On the other hand extending SIP based infrastructure to implement new
functionality is a lot more complex. Adding new features will require
standardization or navigating a large number of conflicting SIP related
specifications which are currently in force. Also, keep in mind that
compliance to a lot of more advanced SIP specifications does not necessarily
imply easy interoperability with existing devices. Compliance to a lot of
those standards require a custom SIP server or SBC which implements them
using a much smaller subset supported by each different SIP device. Bottom
line, adding new features in SIP based environment typically requires a lot
of server development, which is pretty much what will be required for doing
signaling via an HTTP connection.

I will concur that using HTTP with JavaScript is a lot less efficient then
using SIP for both the client and the server, since client will need to
implement more functionality using JavaScript and the server will need to
maintain large number of connections and proxy all the requests, but this is
a drawback of any AJAX based solution. This is something that seems to be
acceptable to the industry and should not be a decisive factor.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi <
[e-mail]> wrote:

>  Harald,****
>
> ** **
>
> I’m proposing for “SIP UA framework for RTCWeb browser”, the framework
> provides Javascript API. In case you mean the same as “SIP lite”. I’m fine
> with it. SIP UA framework helps to support two-party communication from
> RTCWeb browser and uses HTTP as presence or configuration interface. ****
>
> ** **
>
> As I mentioned in the another mail, I’m talking about INVITE subset of RFC
> 3261 in browser.  ****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Harald Alvestrand [mailto:[e-mail]]
> *Sent:* Thursday, September 08, 2011 12:23 PM
>
> *To:* Ravindran Parthasarathi
> *Cc:* Matthew Kaufman; [e-mail]; [e-mail]
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]****
>
>  ** **
>
> On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: ****
>
> Harald,****
>
>  ****
>
> For browser as a SIP UA application, browser has to no need to compliant
> with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree
> with you that browser-to-browser communication, I could not see the strong
> reason for supporting S/MIME. As part of the RTCWeb architecture & solution,
> we will able to explore the SIP UA requirement for making browser SIP
> compliant.****
>
> So you're advocating for creating a "SIP lite" subset that RTCWEB browsers
> implement.
> I think we have been down this road before, and it's not a happy one.
> But sure - if you want us to implement some part of SIP, *please start
> stating what part* rather than making wooly statements.
>
> Subsets are Real Hard Work.
>
> ****
>
> Say for example, forking does not make sense in case of browser as SIP UA
> application, forked response will be rejected with CANCEL in browser without
> Javascript intervention. The main requirement is to build the right SIP UA
> framework in browser by which Javascript developer will be able to use to
> the maximum extent without impacting the basic 2 two party communication in
> the internet.  ****
>
>  ****
>
> As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a
> modern exchange in web world (Plain Old Telephony System phone with exchange
> architecture). I think so because POTS phones are dumb which does not know
> its identity and every event like offhook, onhook has to passed to exchange
> (webserver) whereas RTCWeb client (browser) has to pass every event to
> webserver and webserver has whole intelligence to make it work.****
>
> Don't forget that the RTCWEB client (the browser) contains an open, fully
> programmable application platform - the Javascript engine. That's a HUGE
> difference to the POTS phone.
>
> ****
>
> I got this feel more when someone is talking about MEGACO or MGCP between
> RTCWEB client & webserver. My understanding is that SIP does not fit well to
> legacy telephone-based paradigm by any means but MEGACO or MGCP are the
> better choice which maps to SS7 architecture well. I’m interested in seeing
> RTCWeb client perform the basic routing rather than webserver does the
> routing on behalf of RTCWEb client.****
>
>  ****
>
> I agree with you that in case it is local exchange (same site like skype or
> Google hangout) communication, there will be no need of signaling but I’m
> interested in communication with one of the Google real-time user in
> internet without having any Google id.  I believe that SIP will make it
> work.****
>
> If by saying "the Google real time user in Internet", you mean a Google
> Talk user, you have that already. It's called Google Voice. It uses SIP, but
> not in the browser.
>
> Talking to someone who doesn't want to talk to you is an use case we don't
> intend to support.
>
> ****
>
>  ****
>
> Thanks****
>
> Partha****
>
>  ****
>
> *From:* Harald Alvestrand [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Wednesday, September 07, 2011 11:13 PM
> *To:* Ravindran Parthasarathi
> *Cc:* Matthew Kaufman; [e-mail]; [e-mail]
> *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
> recording - RTC-Web client acting as SIPREC session recording client]****
>
>  ****
>
> On 09/07/11 19:29, Ravindran Parthasarathi wrote: ****
>
> Matthew,****
>
>  ****
>
> When I asked for SIP, I have meant RFC 3261 only.****
>
> This is 269 pages, and has 26 normative dependencies including S/MIME. It's
> not a small dependency.****
>
>
>
>
> ****
>
> The basic reason for asking SIP is to make the basic call works between
> browser to browser across web servers. Without SIP in browser, it is not
> going happen. Innovative application is going to be proprietary whether it
> is HTTP or SIP or any other protocol for that matter.****
>
>  ****
>
> My reasoning are as follows:****
>
> SIP makes browser more intelligence compare to dump signaling mechanism
> like MEGACO and browser acts as MG. ****
>
> Why does that "intelligence" need to be in the browser, rather than in the
> Javascript?
>
>
> ****
>
> The importance of basic call interop is that there is no need of many
> individual id like skype id, Google id  and yahoo id by everyone in the
> world to communicate others. I wish to have single id like e-mail id to be
> maintained by browser-to-browser users to communicate with others. ****
>
> This only makes sense for applications that fit the "call an identified
> party" paradigm.
>
>
> ****
>
> SIP helps to interop for basic call with other existing realtime
> application in Enterprise & Telecom provider.****
>
> There is no need to build two different signaling logic in VoIP servers for
> each service. Your own example of Bridge line appearance will need two
> implementation by the single vendor because desktop application or hardphone
> implementation based on SIP and browser based implementation is depend on
> HTTP metadata. It is possible to avoided by having one signaling protocol.
> ****
>
> One protocol can be achieved by multiple applications choosing to implement
> one protocol.
> It doesn't have to be enforced by the prtoocol being embedded in the
> browser.
>
>
> ****
>
>  ****
>
> In RTCWEB does not standardize the signaling protocol interface between
> browsers, the interop across webservers is next to impossible and it will be
> restricted to single webserver (company) only. Please let  me know in case
> I’m missing something here.****
>
>
> I think the main thing you are missing is that there are many applications
> that people want to build on top of RTCWEB that are not telephones, and will
> not fit with telephone-based paradigms.****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>