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

["Ravindran Parthasarathi" <[e-mail]>]

Peter,

Thanks for forwarding info about draft-ietf-hybi-thewebsocketprotocol. I
started this mail thread to know whether RTCWeb1.0 is a unofficial
RFC3261bis for the line side (endpoint to access server) :-) [I really
don't know the better term for the line side]. Endpoint may be desktop,
smart phone (android), laptop, tablet, CPE, etc.,

Till reading this draft, I assumed websocket as a socket layer for HTTP
and it is bad assumption :-(. In short, browser is able to create two
way communication with webserver (which has globally routable address).
Two browser creating websocket with web servers will be able to
communicate with each other. This architecture exactly fits in SIP world
as
 
                       SIP UA <---->B2BUA<----->SIP UA

And resultant as   browser<---> webserver <----> browser. I tend to
agree with you that Websocket looks as a better choice for this simple
web architecture as there is no need of identity exchange here because
webserver knows and authenticated both browsers with the corresponding
identity. In fact, B2BUA with globally routable address will interop
better with any endpoint for that matter. The difference comes into
picture for federation (interop between servers). I'm not very clear
whether websocket is intended for federation as well or not. Most of the
discussion RTCWeb points to use SIP as a federation protocol which may
change later. I'm interested knowing your view here. For this mail, I
assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready to
change if it is the right thing to do :-)

I'm asking for the single protocol based on my gateway implementation
experience in signaling protocol like SIP, H.323, and basic of MEGACO,
Q.931 (ISDN) etc., My understanding is that mapping of between tow
protocols leads to get the common set in both protocol and under
utilization of specific protocol functionality. The mapping is not
perfect lot of times and one of the example which I know in IETF product
is RFC 3398. It is not possible in RFC 3398 to proper reverse mapping of
cause code for ISUP in case conversion in first gateway converts ISUP to
SIP, second gateway converts is SIP to ISUP, ISUP cause code value in
second gateway is not same what is received in first gateway and this
leads to lot of interop issue which includes passing of reason SIP
header with Q.931 IE recently as per IETF-80 decision (workaround bug
fix). This is not the only mapping failure which I have seen during the
gateway implementation. So, I prefer to look for the strong reason for
putting multiple protocol (SIP, websocket) as a RTCWeb architecture. 

Apart from this, my understanding is that websocket + REST XML is the
best choice in web world but SIP + REST XML is an overkill. My
understanding is based on SIPREC metadata XML design where I explored to
make REST XML which is generic for SIP and other protocols, but I
realized that REST XML is overkill for SIP as it has dialog context in
both server & client. Please let me know your comments on this.

Also, Endpoint shall be single IETF protocol for real-time communication
rather than having two protocols (SIP, websocket) for any application.
It looks inconsistent for Endpoint application to use SIP and Endpoint
browser application to use websocket. IMO, IETF should give some clarity
for better real-time network design here.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Peter Saint-Andre
>Sent: Friday, September 09, 2011 1:22 AM
>To: [e-mail]
>Cc: [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 9/8/11 1:22 PM, Igor Faynberg wrote:
>>> On 09/08/11 16:54, Igor Faynberg wrote:
>>> ...
>>
>>> If the issue is getting a signal from a Web server to a client,
>>> there's approximately 100 ways to get notifications from the server
>to
>>> the client using HTTP (hanging GET being one of them).
>>
>> I thought  that COMET-like polling is inefficient. Hanging GETs
>> require server resources to hold a TCP session o open. Firewalls and
>IE7
>> time out  a GET after 30-60 seconds.
>>
>>> Now that WS is getting standardized, there will be 101.
>>>
>>
>>  101st, seems to be a solution, I agree.  But it has not finished
>> standardization,
>
>draft-ietf-hybi-thewebsocketprotocol is close to approve as a Proposed
>Standard (discussed on this morning's IESG telechat, still a few issues
>to clean up). Not that PS means finalization.
>
>> while SIP has.
>
>SIP is not a full Standard. rfc3261bis, anyone? ;-)
>
>Peter
>
>--
>Peter Saint-Andre
>https://stpeter.im/
>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb