Re: [rtcweb] Agenda requests for Atlanta meeting

James Polk <jmpolk@cisco.com> Fri, 12 October 2012 19:21 UTC

Return-Path: <jmpolk@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 316AB21F86DD for <rtcweb@ietfa.amsl.com>; Fri, 12 Oct 2012 12:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level:
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRF2S07U8Qo2 for <rtcweb@ietfa.amsl.com>; Fri, 12 Oct 2012 12:21:17 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14CD421F86E2 for <rtcweb@ietf.org>; Fri, 12 Oct 2012 12:21:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6407; q=dns/txt; s=iport; t=1350069677; x=1351279277; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=fOYIx6AX3ssGk39yXsqV+I89rLGcXDUEOt9kvc34e80=; b=YG+W2G7PD7eHvlBQ8lt8/GUlMjKI2Pkf6gWUEJdDpeQP2ri4v2g5JkFX 5qSq5h2P3afo+oRohc1DimXxOLo6/Supdu/CRC1u3dqsTPJDEoOB9KVls mHpW3694yFDkx6s+pNnlJOcMdluE8yHihzMtx6kiM98TsxeM/SGiSq4Sx I=;
X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="130864140"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 12 Oct 2012 19:21:16 +0000
Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CJLGse016666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 19:21:16 GMT
Message-Id: <201210121921.q9CJLGse016666@rcdn-core2-1.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Oct 2012 14:21:14 -0500
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Parthasarathi R <partha@parthasarathi.co.in>
From: James Polk <jmpolk@cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.ee mea.ericsson.se>
References: <506B0367.4000103@ericsson.com> <C5E08FE080ACFD4DAE31E4BDBF944EB111867718@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB11187F8F1@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1118810C3@xmb-aln-x02.cisco.com> <CABkgnnV8YbbPi3pZt9mBjBfSgkx4EgL=EY0YogpeRobUMQ506w@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1118819FB@xmb-aln-x02.cisco.com> <000b01cda720$bd5097a0$37f1c6e0$@co.in> <C5E08FE080ACFD4DAE31E4BDBF944EB11188661A@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.eemea.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
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: Fri, 12 Oct 2012 19:21:19 -0000

At 12:43 PM 10/12/2012, Christer Holmberg wrote:
>Hi,
>
> > I fully agree this needs to work early media to PSTN via SIP. I 
> don't see any problem with doing that. I'm happy to work through 
> detail call flows to make sure that early media to PSTN works.
> >
> > Update after a 180 is not allowed by the Update RFC as I pointed 
> out in other email exactly because just in SIP with no RTCP web, 
> the UA that caret the invite would not have enough information to 
> be able to process this as you point in the thread below.
>
>As far as I know, UPDATE is allowed after a reliable 180. If you 
>don't agree, please show me the text which forbids it :)

UPDATE is allowed after a before and after a 180, and allowed after a 
200 OK to the INVITE. RFC 6442 (Geolocation Header) took advantage of 
this function through/with/by/whatever the blessing of Jonathan R.

James


>Regards,
>
>Christer
>
>
>
>On Oct 10, 2012, at 1:51 PM, Parthasarathi R 
><partha@parthasarathi.co.in> wrote:
>
> > Cullen,
> >
> > As signaling is moved to JS (application layer), Offer-answer in 
> JSEP has to
> > be generic enough. The underlying assumption in PRANSWER state is that
> > webserver knows whether the received SDP from remote is PRANSWER or final
> > ANSWER. Unfortunately, Webserver may not able to tell whether the 
> receive in
> > lot of real time deployment which is an open issue now. UPDATE offer after
> > 18x answer from remote is the typical example where PRANSWER state breaks.
> > The real-time usage of SIP UPDATE offer is to update the existing answer in
> > 18x in the same dialog. Early dialog UPDATE callflow is well deployment
> > because of PSTN remote ringback (18x) from media server and then 
> UPDATE with
> > SDP to update the media information of remote endpoing and then, call
> > connect (200 ok) from actual endpoint. The same PSTN callflow shall be
> > achieved by serial forking as well. Please note that the final 
> answer or not
> > is not based on browser or originating SIP UA but it is based on the
> > intermediate SIP entities.
> >
> > From RTCWeb perspective, The new OFFER is possible to be received 
> in browser
> > as per RFC 3264 after the first answer is received. PRANSWER is the new
> > state in JSEP wherein JSEP is the extension of RFC 3264. It will be good in
> > case you explain how browser in PRANSWER has to handle new OFFER from the
> > remote side.
> >
> > Please include me in case any phone discussion if you are planning.
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> > Cullen Jennings (fluffy)
> > Sent: Wednesday, October 10, 2012 1:35 AM
> > To: Christer Holmberg
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
> >
> >
> > On Oct 9, 2012, at 12:04 , Christer Holmberg
> > <christer.holmberg@ericsson.com>
> > wrote:
> >
> >> Hi,
> >>
> >>>> I have not seen any reason to relax 3264 yet but if something comes up,
> > agree we should carefully look at the cases. I think we can just 
> do straight
> > up 3264.
> >>>
> >>> RFC 3264 doesn't describe PRANSWER.  The concept is entirely absent.
> >>>
> >>> The offerer MAY immediately cease listening for media formats that
> >>> were listed in the initial offer, but not present in the answer.
> >>>
> >>> "the" answer.
> >>
> >> I agree with Martin. 3264 O/A is always per dialog, and forking is
> > supported by generating multiple dialogs. JSEP, OTOH, in order to support
> > forking with a single "dialog" (peerConnection local descriptor), now
> > defines O/A as offer+any number of pranswers + answer.
> >>
> >> So, we would e.g. have to define what happens if a new offer is received
> > from the remote side while the browser is in pranswer-received 
> state (see my
> > call flow in another reply).
> >
> >
> > 3264, SDP, 3261, and related documents are dealing with a bunch of things
> > including what happens at media plane and signaling plane.
> >
> > I'll note that though O/A is per dialog, there is only one O shared across
> > multiple legs and when you create the O you don't know how many dialogs
> > there will be. So from the media point of view (covered more in SDP spec
> > than 3264) there is one O with a bunch of A. From signaling point of view
> > there are a bunch of O/A pairs).
> >
> > The dialog is SIP signaling concept not a media plane level concept. We
> > moved the signaling part out of the browser and into the JS. But the media
> > part is still in the browser. So as 3264 says, after the offer is
> > constructed, we have to be willing to receive media for all the codec type
> > in the offer. When we get the answer 3264 makes it clear that one MAY stop
> > receiving the codecs that were in the offer but not selected in the answer.
> > However, this can not be done until the signaling layer is sure 
> that no more
> > offers will be honored. Since that signalling part of 
> Offer/Answer is in the
> > JS, the API need to to have a way to signal what the MAY part should do and
> > that is the PRANSWER vs ANSWER.
> >
> > People keep trying to make this some complex weird argument 
> invoking the SIP
> > deities of the past and quoting incomprehensible phrases from various RFC
> > caved in stone but the bottom line in the code is very simple to 
> understand.
> > When creating the offer you alloced some resources ( like a port to receive
> > video on ). When you get an answer that does not use that 
> resource, you need
> > to tell the media stack if it should free the resources or not. O/A has
> > situation where you need to keep the resources available (like there are
> > more dialogs coming) and situation where you need to free the resource.
> > Since we split the signalling out of the browser and left the media in the
> > browser, we need be able to allow the JS that is dealing with signaling to
> > tell the browser when to free the resource.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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