Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 21 September 2011 06:23 UTC
Return-Path: <pravindran@sonusnet.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 163A121F8C1A for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 23:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.206
X-Spam-Level:
X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6]
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 cRR5Pb8pK8ps for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 23:23:24 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DAC9521F8C0C for <rtcweb@ietf.org>; Tue, 20 Sep 2011 23:23:23 -0700 (PDT)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8L6QKQ5006549; Wed, 21 Sep 2011 02:26:20 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 02:25:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7827.4BC34839"
Date: Wed, 21 Sep 2011 11:55:45 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0E6B@sonusinmail02.sonusnet.com>
In-Reply-To: <CAD5OKxvq3DhAimZ4UeRBxTCbeQhqCP9+gkWJwsUa0Tb5CS5OdA@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: Acx4BRNOQgN6BStIT/S6yHJQj92ghQAH1idA
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><2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> <CAD5OKxvq3DhAimZ4UeRBxTCbeQhqCP9+gkWJwsUa0Tb5CS5OdA@mail.gmail.com>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Roman Shpount <roman@telurix.com>
X-OriginalArrivalTime: 21 Sep 2011 06:25:48.0745 (UTC) FILETIME=[4D932B90:01CC7827]
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 06:23:25 -0000
Hi Roman, Thanks for the correction. I agree with you that there is no need to mention that forking is not support in RTCWeb. Your simple model works for browser as RTP End-point. One problem with the generic statement of multiple answer is that it may violate offer/answer model itself. For example: 18x and 200 having different answer for INVITE offer (standard implementation violation of offer/answer ;-)) Hope we are in the same page that forking related API and its parameters shall be decided by W3C Thanks Partha From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, September 21, 2011 7:51 AM To: Ravindran Parthasarathi Cc: Hadriel Kaplan; Cullen Jennings; rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Small correction to what you are saying -- new dialogs cannot be stopped using CANCEL (this will stop all dialogs). They can only be stopped using BYE. I would consider it very unfortunate if we decide not to support forking in RTC. It needs to be handled, and not in signaling, but by defining what to do with multiple incoming media RTP streams and multiple answers. The simplest model would be ignore everything except the RTP media defined in the last answer and have an ability to update the answer to the last offer. Alternative would be to create a new PeerConnection based on a new answer (this is API change so should probably go to W3C). _____________ Roman Shpount On Tue, Sep 20, 2011 at 10:11 PM, Ravindran Parthasarathi <pravindran@sonusnet.com> wrote: Forking in SIP does not apply in the literal sense to lot of SIP applications (ISDN-SIP gateway, End-point which can't perform mixing). In case of ISDN-SIP gateway, SIP callleg has to handle all forked dialogs till 200 OK is received from anyone of the UAS and reject all other dialogs with CANCEL, the media plane update is depend upon the implementation whether to override the last SDP in media plane in case mixing is not possible. I'm saying in this mail thread to highlight forking handling in browser (as a SIP UA application) is not an exception and it is the decision which has to be taken by any SIP application development (and not SIP framework) for that matter. SIP application forking behavior depends upon RTP model (endpoint or mixer). In case browser acts only as endpoint, I agree with Cullen that forking shall be handled by browser without application aware and no need of API or callback. The counter argument may be that my innovative mixing application in browser is stopped by this API model. In the generic SIP framework, the callbacks are provided to handle this situation, default callback function (browser as endpoint) are provided to reduce the application awareness. From the API perspective, offer & answer state machine is not required to be handled in application but we required to know whether the application prefers which media model whether as end-point or mixer and let end-point model be default. IMO, it is browser API design which belongs to W3C. Please correct me here in case this API design is somehow related to IETF. Thanks Partha >-----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 >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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- Re: [rtcweb] Minimal SDP negotiation mechanism Olle E. Johansson
- [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Minimal SDP negotiation mechanism Paul Kyzivat
- Re: [rtcweb] Minimal SDP negotiation mechanism Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Iñaki Baz Castillo
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Minimal SDP negotiation mechanism Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Iñaki Baz Castillo
- Re: [rtcweb] Minimal SDP negotiation mechanism Magnus Westerlund
- Re: [rtcweb] Minimal SDP negotiation mechanism Roman Shpount
- Re: [rtcweb] Minimal SDP negotiation mechanism Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Cullen Jennings
- [rtcweb] Forking & Early Media - Was Re: Minimal … Cullen Jennings
- Re: [rtcweb] Minimal SDP negotiation mechanism Cullen Jennings
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Cullen Jennings
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Dzonatas Sol
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Ravindran Parthasarathi
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Olle E. Johansson
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Ravindran Parthasarathi
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Saúl Ibarra Corretgé
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Forking & Early Media - Proposal Randell Jesup
- Re: [rtcweb] Forking & Early Media - Proposal Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Magnus Westerlund
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] Forking & Early Media - Proposal Roman Shpount
- Re: [rtcweb] Forking & Early Media - Proposal Randell Jesup
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Cullen Jennings
- [rtcweb] SIP Glare - Re: Minimal SDP negotiation … Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Tim Panton
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Roman Shpount
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Magnus Westerlund
- Re: [rtcweb] Forking & Early Media - Proposal Elwell, John
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Harald Alvestrand
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Iñaki Baz Castillo
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Dzonatas Sol
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Matthew Kaufman
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Iñaki Baz Castillo
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Iñaki Baz Castillo
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Matthew Kaufman
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Christer Holmberg
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Randell Jesup
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Magnus Westerlund
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Harald Alvestrand
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg