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:51 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 3788921F8D5B for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 05:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level:
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 vvH5I5w0FGey for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 05:51:25 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6321F8D3F for <rtcweb@ietf.org>; Mon, 31 Oct 2011 05:51:25 -0700 (PDT)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9VCpv1K032255; Mon, 31 Oct 2011 08:51:57 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 08:51:21 -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 18:21:24 +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 18:21:23 +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 18:21:23 +0530
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Iñaki Baz Castillo <ibc@aliax.net>
Thread-Topic: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
Thread-Index: AQHMl8hDWxKjfg17L0K1sVMHltxMmJWWCBIAgABc26A=
Date: Mon, 31 Oct 2011 12:51:22 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CB914@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> <387F9047F55E8C42850AD6B3A7A03C6CB8C4@inba-mail01.sonusnet.com> <CALiegf=iV=d9b8TNRrv9dh-gUDMzFBdRbsaUhLHdrXBG55ieGg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522356F25B3@ESESSCMS0356.eemea.ericsson.se>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2011 12:51:24.0525 (UTC) FILETIME=[CC1909D0:01CC97CB]
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:51:27 -0000

Hi Christer,

I agree with you. By reading ROAP draft, I got the feel that it is possible to connect to multiple peer from single local offer and also, it is possible to update multiple peers during each offer/answer exchange.  It is slightly upper version of SIP parallel forking wherein multiple dialogs are created in terms of SIP due to forking and update each dialogs using RE-INVITE for media change. I like this usecase as this infrastructure helps for building complex media services in browser.

Thanks
Partha

>-----Original Message-----
>From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>Sent: Monday, October 31, 2011 6:08 PM
>To: Iñaki Baz Castillo; Ravindran Parthasarathi
>Cc: rtcweb@ietf.org
>Subject: RE: [rtcweb] Media forking solution for SIP interoperability
>(without a media gateway)
>
>
>Hi,
>
>I would suggest that, instead of talking about a single PeerConnection,
>we talk about using the same local IP parameters and candicates for
>multiple remote endpoints. It could be a single PC, or it could be
>multiple "cloned" PCs.
>
>Again, let's first decide whether we need it - then we can start
>thinking of how to get it :)
>
>Regards,
>
>Christer
>
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Iñaki Baz Castillo
>> Sent: 31. lokakuuta 2011 14:26
>> To: Ravindran Parthasarathi
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Media forking solution for SIP
>> interoperability (without a media gateway)
>>
>> 2011/10/31 Ravindran Parthasarathi <pravindran@sonusnet.com>:
>> > 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.
>>
>> The above requirements don't say that a *single*
>> PeerConnection MUST be able to send and receive streams
>> to/from several peers concurrently. It just says that the
>> *browser* MUST be able, and a way to achieve that is by
>> creating multiple concurrent PeerConnection objects.
>>
>>
>>
>>
>> --
>> Iñaki Baz Castillo
>> <ibc@aliax.net>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>

v2.23.0 | Report a Bug | By Email