Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

[Roman Shpount <[e-mail]>]

Since we are commenting on this draft, I, as I've previously stated on this
list, really would not like to see SIP as something directly supported by
Web RTC, especially a version of SIP lite described in this draft.

If we decide to build SIP into RTC, I would assume we would need a secure
channel for signaling, so we will need TLS transport. Also, if we plan to
use ICE, SIP messages will be larger then the SIP standard limit set for UDP
transport, so even in the cases of non secure connections we will need TCP
for signaling, not UDP with STUN keep alives. If we decide to implement SIP
over TCP from behind NAT we will need to fix RFC 5626 to provide a contact
for calls and transactions that can be recovered after a TCP connection
reset. As far as I know this standard assumes that GRUU is used for call
contacts, and is recovered using new registrations, but does nor provide any
guidance on what suppose to happen with transaction responses if connection
is reset. After we fix this spec, industry will have to go and implement
signaling servers that support such functionality (ASFAK there are none in
existence) and proxy it to normal SIP. I believe, at this point it would
actually be easier to build a JavaScript library + HTTP(S) to SIP proxy.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 10:04 AM, Hadriel Kaplan <[e-mail]>wrote:

>
> On Sep 22, 2011, at 9:17 AM, Cullen Jennings wrote:
>
> > I'll note that Cary and my draft has been putting serious limitation on
> SIP since the beginning and we have yet to receive a comment on that. You do
> realize the outcome of this decision would be that you needed an SBC between
> the SIP to WEB Gateway and any SIP network that forked so that SBC could
> isolate the other side from the forks. As full disclosure, really, I don't
> own any ACME stock :-)
>
> Oh, I think we'll be busy enough. ;)
>
> Choosing the right fork is really hard. (or so it seems when I sit down at
> fancy restaurants)
>
>
> > Clearly one could support forking in the browsers and equally obviously,
> that complicates things fairly significantly. The question will be if the
> complexity is worth the end user gain in functionality.
>
> Ignoring the issue of not being SIP anymore, I think you'll want forking in
> the end.  Even in XMPP people have asked for it now and then.
>
> But anyway sorry I didn't read Cary and your draft before.  Would you like
> comments now?  :)
> First, I assume you mean draft-cbran-rtcweb-protocols-00.
>
> You have the following as optional:
>   o  INVITEs without an offer
>   o  re-INVITEs
>   o  forking
>   o  S/MIME
>   o  SIPS URI Scheme
>
> My comments:
> S/MIME has never seen the light of day and would be removed if we ever
> raised 3261 to the soon-to-be-second-and-final level of maturity, so sure.
> INVITEs without offers can be ignored in terms of generating them from
> rtcweb, but rtcweb has to be able to receive them. (I would think Cisco in
> particular would demand this ;)
> Re-INVITEs again may not need to be generated by rtcweb, but have to be
> able to be received. (it's not hard is it?)
> Forking is needed to eat our own dogfood with.
> SIPS is sadly rare, but ironically I would think the rtcweb model is one
> we'd actually want and use it in (because we could require HTTPS be used,
> and it probably would even happen!).
>
> Last comment: you gave me a good chuckle, making 4474/4916 required.  :)
>
> -hadriel
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>