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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 21 September 2011 11:32 UTC

Return-Path: <mperumal@cisco.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 E5CA821F8AFD for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 04:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8]
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 TfO22JsBfaWK for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 04:32:15 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A065321F84FD for <rtcweb@ietf.org>; Wed, 21 Sep 2011 04:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3362; q=dns/txt; s=iport; t=1316604883; x=1317814483; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Qz8ouOQsGxFo0snUOQUI38A2lpATgYeaBvmAdKUhkUw=; b=asr0om6unkJ1gKyLL25Tb5hlCmxtaXwJBB8p92aoz7Yh1YxR2bE7UVkv GMEvKj/BbzwUaIS7ccuTrHkuWd7NjkLcOpdj3XW+anU3CpvpbX3aF0dYe QHrm2ZAQkRXkRA5qHotlOz9PAu5lxUTUC39iluEKySgqIjNgOgNqiQmnw k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArAAAFfLeU5Io8UR/2dsb2JhbABCmHeOaXiBUwEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQsGFwEGASYfCQgCBAEKCAgRCYdblhQBnh2GHWAEh26RB4wQ
X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="116442002"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2011 11:34:41 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8LBYakU028874; Wed, 21 Sep 2011 11:34:40 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 17:04:39 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Sep 2011 17:04:37 +0530
Message-ID: <1D062974A4845E4D8A343C65380492020672BCFD@XMB-BGL-414.cisco.com>
In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCZVXrypA
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>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
X-OriginalArrivalTime: 21 Sep 2011 11:34:39.0887 (UTC) FILETIME=[72FF09F0:01CC7852]
Cc: 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: Wed, 21 Sep 2011 11:32:16 -0000

|Not really - there will be signaling, because there has to 
|be SDP answers even just to get ICE to work before the media 
|starts flowing in many NAT cases.  And even in practice in 
|SIP there're usually SDP answers in 18x to open "gates", and 
|to get upstream DTMF.  So if the concern is just that there's
|no signaling to tell the browser there are multiple RTP streams
|coming, I think that can be allayed.

I think it is further allayed with ICE because ICE requires that early
media be not sent until the ICE connectivity check is done and a valid
candidate pair is selected -- it requires implementations to delay
alerting the called party until this point (in the case of a PSTN
gateway, this would mean that the setup message into the PSTN is delayed
until this point). So, the RTCWeb app would have to just create a single
PeerConnection object for receiving/transmitting a media stream once
this procedure is completed.
 
Of course there is complexity in the SIP/PSTN interworking gateway, but
it doesn't look the RTCWeb app would have worry about it.

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf Of Hadriel Kaplan
|Sent: Wednesday, September 21, 2011 4:06 AM
|To: Cullen Jennings (fluffy)
|Cc: rtcweb@ietf.org
|Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP
negotiation mechanism
|
|
|On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:
|
|> That said, I think that doing both forking and early media is hard.
Lets assume we are using a
|signaling gateway that is not a media gateway to translate between a
SIP call on one side and whatever
|is happening over on the browser side. The basic issue is the browser
initiating the communications
|needs to be able to start receiving multiple RTP streams before it even
has signaling information to
|tell it how many it might receive.
|
|Not really - there will be signaling, because there has to be SDP
answers even just to get ICE to work
|before the media starts flowing in many NAT cases.  And even in
practice in SIP there're usually SDP
|answers in 18x to open "gates", and to get upstream DTMF.  So if the
concern is just that there's no
|signaling to tell the browser there are multiple RTP streams coming, I
think that can be allayed.
|
|The really hard part is knowing which stream to use/render/send-to,
imho.  And putting that decision
|in the gateway isn't good - the best decider of that is probably the JS
in the browser.
|
|
|> To simplify this problem, Cary and my draft proposes not allowing
forking on the SIP side of the
|signaling gateway but still allowing early media. If you wanted to do
do forking in this case, one
|would need a SBC that processed media and turned the forked medial legs
into one media leg.
|
|Obviously you can request that a request not be forked, using
caller-prefs, but you can't "not allow"
|forking on the SIP side.  That would make it not SIP.  I know forking
is hard, but that's life.  It's
|not appropriate for this WG to make fundamental changes/limitations to
the SIP protocol, just because
|some of it's "hard" for a browser.
|
|-hadriel
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb