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

Roman Shpount <roman@telurix.com> Thu, 22 September 2011 14:47 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDCC21F8505 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 07:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.741
X-Spam-Level:
X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnno3emCDTdJ for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 07:47:09 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAB221F84D6 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 07:47:09 -0700 (PDT)
Received: by yxt33 with SMTP id 33so2448801yxt.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 07:49:41 -0700 (PDT)
Received: by 10.150.69.26 with SMTP id r26mr240821yba.322.1316702980746; Thu, 22 Sep 2011 07:49:40 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id q16sm4295838ybf.8.2011.09.22.07.49.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 07:49:40 -0700 (PDT)
Received: by yxt33 with SMTP id 33so2448787yxt.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 07:49:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.34.138 with SMTP id z10mr4478920pbi.105.1316702979362; Thu, 22 Sep 2011 07:49:39 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 07:49:39 -0700 (PDT)
In-Reply-To: <D1E0CC49-9D6A-45C9-9EA8-89093822ACD7@acmepacket.com>
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <3A175754-2318-4512-98C5-F8742A82067E@cisco.com> <D1E0CC49-9D6A-45C9-9EA8-89093822ACD7@acmepacket.com>
Date: Thu, 22 Sep 2011 10:49:39 -0400
Message-ID: <CAD5OKxurrFLBYzG0xQJB9r5JYJHL838h64B_aBW+3_bgHVuN7g@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary=bcaec52163035c0e8c04ad88cd82
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2011 14:47:10 -0000

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 <HKaplan@acmepacket.com>wrote;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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>