Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00

[Hadriel Kaplan <[e-mail]>]

Partha,
comments inline...

On Oct 25, 2011, at 12:56 AM, Ravindran Parthasarathi wrote:

> But I'm not in
> agreement with the requirement in Sec 6 and Sec 7 of your document
> because it influence the specific implementation. 

Just to be clear, and the draft is a bit confusing about this: the draft isn't stating that the RTCWEB Working Group has to comply with all the requirements - in fact, I expect some can't be complied with due to security issues or IPR issues.  It's merely stating what has to be done to avoid needing an interworking function in the signaling and/or media-planes, for various common use-cases; and what the complexity is for the different interworking functions should they be needed.

There was an expressed desire from some of the WG members that interworking with deployed SIP devices be possible, with as little complexity as possible, and this draft is just stating what that would entail for various use-cases.  That way we can come to some consensus on what RTCWeb needs to support and how.


> I'll take A1-1 requirement of SIP forking wherein it is very much
> possible for RTCWEB-SIP gateway to hide the forking functionality from
> browser and it is normal B2BUA (SBC in market term) functionality in SIP
> wherein originating SIP UA does not support forking properly. IOW,
> please don't add requirement in RTCWeb for the sake SIP interop and it
> is possible to design the better gateway if required. I'm looking for
> standard RTCWeb signaling protocol like ROAP by which better solution
> for RTCWeb-federation gateway is documented in IETF.

Of course an SBC or gateway could do that - an SBC or gateway can do all of it, obviously, and some already do most of it already today.  That's not the point.  The point is there's complexity involved in the functions, which translates to cost ultimately, and if we want to keep the complexity down we need to try to avoid needing to do them, or as many of them as possible/practical.  For example many SBCs can do transcoding, but it costs money and potentially impacts call quality, so we should try avoiding that... especially since it's easy to avoid in the G.711 case. (G.711 is trivial to implement and not under IPR, afaik)


> Also, I'm interested in hearing about other RTCWeb federation protocol
> like Jingle before doing the deep-dive into the requirement because my
> gut feeling is that we will end-up in multiple federation protocol
> rather than single.

The draft isn't suggesting SIP be a mandated "federation" protocol.  I don't believe we can nor should mandate a federation protocol, nor any protocol outside of RTCWeb.  But SIP is an IETF protocol and quite popular, so this is just an Informational draft stating what would be needed to do so, to/from deployed SIP domains/devices.

Also, I don't use the word "federation" in the draft for a reason: an obvious use-case for RTCWeb is one where an Enterprise uses RTCWeb on their Web servers, for either their employees or for customer pages such as support or sales pages, but needs to interwork that to SIP internally to their SIP systems for numerous reasons.  Likewise a SIP Service Provider could use RTCWeb as another means of customer universal access, and interface it to SIP to reach their SIP devices/systems.  It's not "federation" - it's just going from RTCWeb to deployed SIP devices/systems, possibly in the same administrative organization/company.

-hadriel