Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Dzonatas Sol <dzonatas@gmail.com> Tue, 20 September 2011 21:48 UTC
Return-Path: <dzonatas@gmail.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 868C41F0CA6 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 14:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.812
X-Spam-Level:
X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 aXoZ3+p9B4jw for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 14:48:56 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3EE61F0C87 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 14:48:56 -0700 (PDT)
Received: by iaby26 with SMTP id y26so1242676iab.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 14:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u5SZxWfy3K/0vieUyfxyHLqCPoI15lzO07as0g4QISs=; b=RNc+WY1/gJ6GqUp1wqvLj19GUUHQuz5kNAVwVJYs9O+6MZYFmBFqDD/a69Ippgk2tq YHQ6YsQ/ozYIB+y00mv+0LJzHw1u4tCk9JZ9hZ1DchoM3dZNPD3hCS2ejDdz6CIWLuCS fWi9jeLbrdQuBe8G1yHsRrdjoaKZLkhhOU8Bo=
Received: by 10.231.60.139 with SMTP id p11mr2183032ibh.73.1316555475329; Tue, 20 Sep 2011 14:51:15 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id ee29sm3785313ibb.9.2011.09.20.14.51.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 14:51:14 -0700 (PDT)
Message-ID: <4E790B59.2010202@gmail.com>
Date: Tue, 20 Sep 2011 14:53:29 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
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> <FFE7B9DF-9343-4D77-A189-CD1A6813AA19@edvina.net> <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com>
In-Reply-To: <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Tue, 20 Sep 2011 21:48:57 -0000
On 09/20/2011 01:39 PM, Cullen Jennings wrote: > On Sep 20, 2011, at 2:17 PM, Olle E. Johansson wrote: > > >> 20 sep 2011 kl. 22:07 skrev Cullen Jennings: >> >> >>> On Sep 20, 2011, at 7:07 AM, Olle E. Johansson wrote: >>> >>> >>>> 20 sep 2011 kl. 15:00 skrev Harald Alvestrand: >>>> >>>> >>>>> Once we start requiring that the PeerConnection know the difference between "early" media and "late" media, it seems to me we're slipping down a slippery slope. >>>>> >>>> The difference between early and late media is purely a billing decision in PSTN. I don't think we should separate these on the rtcweb side. It's a PSTN gateway issue, not something to be bothered with in rtcweb. >>>> >>>> "The campaign to simplify call states" >>>> >>> Simplification is good - just make sure that it is possible to gateway to a SIP call to 1-800-go-fedex. A simplification that broke that would, in my personal opinion, would not be acceptable. (and I think that early media is a bit more than just a billing artifact but that's a longer story). You agree? >>> >> Absolutely, but if the call is in UP state on the rtcweb side as soon as the PSTN/SIP gateway receives early media we will have no issue with sending DTMF in early media, which is what you are trying to trick me with :-) >> > really I was not going to mention DTMF :-) > > I was thinking a a call where the browser initiates the call, sends something to the web2sip signaling gateway that sends a SIP invite to the PSTN GW. Now the PSTN gateway sends a 180 and starts ICE. The PSTN GW sounds like a room pressure aware device that may encounter said vacuum space on return. That resolves the potential error on GLARE exceptions. Instead of "stable", the mobile units wants ubiquity with real-time GLARE-to-FIXATED states, smoothly. Or; in return, the display unit and mobile unit become actors in use-cases (and used-cases), so we clarified (the two) for rtp-usage. JIT repository is FIXATED when there is no HTTP sent/delivered due to non-expired certificates. Browsers that have no encryption provided by the certificate is not obligated to store such bytecode in non-obvious encryption; thus, raises the bar a little on reason to federate to FIXATED-known headers; no X-, no 0day. JIT repository that stay FIXATED for more than one day are then valuable. The sites' bytecodes simply tune-out the origin servers that deal only with unified user-agents, as the FIXATED state cares more about the agent than the user (note-well vs. E911 recommendations). SIP presents RTCWeb with many ways to undo, untwist, or simply focus on the user more, yet professionally there is no FIXATED state, or we have no professional reason why such FIXATED state of JIT does not exist and displays continue to consume power while on-the-... federated signal. Elevators that just want the SSRC for MMUSIC, there are professionally known geolocations for that range and length of signal. We think of treats, not tricks. > Then the PSTN GW starts sending RTP with the fedex prompts in them and then it eventually sends a 200. The key thing is the browser needed to be able to receive RTP before the signaling gateway received the 200. As long as we are on the same page there, it's good with me. The PSTN GW sends the RTP directly to the the browser but sends the SIP to the signaling gateway. > > > >> Now, if we force early media which is supposed to be one-way, not many implementations would support fedex. I don't see this as a problem if we just forget the early-media and late-media difference and just talk about media and if it's up or not up. That would handle ringback as well. >> > I could care less about if the media is 1 way or two way. I just care about hearing the prompts when I call 1-800-fedex. (I care about early media, not one way media :-) > > >> In my head, rtcweb is only the handset of a phone. The phone knows about early media, but the handset just has a mike and a speaker and it's simply on or off. >> > sure - not problem with that > > >> >> >>> 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. 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. >>> >> SBS or b2bua - in this case rtcweb to SIP ua. Yep, that's my way of thinking. >> >>> What I'm trying to say is I agree that early media + forking is hard, and the way I would like to simplify that is not allow forking. Note that none of this has much to do with if the PeerConnection object knows if media is early or late - what it needs to deal with is receiving RTP regardless os if the SIP signaling GW had sent it any signaling that indicated what had been in the SIP answer of the SIP side of a signaling GW. >>> >> Agree. >> >> /O >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- <i>The wheel.</i metro-link=t dzonatasolyndra>
- 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