IETF Logo Mail Archive

Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 30 April 2012 16:22 UTC

Return-Path: <eckelcu@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 46B3521F8773 for <rtcweb@ietfa.amsl.com>; Mon, 30 Apr 2012 09:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.513
X-Spam-Level:
X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 thp1EHvCLo74 for <rtcweb@ietfa.amsl.com>; Mon, 30 Apr 2012 09:22:45 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99A21F877E for <rtcweb@ietf.org>; Mon, 30 Apr 2012 09:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2044; q=dns/txt; s=iport; t=1335802962; x=1337012562; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=cmFba//6iwEJN4bjipyjCyCLpUKMGyGdMfZ5HKc4wSY=; b=N9s89yX5UeK5N2lAuBd9a5DmoLlGSREiBNj1sOrouFhKRjGQbqcHkrNw wpZSrk3dxVQ6yytu9YldJu4WPVxfvgSDz1zLmG0VBXKf7n5hynFLK410z xpPB9NwL4kfQOK4CXvZP/aZiRkcvaICkS9Pv/CO8wIlL/j2WbfS93x4cR Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAFS7nk+rRDoJ/2dsb2JhbABEr0iDAIEHggkBAQEEAQEBDwEUCQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah2oBC5oVn3EEkD9jBIhklnSEf4Fpgwg
X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208";a="39701928"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 30 Apr 2012 16:22:42 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3UGMgg1020417; Mon, 30 Apr 2012 16:22:42 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 09:22:41 -0700
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: Mon, 30 Apr 2012 09:22:42 -0700
Message-ID: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C06EED670@xmb-sjc-234.amer.cisco.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0mnx+EQrlVrvWDRey+KwUxgcHWewAThDfg
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com>
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>, Justin Uberti <juberti@google.com>, Cullen Jennings <fluffy@iii.ca>
X-OriginalArrivalTime: 30 Apr 2012 16:22:41.0978 (UTC) FILETIME=[77A159A0:01CD26ED]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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, 30 Apr 2012 16:22:50 -0000

Hi Partha,

I believe such a flow illegal, per RFC 3311:

      o  If the UPDATE is being sent before the completion of the INVITE
         transaction, and the initial INVITE contained an offer, the
         UPDATE cannot be sent with an offer unless the callee has
         generated an answer in a reliable provisional response, has
         received a PRACK for that reliable provisional response, has
         not received any requests (PRACK or UPDATE) with offers that it
         has not answered, and has not sent any UPDATE requests
         containing offers that have not been answered.

Cheers,
Charles

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Ravindran, Parthasarathi
> Sent: Monday, April 30, 2012 12:02 AM
> To: Justin Uberti; Cullen Jennings
> Cc: rtcweb@ietf.org
> Subject: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
> 
> Justin/Cullen,
> 
> Could you please explain in case for an SDP_OFFER(1), the remote
entity
> replies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the
> expected behavior. The exact callflow is as follows:
> 
> 
> Browser1-------------------------Browser2(SIP-JSEP gateway)
>     |        SDP_OFFER(1)            |  INV with offer1
>     |------------------------------->|--->
>     |       SDP_PRANSWER(1)          |  183 with answer1
>     |<-------------------------------|<---
>     |       SDP_OFFER(2)             |   UPDATE with offer2
>     |<-------------------------------|<---
>     |       SDP_ANSWER(2?)           |
>     |--------------------->?
> 
> The reason for this O/A callflow is due to UPDATE method (RFC 3311)
> mapping in Browser 2 (SIP-JSEP gateway).
> 
> Thanks
> Partha
> 
> PS: For simplicity, PRACK message exchange is not chosen in SIP side.
> 
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email