IETF Logo Mail Archive

Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)

Ravindran Parthasarathi <pravindran@sonusnet.com> Mon, 31 October 2011 12:21 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 26BAD21F8DAF for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 05:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.674
X-Spam-Level:
X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599]
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 rpyg0OXZJlFt for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 05:21:12 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6456121F8DAE for <rtcweb@ietf.org>; Mon, 31 Oct 2011 05:21:10 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9VCLg5N012398; Mon, 31 Oct 2011 08:21:42 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 08:21:06 -0400
Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 17:51:09 +0530
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 17:51:08 +0530
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 17:51:08 +0530
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Harald Alvestrand <harald@alvestrand.no>, Cullen Jennings <fluffy@cisco.com>
Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
Thread-Index: AQHMl2DMJAhpsnUL9kK3CsrGujQNm5WVSEKAgAEIExA=
Date: Mon, 31 Oct 2011 12:21:08 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com>
References: <CALiegfkikmpi55ePUo=AQCQvorv4_6v2ByTCdL=V_=umcCEpUA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se> <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com> <4EADF511.2040403@alvestrand.no>
In-Reply-To: <4EADF511.2040403@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.54.32]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2011 12:21:09.0447 (UTC) FILETIME=[923A1D70:01CC97C7]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
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: Mon, 31 Oct 2011 12:21:13 -0000

Harald,

As per F11 & F12 of draft-ietf-rtcweb-use-cases-and-requirements-06 , 

   "F11             The browser MUST be able to transmit streams to
                   several peers concurrently.

   F12             The browser MUST be able to receive streams from
                   multiple peers concurrently."

The above browser requirement makes me to guess that it is possible to support SIP parallel forking sort of services in case proper JS APIs are provided (May be current form of peerconnection does not). Please let me know your opinion on this.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of Harald Alvestrand
>Sent: Monday, October 31, 2011 6:39 AM
>To: Cullen Jennings
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Media forking solution for SIP interoperability
>(without a media gateway)
>
>On 10/30/2011 11:41 AM, Cullen Jennings wrote:
>> On Oct 30, 2011, at 9:58 , Christer Holmberg wrote:
>>
>>> In my opinion a better solution is to create a new PeerConnection for
>every new early dialog, which uses the *same* address/candidate
>parameters as the "parent" PeerConnection.
>> Hmm we should talk about this - I have a hard time seeing how that is
>going to work. I was working on the assumption that  PeerConnection
>could deal with more than one offer/answer pair at a time. Given the
>current WebRTC API and something like ROAP - it seems like that should
>just work.
>I think having a single PeerConnection object send media to multiple
>peers at the same time breaks the model we've been working from.
>
>It may be reasonable to give a PeerConnection the ability to switch from
>one remote peer to another remote peer (to support 180-like things), but
>I don't think it's reasonable to have it connected to multiple remote
>peers.
>
>So if we support real forking, we'll have to create multiple
>PeerConnections to do that.
>
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email