From pkyzivat@cisco.com Tue Feb 1 05:49:58 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96FD3A6D19 for ; Tue, 1 Feb 2011 05:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zqTPL+mtKIk for ; Tue, 1 Feb 2011 05:49:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 35E3B3A6D1C for ; Tue, 1 Feb 2011 05:49:57 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFeeR01AZnwN/2dsb2JhbAClBXOhAJsohVMEhROHEINCgxY Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Feb 2011 13:53:14 +0000 Received: from [10.86.251.161] (bxb-vpn3-929.cisco.com [10.86.251.161]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p11DrDf0022139 for ; Tue, 1 Feb 2011 13:53:13 GMT Message-ID: <4D481049.5000205@cisco.com> Date: Tue, 01 Feb 2011 08:53:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dispatch@ietf.org References: <4C8132A2-4024-4633-966D-F3F88B6E60A9@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D860F2C30@HE111648.emea1.cds.t-internal.com> <4D3EEE2F.4040202@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA25A@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA2AA@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFABF612F@HE111648.emea1.cds.t-internal.com> <4D42EB72.90302@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFABF6AE2@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFABF6AE2@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:49:59 -0000 I've realized via discussions with Christer that the changes here are introducing a conflict with the 199 draft. That draft is explicitly calling for use of a Reason header with sip cause code to indicate the final sip response that caused a 199 response to be sent. Because 199 is being defined to explicitly allow this usage, it is in compliance with 3326. If we were to revise 3326 as we are discussing, then the 199 usage would be in conflict with the revision. So, I think we have to craft the wording very carefully here, to allow the use of Q.850 codes in a range of responses, while leaving the use of sip reason codes up to per-response-code specifications, as it was. And I'll restate that it probably doesn't make good sense to use any/all Q.850 response codes in an arbitrary sip response either. Thanks, Paul On 1/31/2011 5:53 AM, R.Jesske@telekom.de wrote: > Hi Paul, > Thank you for the hint. > Yes I agree that it would be a little seldom if a SIP reason code would be included within a SIP Response. > So I tried to change the wording like: > > Section 3. New Text: > > Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request and in any response, if it contains a Q.850 Cause Code, except the 100 trying response. > > Section 4. New Text: > > The Reason header field containing a Q.850 Cause Code MAY appear in any request within a dialog, in any CANCEL request. The appearance of the Reason header is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x and 199 > > So I hope now the document is more consistent. > > Best Regards > > Roland > >> > >> -----Ursprüngliche Nachricht----- >> Von: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Freitag, 28. Januar 2011 17:15 >> An: dispatch@ietf.org >> Betreff: Re: [dispatch] Update fo RFC3326 or >> draft-jesske-dispatch-reason-in-responses approach >> >> >> >> On 1/28/2011 8:11 AM, R.Jesske@telekom.de wrote: >>> Hi Mary, >>> until now it looked for me it is the decision of people >> which way they >>> want to go. >>> So seeing from your mail I see that there an UPDATE to >> RFC3326 would be >>> more convenient and my other draft could help to have some >> reasoning/use >>> cases. >>> So I have Uploaded an draft proposing an UPDATE to RFC3326. >>> >> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >> -responses-00.txt >>> Comments are welcome. >>> Best Regards >>> Roland >> >> >> Its a very simple draft (which is fine). >> >> I do find an inconsistency. The overview states: >> >> This document specifies and formally permits the use of the >> Reason header field in SIP responses to carry Q.850 [Q.850]reason >> codes for this and other purposes. >> >> But the actual normative changes permit *any* sort of reason codes in >> responses. >> >> This could be especially confusing if a sip reason code is >> included in a >> sip response. >> >> Also, this says nothing about what it *means* to have a >> reason code in a >> response, while 3326 does say a bit about what it means to >> put a Reason >> in a request. In the case of Q.850 reasons its fairly >> obvious, at least >> coming from a Q.850 gateway. >> >> The simple answer here would be to exclude the use of SIP Reasons in >> responses. Else there had better be text on when it is >> appropriate. (And >> I can't think of any.) >> >> Thanks, >> Paul >> >>> >> -------------------------------------------------------------- >> ---------- >>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >>> *Gesendet:* Donnerstag, 27. Januar 2011 18:10 >>> *An:* Jesske, Roland >>> *Cc:* dispatch@ietf.org >>> *Betreff:* Re: [dispatch] Update fo RFC3326 or >>> draft-jesske-dispatch-reason-in-responses approach >>> >>> The problem is that the current wording in the draft implies an >>> update to RFC 3326 - i.e., it states: >>> This document >>> >>> specifies and formally permits the use of the >> Reason header field in >>> SIP responses to carry Q.850 reason codes for this and other >>> purposes. >>> >>> >>> So, the question isn't whether to progress the draft per se but >>> whether the implication of the functionality you describe is a >>> normative change RFC 3326 (i.e., UPDATES) or whether an >>> informational draft is sufficient. I would posit that >> if this work >>> is progressed as informational, then it should be restricted to >>> describing the use of SIP responses to carry the Q.850 >> reason codes >>> and drop the the "other purposes". And, you need to remove the >>> normative RFC 2119 language. In other words, if folks >> do not believe >>> an update to RFC 3326 is necessary then the drafts needs to be >>> revised to limit the scope and be quite clear that it >> is informational. >>> >>> Regards, >>> Mary. >>> >>> On Thu, Jan 27, 2011 at 10:31 AM,>> > wrote: >>> >>> So to clarify my opinion below. >>> used the wrong number. >>> >>> As long as the draft is already existing I have my >>> preference to go for 2. >>> >>> that is the problem using too easy numbering. >>> >>> Sorry >>> >>> >>> > -----Ursprüngliche Nachricht----- >>> > Von: dispatch-bounces@ietf.org >> >>> > [mailto:dispatch-bounces@ietf.org >>> ] Im Auftrag von >> Jesske, Roland >>> > Gesendet: Donnerstag, 27. Januar 2011 17:00 >>> > An: dispatch@ietf.org >>> > Betreff: [dispatch] Update fo RFC3326 or >>> > draft-jesske-dispatch-reason-in-responses approach >>> > >>> > >>> > Dear all, >>> > a couple of days we discussed how to proceed >> with the reason >>> > in responses. >>> > >>> > As I see we have enough support for going ahead. >> But which >>> > approach should we take. (Mary asked this >> question also on >>> Monday) >>> > >>> > 1. write an UPDATE to RFC 3326 >>> > 2. progress draft-jesske-dispatch-reason-in-responses >>> > >>> > Currently I have seen the following opinions: >>> > >>> > For solution 1. +1 Paul >>> > For solution 2. + Laura >>> > 1 or 2 don't mind +1 John >>> > >>> > As long as the draft is already existing I would have my >>> > preference to go for 1. >>> > But if needed I can also create an UPDATE to RFC3326. >>> > >>> > So please indicate your solution you would like to see. >>> > >>> > Thank you and Best Regards >>> > >>> > Roland >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> > >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From partr@cisco.com Tue Feb 1 06:46:17 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA34A3A6CEA for ; Tue, 1 Feb 2011 06:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.886 X-Spam-Level: X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkA+QF34Ie9c for ; Tue, 1 Feb 2011 06:46:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 356013A6C11 for ; Tue, 1 Feb 2011 06:46:15 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwCAO+rR02Q/khNgWdsb2JhbACWI45iFQEBFiIkoQKbIYVTBIURilo Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2011 14:49:31 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p11EnSkD003494; Tue, 1 Feb 2011 14:49:31 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 20:19:30 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC21F.3AEB2E80" Date: Tue, 1 Feb 2011 20:19:29 +0530 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFABF6DA5@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Update fo RFC3326ordraft-jesske-dispatch-reason-in-responses approach Thread-Index: Acu+RB4bhHL8q6N8R16OF4b3JYH4EgAAHWEVADG/omYAjwTdMAA0Zw4w References: <4C8132A2-4024-4633-966D-F3F88B6E60A9@cisco.com><580BEA5E3B99744AB1F5BFF5E9A3C67D860F2C30@HE111648.emea1.cds.t-internal.com><4D3EEE2F.4040202@cisco.com><580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA25A@HE111648.emea1.cds.t-internal.com><4D41A550.8010701@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFABF6DA5@HE111648.emea1.cds.t-internal.com> From: "Parthasarathi R (partr)" To: , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 01 Feb 2011 14:49:30.0527 (UTC) FILETIME=[3B5322F0:01CBC21F] Subject: Re: [dispatch] Update fo RFC3326ordraft-jesske-dispatch-reason-in-responses approach X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:46:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC21F.3AEB2E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roland, =20 I agree to the point that Update of RFC 3326 is implemented by lot of vendors as there is no proper mapping between Q.850 and SIP response. I noticed that Cisco PSTN (TDM) GW implemented reason header in SIP response long back as there was no proper reverse mapping exists for Q.850 from SIP response. The solution works well for PSTN---SIP----PSTN topology. In case your intention of updating RFC 3326 is to create "Best current practice" or "Historic" document, then I'm complete with you as the legacy PSTN GW to SIP interop issue may be solved smoothly by your draft reference.=20 =20 My concern (issues noticed) with UPDATE of RFC 3326 as Proposed Standard are as follows: =20 1) In case of new implementation which acts as both B2BUA and PSTN GW(SIP UA--PSTN) has to handle two response code for SIP responses as standard mentions to handle two types response codes (Q.850 cause code, SIP response code). This could be avoided in case single response code method exist (which is update for RFC 3398). [Multiple type of response code handled may be implemented in few of the existing implementation as there is no solution exists] =20 2) The solution of passing Q.850 cause code *may* fail when B2BUAs are involved in the topology. In real deployment, most of the solutions will have multiple SIP (B2BUA) hops. So, the topology like PSTN Cloud----SIP--B2BUA---SIP---PSTN cloud will not pass across reason header as there is no means to enforce this policy of passing reason header through B2BUA. The point to be noted is that SIP response header normally passed across well in B2BUA with proper translation (like 503 to 500) because it is related to RFC 3261.=20 =20 As your work looks like interworking between IMS SIP entity and PSTN (NGN network to legacy), it may be preferred to have the proper SIP based solution which translates PSTN cause code at PSTN-IMS GW itself. Please let me know your opinion on the above concerns. Also in case you address the above concerns, Please let me know the approach. =20 Thanks Partha ________________________________ From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Monday, January 31, 2011 6:50 PM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); dispatch@ietf.org Subject: AW: [dispatch] Update fo RFC3326ordraft-jesske-dispatch-reason-in-responses approach Hi Partha, A UPDATE to RFC3326 will reflect that what is already implemented all over the world while a UPDATE to RFC 3398 will never succeed due to the fact that the Q.850 CV are very different to SIP Responses. =20 There are groups of Q.850 Causes that are mapped to the same SIP Response due to the fact that only one fit to such a Response. E.G Response 503 is very often used for a couple of Q.850 causes. But the CV itself causes within ISUP different reactions (e.G special Tones or Announcements). =20 And as the reactions showed there is enough support for a further progress to allow the Reason header (containing Q.850 Causes) within responses.=20 =20 Best Regards =20 Roland ________________________________ Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftrag von Parthasarathi R (partr) Gesendet: Freitag, 28. Januar 2011 17:51 An: Paul Kyzivat (pkyzivat); dispatch@ietf.org; Jesske, Roland Betreff: Re: [dispatch] Update fo RFC3326 ordraft-jesske-dispatch-reason-in-responses approach Hi Roland, =20 Including Roland in this mail thread... =20 For your requirement, Update of RFC 3398 may solve the issue but update of RFC 3326 is a workaround. =20 Please correct me in case I'm missing something. =20 Thanks Partha ________________________________ From: dispatch-bounces@ietf.org on behalf of Parthasarathi R (partr) Sent: Thu 1/27/2011 10:36 PM To: Paul Kyzivat (pkyzivat); dispatch@ietf.org Subject: Re: [dispatch] Update fo RFC3326 ordraft-jesske-dispatch-reason-in-responses approach =09 =09 =09 Hi Roland, =20 I look into draft-jesske-dispatch-req-reason-in-responses-02 requirement. By reading your requirement document, it looks like that RFC 3398 does not distinguish each of the Q.850 to SIP responses. It leads to wrong response code in PSTN--SIP--PSTN topology. In case the proper mapping exist between Q.850 to SIP response, the problem *may* be solved. Pls correct me in case I misunderstand your requirement document. =20 I agree that Q.850 cause code in SIP response solves the problem for PSTN--SIP--PSTN network but ISTM protocol hack as there are two response codes exist in the same response and the two response codes are mutually exclusive in one occasion and different in other occasion. =20 Eg: 1) In single response msg, same response in two form=20 =20 503 SIP msg response with 41 as Q.850 cause code =20 2) In single response msg, Different responses=20 =20 503 SIP msg response with 34 as Q.850 cause code =20 This could be avoided in case the proper mapping exist. Please let me know your opinion here. =20 Thanks Partha ________________________________ From: dispatch-bounces@ietf.org on behalf of Paul Kyzivat (pkyzivat) Sent: Thu 1/27/2011 10:33 PM To: dispatch@ietf.org Subject: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach =09 =09 I can live with either way. =09 Thanks, Paul =09 On 1/27/2011 11:00 AM, R.Jesske@telekom.de wrote: > > Dear all, > a couple of days we discussed how to proceed with the reason in responses. > > As I see we have enough support for going ahead. But which approach should we take. (Mary asked this question also on Monday) > > 1. write an UPDATE to RFC 3326 > 2. progress draft-jesske-dispatch-reason-in-responses > > Currently I have seen the following opinions: > > For solution 1. +1 Paul > For solution 2. + Laura > 1 or 2 don't mind +1 John > > As long as the draft is already existing I would have my preference to go for 1. > But if needed I can also create an UPDATE to RFC3326. > > So please indicate your solution you would like to see. > > Thank you and Best Regards > > Roland > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 ------_=_NextPart_001_01CBC21F.3AEB2E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Update fo RFC3326 or = draft-jesske-dispatch-reason-in-responses approach
Hi Roland,
 
I agree to the point that Update of RFC 3326 is = implemented by=20 lot of vendors as there is no proper mapping between Q.850 and SIP=20 response.  I noticed that Cisco PSTN (TDM) = GW implemented=20 reason header in SIP response long back as there was no proper = reverse=20 mapping exists for Q.850 from SIP response. The solution works well for=20 PSTN---SIP----PSTN topology. In case your = intention of updating RFC=20 3326 is to create "Best current practice" or "Historic" = document,=20 then I'm complete with you as the legacy PSTN GW to SIP interop = issue may=20 be solved smoothly by your draft reference.
 
My concern (issues = noticed) with UPDATE of RFC=20 3326 as Proposed Standard are as follows:
 
1) In case of new=20 implementation which acts as both B2BUA and PSTN GW(SIP UA--PSTN) has to = handle=20 two response code for SIP responses as standard mentions = to handle two=20 types response codes (Q.850 cause code, SIP response code). This could = be=20 avoided in case single response code method exist (which is update for = RFC=20 3398). [Multiple type of response code handled may be = implemented in=20 few of the existing implementation as there is no solution=20 exists]
 
2) The solution of passing Q.850 cause = code *may* fail=20 when B2BUAs are involved in the topology. In real deployment, most of = the=20 solutions will have multiple SIP (B2BUA) hops. So, the topology like = PSTN=20 Cloud----SIP--B2BUA---SIP---PSTN cloud will not pass across reason = header as=20 there is no means to enforce this policy of passing reason header = through=20 B2BUA.  The point to be noted is that SIP response header = normally=20 passed across well in B2BUA with proper translation (like 503=20 to 500) because it is related to RFC 3261. =
 
As your work looks like interworking between = IMS SIP=20 entity and PSTN (NGN network to legacy), it may be preferred to have the = proper=20 SIP based solution which translates PSTN cause code at PSTN-IMS GW = itself.=20 Please let me know your opinion on the above concerns. = Also in=20 case you address the above concerns, Please let me know the=20 approach.
 
Thanks
Partha

From: R.Jesske@telekom.de=20 [mailto:R.Jesske@telekom.de]
Sent: Monday, January 31, 2011 = 6:50=20 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);=20 dispatch@ietf.org
Subject: AW: [dispatch] Update fo=20 RFC3326ordraft-jesske-dispatch-reason-in-responses = approach

Hi Partha,
A UPDATE to RFC3326 will reflect that what is = already=20 implemented all over the world while a UPDATE to RFC 3398 will never = succeed due=20 to the fact that the Q.850 CV are very different to SIP=20 Responses.
 
There are groups of Q.850 Causes that are mapped = to the same=20 SIP Response due to the fact that only one fit to such a Response. E.G = Response=20 503 is very often used for a couple of Q.850 causes. But the CV itself = causes=20 within ISUP different reactions (e.G special Tones or=20 Announcements).
 
And as the reactions showed there is enough = support for a=20 further progress to allow the Reason header (containing Q.850 Causes) = within=20 responses. 
 
Best Regards
 
Roland
Von:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von=20 Parthasarathi R (partr)
Gesendet: Freitag, 28. Januar 2011 = 17:51
An: Paul Kyzivat (pkyzivat); dispatch@ietf.org; Jesske,=20 Roland
Betreff: Re: [dispatch] Update fo RFC3326=20 ordraft-jesske-dispatch-reason-in-responses = approach

Hi = Roland,
 
Including = Roland in this=20 mail thread...
 
For your requirement, = Update of RFC=20 3398 may solve the issue but update of RFC 3326 is a=20 workaround.
 
Please correct me in = case I'm=20 missing something.
 
Thanks
Partha

From: dispatch-bounces@ietf.org on = behalf of=20 Parthasarathi R (partr)
Sent: Thu 1/27/2011 10:36 = PM
To:=20 Paul Kyzivat (pkyzivat); dispatch@ietf.org
Subject: Re: = [dispatch]=20 Update fo RFC3326 ordraft-jesske-dispatch-reason-in-responses=20 approach

Hi Roland,
 
I look=20 into draft-jesske-dispatch-req-reason-in-responses-02=20 requirement. By reading your requirement document, it looks=20 like that RFC 3398 does not distinguish each of = the Q.850=20 to SIP responses. It leads to wrong response code in PSTN--SIP--PSTN = topology.=20 In case the proper mapping exist between Q.850 to SIP response, the = problem=20 *may* be solved. Pls correct me in case I misunderstand your = requirement=20 document.
 
I agree that Q.850 cause = code in SIP=20 response solves the problem for PSTN--SIP--PSTN network but ISTM = protocol hack=20 as there are two response codes exist in the same response and the two=20 response codes are mutually exclusive in one occasion and different in other = occasion.
 
Eg:  1) In single = response msg, same=20 response in two form
 
   503 SIP msg response with 41 as Q.850 cause code
 
2) In single response msg, = Different=20 responses
 
   503 SIP msg response with 34 as Q.850 cause = code
 
This could be avoided in = case the proper=20 mapping exist. Please let me know your opinion here.
 
Thanks
Partha

From: dispatch-bounces@ietf.org on = behalf of=20 Paul Kyzivat (pkyzivat)
Sent: Thu 1/27/2011 10:33 = PM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] Update fo RFC3326 = or=20 draft-jesske-dispatch-reason-in-responses = approach

I can live with either=20 way.

       =20 Thanks,
        Paul

On = 1/27/2011=20 11:00 AM, R.Jesske@telekom.de wrote:
>
> Dear all,
> = a=20 couple of days we discussed how to proceed with the reason in=20 responses.
>
> As I see we have enough support for going = ahead.=20 But which approach should we take. (Mary asked this question also on=20 Monday)
>
> 1. write an UPDATE to RFC 3326
> 2. = progress=20 draft-jesske-dispatch-reason-in-responses
>
> Currently I = have=20 seen the following opinions:
>
> For solution 1. +1 = Paul
>=20 For solution 2. + Laura
> 1 or 2 don't mind +1 = John
>
> As=20 long as the draft is already existing I would have my preference to go = for=20 1.
> But if needed I can also create an UPDATE to=20 RFC3326.
>
> So please indicate your solution you would = like to=20 see.
>
> Thank you and Best Regards
>
> = Roland
>=20 _______________________________________________
> dispatch = mailing=20 list
> dispatch@ietf.org
> https://www.ietf.= org/mailman/listinfo/dispatch
>
____________________________= ___________________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

= ------_=_NextPart_001_01CBC21F.3AEB2E80-- From hakim.ietf@gmail.com Tue Feb 1 10:03:29 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3FA73A6E80 for ; Tue, 1 Feb 2011 10:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g86NCEgrhD9d for ; Tue, 1 Feb 2011 10:03:28 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A4AB63A6E6B for ; Tue, 1 Feb 2011 10:03:27 -0800 (PST) Received: by qyj19 with SMTP id 19so7320042qyj.10 for ; Tue, 01 Feb 2011 10:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=VEva9gVHfZH4qs4pvYOUo1+NfhKIUtF92KWpom/btgo=; b=LknSTaNInYazu4vrpsAZWb+zCnQGv5LG9d5K6OkKWAyb+6nXIsX+ydl+d70BrBEY/Q rpwIF86khh51/SGvJMzz0OsKp+0b9naWkR2+zhGiD6xrKu6Awp/D67aIdnbWTxUcLyNG pnKOe+epqVV/93KYEkql5qjUHLvcY3m9tohgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=KDNHzlhvHmvV8RLowcIoY6R+9AsxTeMBZPccFS1/kCLvmbU1qA6mXFUmfj8nOlZ52Q P37CK8Lf6/XcypudB0MtLG6eJT45nyh1eLUdf6XDZNuxK9EGMUFKe3jyKgf5waMIZEFi t610cwGZrDhyITbKvfy7g0n8olf7Pnvvn8NAY= MIME-Version: 1.0 Received: by 10.229.81.65 with SMTP id w1mr7409398qck.9.1296583604841; Tue, 01 Feb 2011 10:06:44 -0800 (PST) Received: by 10.229.38.206 with HTTP; Tue, 1 Feb 2011 10:06:44 -0800 (PST) Date: Tue, 1 Feb 2011 12:06:44 -0600 Message-ID: From: hakim mehmood To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=00163646d410302e78049b3c6575 Subject: Re: [dispatch] VIPR Charter V5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:12:15 -0000 --00163646d410302e78049b3c6575 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, 1) Yes, I am interested. 2) I can review work. 3) Yes, this is ready to be chartered. Hakim From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Richard Shockey Sent: Saturday, January 29, 2011 8:03 PM To: 'DISPATCH list' Subject: Re: [dispatch] VIPR Charter V5 A. No I=92m not interested. I have very little expectation that this w= ork will deploy beyond certain enterprise applications. B. I have no intentions of reviewing this work C. But Yes this work is ready to be chartered. Whatever, have at it, b= e my guest, have a nice 3 years or so. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Peter Musgrave Sent: Saturday, January 29, 2011 2:36 AM To: Mary Barnes Cc: DISPATCH list Subject: Re: [dispatch] VIPR Charter V5 Hi, 1) Yes, I am interested. 2) I can review work. 3) Yes, this is ready to be chartered. Peter Musgrave On 2011-01-28, at 3:12 PM, Mary Barnes wrote: Hi folks, Marc posted the following updated charter a couple weeks back addressing many of the concerns raised in this thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg03090.html If folks could please respond if they believe this addresses the concerns they raised, that would be very helpful. Also, we need answers to the following in order to consider whether it should be progressed for chartering: 1) Are you interested in this work? 2) Are you willing to contribute to the work (reviewing, contributing text= , editing if needed, etc.) ? 3) Do you believe this work is ready to be chartered? Thanks, Mary. DISPATCH WG co-chair On Sun, Jan 16, 2011 at 9:37 AM, Marc Petit-Huguenin wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please find the V5 of the VIPR charter proposal below. Please send any concern to this mailing-list, so we can discuss them and improve the charter. Thanks. - --------------------------------------------------------------------------- VIPR Charter Proposal (Version 5) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. The goal of this working group is to enable inter-domain communications over the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will also develop mechanisms to detect in a timely manner that a given domain is not longer responsible for a phone number. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The WG will produce the following deliverables: 1) A document describing the requirements, problem statement and architectural approach to support SIP inter-domain communications. 2) A document describing the use of the p2psip protocol (RELOAD) as applied to this problem space. 3) A document defining a scheme for validating the phone numbers using publicly available open interfaces to the PSTN. 4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls. 5) A document describing a mechanism to mitigate SPAM issues. The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0zELIACgkQ9RoMZyVa61c8JQCZAYr/HaVyUZ2nV+bO+F4CWjOH mD4AnjQatv9wxZfVJ4zwl0tT4d4SqEcj =3DGueo -----END PGP SIGNATURE----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --00163646d410302e78049b3c6575 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,
=A0
1) Yes, I am interested.
2) I can review work.
3) = Yes, this is ready to be chartered.
=A0
Hakim
=A0
=A0
From: = dispatch-bou= nces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Saturday, January 29, 2011 8:03 PM
To: 'DISPATCH list'
= Subject: Re: [dispatch] VIPR Charter V5
=A0
A.=A0=A0=A0=A0=A0 No I=92= m not interested. I have very little expectation that this work will deploy= beyond certain enterprise applications.
B.=A0=A0=A0=A0=A0 I have no intentions of reviewing this work
C.=A0=A0= =A0=A0=A0 But Yes this work is ready to be chartered. Whatever, have at it,= be my guest, have a nice 3 years or so.
=A0
From: dispatch-bounces@ietf.org= [mailto:dis= patch-bounces@ietf.org] On Behalf Of Peter Musgrave
Sent: Saturday, January 29, 2011 2:36 AM
To: Mary Barnes
Cc: DISPATCH= list
Subject: Re: [dispatch] VIPR Charter V5
=A0
Hi,
=A0
1= ) Yes, I am interested.
2) I can review work.
3) Yes, this is ready = to be chartered.
=A0
Peter Musgrave
=A0
On 2011-01-28, at 3:12 PM, Mary Barnes wrot= e:
=A0
Hi folks,
=A0
Marc posted the following updated charter = a couple weeks back addressing many of the concerns raised in this thread:<= br>http://www.ietf.org/mail-archive/web/dispatch/cur= rent/msg03090.html
=A0
If folks could please respond if they believe this addresses the con= cerns they raised, that would be very helpful.
=A0
Also, we need ans= wers to the following in order to consider whether it should be progressed = for chartering:
1)=A0 Are you interested in this work?=A0
2)=A0 Are you willing to cont= ribute to the work (reviewing, contributing text, editing if needed, etc.) = ?
3)=A0 Do you believe this work is ready to be chartered?

Thanks,
Mary.
DISPATCH WG co-chair
=A0
On Sun, Jan 16, 2011 = at 9:37 AM, Marc Petit-Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MES= SAGE-----
Hash: SHA1

Please find the V5 of the VIPR charter proposal below.

Please send any concern to this mailing-list, so we can discuss them and= improve
the charter.

Thanks.

- ----------------------------------------------------------------------= -----

VIPR Charter Proposal (Version 5)

WG Name:=A0 Verification Involving PSTN Reachability (VIPR)

There are two globally deployed address spaces for communications usedby more than a billion people daily - phone numbers and DNS rooted
add= ress such as web servers and email addresses.=A0 The inter-domain
signal= ing design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
i= dentifying users, thus DNS lookups are not sufficient.=A0 The goal of this<= br>working group is to enable inter-domain communications over the Internet= ,
using protocols such as SIP, while still allowing people to use phone
nu= mbers to identify the person with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
dom= ains that claim to be responsible for a given phone number
to mitigate t= he involvement of centralized entities to avoid some of
the issues encou= ntered by past attempts to support SIP inter-domain
communications.=A0 Validation protocols will be developed to ensure a
re= asonable likelihood that a given domain actually is responsible for
the = phone number.=A0 In this context, "responsible" means an
admin= istrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed.=A0 Once the domain
res= ponsible for the phone number is found, existing protocols, such
as SIP,= can be used for inter-domain communications.

Some validation protocols may be based on knowledge gathered around aPSTN call; for example, the ability to prove a call was received over
t= he PSTN based on start and stop times.=A0 Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a
d= omain received a particular PSTN phone call, may also be considered by
t= he working group.=A0 This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be
performe= d by any domain wishing to participate.=A0 The WG will select and
standa= rdize at least one validation scheme.

The validation mechanism requires a domain to gather and maintain
inf= ormation related to PSTN calls.=A0 This information is used by call
agen= ts such as phones, SBCs and IP PBXs to route calls.=A0 The WG will
also = develop mechanisms to detect in a timely manner that a given domain
is not longer responsible for a phone number.=A0 The WG will define a
cl= ient-server protocol between these call agents and the entity within a
d= omain that maintains the information.

To help mitigate SPAM issues when using SIP between domains, the WG will=
define a mechanism to enable one domain to check that incoming SIP
m= essages are coming from a validated phone number.=A0 A phone number is
considered validated if it is coming from a domain to which the calling
= domain had previously successfully placed a PSTN call.=A0 The working
gr= oup will define new SIP headers and option tags, as necessary, to
enable= this.

The essential characteristic of VIPR is establishing authentication byPSTN reachability when it is not possible to use a direct reference toENUM databases or other direct assertions of PSTN number
ownership.=A0 = Elements such as public ENUM easily coexist with VIPR but no
direct interaction with ENUM will be required.=A0 The solution set defined<= br>by this WG will be incrementally deployable using only existing
inter= faces to the PSTN.=A0 No changes will be required to existing PSTN
capab= ilities, no new database access is needed nor is any new support
from PSTN service providers required.

The WG will produce the following deliverables:

1) A document describing the requirements, problem statement and
arch= itectural approach to support SIP inter-domain communications.
2) A docu= ment describing the use of the p2psip protocol (RELOAD) as
applied to th= is problem space.
3) A document defining a scheme for validating the phone numbers using
p= ublicly available open interfaces to the PSTN.
4) A document defining cl= ient-server protocol between call agents and the
entity within a domain = that gathers and maintains information related to
PSTN calls.
5) A document describing a mechanism to mitigate SPAM issues= .

The working group will carefully coordinate with the security area, O&am= p;M
area, as well as the appropriate RAI WGs such as sipcore and p2psip.=

- --
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professi= onal email: petithug@= acm.org
Blog: ht= tp://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
V= ersion: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0zELIACgkQ9RoMZyVa61c8JQCZAYr/HaVyUZ2nV+bO+F4CWjOH
mD4A= njQatv9wxZfVJ4zwl0tT4d4SqEcj
=3DGueo
-----END PGP SIGNATURE-----
_= ______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list=
dispatch@ietf.or= g
https://www.ietf.org/mailman/listinfo/dispatch

--00163646d410302e78049b3c6575-- From jon.peterson@neustar.biz Tue Feb 1 10:20:21 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BFD3A6F7E for ; Tue, 1 Feb 2011 10:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.614 X-Spam-Level: X-Spam-Status: No, score=-104.614 tagged_above=-999 required=5 tests=[AWL=1.984, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiGAc6PPFygM for ; Tue, 1 Feb 2011 10:20:19 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id AC4C13A6F79 for ; Tue, 1 Feb 2011 10:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1296584612; x=1611928734; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=zqPM4qyocyxchV3ET0rRS2rlgj84TPmNQTGhbZbD5uw=; b=TrgWQ0yPSgsy/U00b2bAaWfEcmz0ilU3m+/+WlJ3RCTnPpMvqmQQzXYCx0jUZ1 ncinEqtsttvIPiBoWnx9h5DA== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.19330960; Tue, 01 Feb 2011 13:23:31 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 1 Feb 2011 13:23:31 -0500 From: "Peterson, Jon" To: Mary Barnes Date: Tue, 1 Feb 2011 13:23:27 -0500 Thread-Topic: [dispatch] VIPR Charter V5 Thread-Index: AcvCPSCkrEXAWsVJTni6enZlU/8O0w== Message-ID: References: <4D3310B4.6020604@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: OvVMqu1VB1Ybi22qnkerUg== Content-Type: multipart/alternative; boundary="_000_BD5F00048B714100BEC241F9F19EEC4Aneustarbiz_" MIME-Version: 1.0 Cc: DISPATCH list Subject: Re: [dispatch] VIPR Charter V5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:20:21 -0000 --_000_BD5F00048B714100BEC241F9F19EEC4Aneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1) Yes. 2) Yes. 3) Yes. Jon Peterson NeuStar, Inc. On Jan 28, 2011, at 12:12 PM, Mary Barnes wrote: Hi folks, Marc posted the following updated charter a couple weeks back addressing ma= ny of the concerns raised in this thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg03090.html If folks could please respond if they believe this addresses the concerns t= hey raised, that would be very helpful. Also, we need answers to the following in order to consider whether it shou= ld be progressed for chartering: 1) Are you interested in this work? 2) Are you willing to contribute to the work (reviewing, contributing text= , editing if needed, etc.) ? 3) Do you believe this work is ready to be chartered? Thanks, Mary. DISPATCH WG co-chair On Sun, Jan 16, 2011 at 9:37 AM, Marc Petit-Huguenin > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please find the V5 of the VIPR charter proposal below. Please send any concern to this mailing-list, so we can discuss them and im= prove the charter. Thanks. - -------------------------------------------------------------------------= -- VIPR Charter Proposal (Version 5) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. The goal of this working group is to enable inter-domain communications over the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will also develop mechanisms to detect in a timely manner that a given domain is not longer responsible for a phone number. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The WG will produce the following deliverables: 1) A document describing the requirements, problem statement and architectural approach to support SIP inter-domain communications. 2) A document describing the use of the p2psip protocol (RELOAD) as applied to this problem space. 3) A document defining a scheme for validating the phone numbers using publicly available open interfaces to the PSTN. 4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls. 5) A document describing a mechanism to mitigate SPAM issues. The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0zELIACgkQ9RoMZyVa61c8JQCZAYr/HaVyUZ2nV+bO+F4CWjOH mD4AnjQatv9wxZfVJ4zwl0tT4d4SqEcj =3DGueo -----END PGP SIGNATURE----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_BD5F00048B714100BEC241F9F19EEC4Aneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1) Yes= .
2) Yes.
3) Yes.

Jon Peterson=
NeuStar, Inc.

On Jan 28, 2011, at 12:12 PM, M= ary Barnes wrote:

Hi folks,
 
Marc posted the following updated charter a couple weeks bac= k addressing many of the concerns raised in this thread:
 
If folks could please respond if they believe this addresses the conce= rns they raised, that would be very helpful.
 
Also, we need answers to the following in order to consider whether it= should be progressed for chartering:
1)  Are you interested in this work?  
2)  Are you willing to contribute to the work (reviewin= g, contributing text, editing if needed, etc.) ?
3)  Do you believe this work is ready to be chartered?

Thanks,
Mary.
DISPATCH WG co-chair
 
On Sun, Jan 16, 2011 at 9:37 AM, Marc Petit-Hugu= enin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE---= --
Hash: SHA1

Please find the V5 of the VIPR charter proposal bel= ow.

Please send any concern to this mailing-list, so we can discuss them an= d improve
the charter.

Thanks.

- -------------------------= --------------------------------------------------

VIPR Charter Prop= osal (Version 5)

WG Name:  Verification Involving PSTN Reachability (VIPR)

T= here are two globally deployed address spaces for communications used
by= more than a billion people daily - phone numbers and DNS rooted
address= such as web servers and email addresses.  The inter-domain
signaling design of SIP is primarily designed for email style addresses
= yet a large percentage of SIP deployments mostly use phone numbers for
i= dentifying users, thus DNS lookups are not sufficient.  The goal of th= is
working group is to enable inter-domain communications over the Internet,using protocols such as SIP, while still allowing people to use phone
= numbers to identify the person with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domain= s that claim to be responsible for a given phone number
to mitigate the = involvement of centralized entities to avoid some of
the issues encounte= red by past attempts to support SIP inter-domain
communications.  Validation protocols will be developed to ensure areasonable likelihood that a given domain actually is responsible for
t= he phone number.  In this context, "responsible" means an
administr= ative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed.  Once the domain
= responsible for the phone number is found, existing protocols, such
as S= IP, can be used for inter-domain communications.

Some validation pro= tocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received over
th= e PSTN based on start and stop times.  Other validation schemes, such<= br>as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by
= the working group.  This validation will be accomplished using publicl= y
available open interfaces to the PSTN, so the validation can be
per= formed by any domain wishing to participate.  The WG will select and standardize at least one validation scheme.

The validation mechanism= requires a domain to gather and maintain
information related to PSTN ca= lls.  This information is used by call
agents such as phones, SBCs = and IP PBXs to route calls.  The WG will
also develop mechanisms to detect in a timely manner that a given domainis not longer responsible for a phone number.  The WG will define aclient-server protocol between these call agents and the entity within a<= br> domain that maintains the information.

To help mitigate SPAM issues = when using SIP between domains, the WG will
define a mechanism to enable= one domain to check that incoming SIP
messages are coming from a valida= ted phone number.  A phone number is
considered validated if it is coming from a domain to which the calling
= domain had previously successfully placed a PSTN call.  The workinggroup will define new SIP headers and option tags, as necessary, to
ena= ble this.

The essential characteristic of VIPR is establishing authentication by<= br>PSTN reachability when it is not possible to use a direct reference toENUM databases or other direct assertions of PSTN number
ownership. &n= bsp;Elements such as public ENUM easily coexist with VIPR but no
direct interaction with ENUM will be required.  The solution set defin= ed
by this WG will be incrementally deployable using only existing
in= terfaces to the PSTN.  No changes will be required to existing PSTNcapabilities, no new database access is needed nor is any new support
from PSTN service providers required.

The WG will produce the follow= ing deliverables:

1) A document describing the requirements, problem= statement and
architectural approach to support SIP inter-domain commun= ications.
2) A document describing the use of the p2psip protocol (RELOAD) as
appl= ied to this problem space.
3) A document defining a scheme for validatin= g the phone numbers using
publicly available open interfaces to the PSTN= .
4) A document defining client-server protocol between call agents and theentity within a domain that gathers and maintains information related to<= br>PSTN calls.
5) A document describing a mechanism to mitigate SPAM iss= ues.

The working group will carefully coordinate with the security area, O&a= mp;M
area, as well as the appropriate RAI WGs such as sipcore and p2psip= .

- --
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: p= etithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN = PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0zELIACgkQ9RoMZyVa6= 1c8JQCZAYr/HaVyUZ2nV+bO+F4CWjOH
mD4AnjQatv9wxZfVJ4zwl0tT4d4SqEcj
=3DG= ueo
-----END PGP SIGNATURE-----
_____________________________________= __________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch

<ATT00001..txt>

= --_000_BD5F00048B714100BEC241F9F19EEC4Aneustarbiz_-- From maltarai@cisco.com Tue Feb 1 10:58:28 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCCB3A6EBF for ; Tue, 1 Feb 2011 10:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrdznuSdaKZB for ; Tue, 1 Feb 2011 10:58:26 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4FB453A6DF4 for ; Tue, 1 Feb 2011 10:58:26 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADvnR02tJV2Z/2dsb2JhbACCRZophzRnc6FtmySCe4JYBIUTcYYfg0iDEA Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 01 Feb 2011 19:01:43 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p11J1gTK021616; Tue, 1 Feb 2011 19:01:42 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 13:01:42 -0600 Received: from 10.116.83.37 ([10.116.83.37]) by XMB-RCD-113.cisco.com ([72.163.62.155]) via Exchange Front-End Server email.cisco.com ([72.163.62.205]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Feb 2011 19:01:42 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 01 Feb 2011 14:01:38 -0500 From: maltarai To: Mary Barnes , DISPATCH list Message-ID: Thread-Topic: [dispatch] VIPR Charter V5 Thread-Index: AcvCQnQAbxSU656qiE+A2BMBHhc8SQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379413699_112272622" X-OriginalArrivalTime: 01 Feb 2011 19:01:42.0658 (UTC) FILETIME=[76C71620:01CBC242] Subject: Re: [dispatch] VIPR Charter V5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:58:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379413699_112272622 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 1)=A0 Are=A0you interested in this work?=A0=A0Yes 2)=A0=A0Are=A0you willing to contribute to the work (reviewing, contributing text= , editing if needed, etc.) ? Yes 3)=A0 Do you=A0believe this work is ready to be chartered? Absolutely. Thanks, Mo On 1/28/11 3:12 PM, "Mary Barnes" wrote: > Hi folks, > =A0 > Marc posted=A0the following=A0updated charter a couple weeks back addressing = many > of the concerns raised in this thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg03090.html > =A0 > If folks could please respond if they believe this addresses the concerns= they > raised, that would be very helpful. > =A0 > Also, we need answers to the following in order to consider whether it sh= ould > be progressed for chartering: > 1)=A0 Are=A0you interested in this work?=A0=A0 > 2)=A0=A0Are=A0you willing to contribute to the work (reviewing, contributing te= xt, > editing if needed, etc.) ? > 3)=A0 Do you=A0believe this work is ready to be chartered? >=20 > Thanks, > Mary. > DISPATCH WG co-chair > =A0 > On Sun, Jan 16, 2011 at 9:37 AM, Marc Petit-Huguenin w= rote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Please find the V5 of the VIPR charter proposal below. >>=20 >> Please send any concern to this mailing-list, so we can discuss them and >> improve >> the charter. >>=20 >> Thanks. >>=20 >> - ----------------------------------------------------------------------= ----- >>=20 >> VIPR Charter Proposal (Version 5) >>=20 >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) >>=20 >> There are two globally deployed address spaces for communications used >> by more than a billion people daily - phone numbers and DNS rooted >> address such as web servers and email addresses. =A0The inter-domain >> signaling design of SIP is primarily designed for email style addresses >> yet a large percentage of SIP deployments mostly use phone numbers for >> identifying users, thus DNS lookups are not sufficient. =A0The goal of thi= s >> working group is to enable inter-domain communications over the Internet= , >> using protocols such as SIP, while still allowing people to use phone >> numbers to identify the person with whom they wish to communicate. >>=20 >> The VIPR WG will develop a peer to peer based approach to finding >> domains that claim to be responsible for a given phone number >> to mitigate the involvement of centralized entities to avoid some of >> the issues encountered by past attempts to support SIP inter-domain >> communications. =A0Validation protocols will be developed to ensure a >> reasonable likelihood that a given domain actually is responsible for >> the phone number. =A0In this context, "responsible" means an >> administrative domain, which is at least one of the domains, to which >> a PSTN call to this phone number would be routed. =A0Once the domain >> responsible for the phone number is found, existing protocols, such >> as SIP, can be used for inter-domain communications. >>=20 >> Some validation protocols may be based on knowledge gathered around a >> PSTN call; for example, the ability to prove a call was received over >> the PSTN based on start and stop times. =A0Other validation schemes, such >> as examining fingerprints or watermarking of PSTN media to show that a >> domain received a particular PSTN phone call, may also be considered by >> the working group. =A0This validation will be accomplished using publicly >> available open interfaces to the PSTN, so the validation can be >> performed by any domain wishing to participate. =A0The WG will select and >> standardize at least one validation scheme. >>=20 >> The validation mechanism requires a domain to gather and maintain >> information related to PSTN calls. =A0This information is used by call >> agents such as phones, SBCs and IP PBXs to route calls. =A0The WG will >> also develop mechanisms to detect in a timely manner that a given domain >> is not longer responsible for a phone number. =A0The WG will define a >> client-server protocol between these call agents and the entity within a >> domain that maintains the information. >>=20 >> To help mitigate SPAM issues when using SIP between domains, the WG will >> define a mechanism to enable one domain to check that incoming SIP >> messages are coming from a validated phone number. =A0A phone number is >> considered validated if it is coming from a domain to which the calling >> domain had previously successfully placed a PSTN call. =A0The working >> group will define new SIP headers and option tags, as necessary, to >> enable this. >>=20 >> The essential characteristic of VIPR is establishing authentication by >> PSTN reachability when it is not possible to use a direct reference to >> ENUM databases or other direct assertions of PSTN number >> ownership. =A0Elements such as public ENUM easily coexist with VIPR but no >> direct interaction with ENUM will be required. =A0The solution set defined >> by this WG will be incrementally deployable using only existing >> interfaces to the PSTN. =A0No changes will be required to existing PSTN >> capabilities, no new database access is needed nor is any new support >> from PSTN service providers required. >>=20 >> The WG will produce the following deliverables: >>=20 >> 1) A document describing the requirements, problem statement and >> architectural approach to support SIP inter-domain communications. >> 2) A document describing the use of the p2psip protocol (RELOAD) as >> applied to this problem space. >> 3) A document defining a scheme for validating the phone numbers using >> publicly available open interfaces to the PSTN. >> 4) A document defining client-server protocol between call agents and th= e >> entity within a domain that gathers and maintains information related to >> PSTN calls. >> 5) A document describing a mechanism to mitigate SPAM issues. >>=20 >> The working group will carefully coordinate with the security area, O&M >> area, as well as the appropriate RAI WGs such as sipcore and p2psip. >>=20 >> - -- >> Marc Petit-Huguenin >> Personal email: marc@petit-huguenin.org >> Professional email: petithug@acm.org >> Blog: http://blog.marc.petit-huguenin.org >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >>=20 >> iEYEARECAAYFAk0zELIACgkQ9RoMZyVa61c8JQCZAYr/HaVyUZ2nV+bO+F4CWjOH >> mD4AnjQatv9wxZfVJ4zwl0tT4d4SqEcj >> =3DGueo >> -----END PGP SIGNATURE----- >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --B_3379413699_112272622 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] VIPR Charter V5 1)=A0 Are=A0you interested in this work?=A0=A0Yes
2)=A0=A0Are=A0you willing to contribute to the work (reviewing, contributing text= , editing if needed, etc.) ? Yes
3)=A0 Do you=A0believe this work is ready to be chartered? Absolutely.

Thanks,

Mo



On 1/28/11 3:12 PM, "Mary Barnes" <mary.ietf.barnes@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi folks,
=A0
Marc posted=A0the following=A0updated charter a couple weeks back addressing ma= ny of the concerns raised in this thread:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03090.html =A0
If folks could please respond if they believe this addresses the concerns t= hey raised, that would be very helpful.
=A0
Also, we need answers to the following in order to consider whether it shou= ld be progressed for chartering:
1)=A0 Are=A0you interested in this work?=A0=A0
2)=A0=A0Are=A0you willing to contribute to the work (reviewing, contributing text= , editing if needed, etc.) ?
3)=A0 Do you=A0believe this work is ready to be chartered?

Thanks,
Mary.
DISPATCH WG co-chair
=A0
On Sun, Jan 16, 2011 at 9:37 AM, Marc Petit-Huguenin <petithug@acm.org> wrote:
<= SPAN STYLE=3D'font-size:11pt'>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please find the V5 of the VIPR charter proposal below.

Please send any concern to this mailing-list, so we can discuss them and im= prove
the charter.

Thanks.

- -------------------------------------------------------------------------= --

VIPR Charter Proposal (Version 5)

WG Name: =A0Verification Involving PSTN Reachability (VIPR)

There are two globally deployed address spaces for communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. =A0The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users, thus DNS lookups are not sufficient. =A0The goal of this working group is to enable inter-domain communications over the Internet, using protocols such as SIP, while still allowing people to use phone
numbers to identify the person with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. =A0Validation protocols will be developed to ensure a
reasonable likelihood that a given domain actually is responsible for
the phone number. =A0In this context, "responsible" means an
administrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed. =A0Once the domain
responsible for the phone number is found, existing protocols, such
as SIP, can be used for inter-domain communications.

Some validation protocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received over
the PSTN based on start and stop times. =A0Other validation schemes, such
as examining fingerprints or watermarking of PSTN media to show that a
domain received a particular PSTN phone call, may also be considered by
the working group. =A0This validation will be accomplished using publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate. =A0The WG will select and
standardize at least one validation scheme.

The validation mechanism requires a domain to gather and maintain
information related to PSTN calls. =A0This information is used by call
agents such as phones, SBCs and IP PBXs to route calls. =A0The WG will
also develop mechanisms to detect in a timely manner that a given domain is not longer responsible for a phone number. =A0The WG will define a
client-server protocol between these call agents and the entity within a domain that maintains the information.

To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP
messages are coming from a validated phone number. =A0A phone number is
considered validated if it is coming from a domain to which the calling
domain had previously successfully placed a PSTN call. =A0The working
group will define new SIP headers and option tags, as necessary, to
enable this.

The essential characteristic of VIPR is establishing authentication by
PSTN reachability when it is not possible to use a direct reference to
ENUM databases or other direct assertions of PSTN number
ownership. =A0Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. =A0The solution set defined by this WG will be incrementally deployable using only existing
interfaces to the PSTN. =A0No changes will be required to existing PSTN
capabilities, no new database access is needed nor is any new support
from PSTN service providers required.

The WG will produce the following deliverables:

1) A document describing the requirements, problem statement and
architectural approach to support SIP inter-domain communications.
2) A document describing the use of the p2psip protocol (RELOAD) as
applied to this problem space.
3) A document defining a scheme for validating the phone numbers using
publicly available open interfaces to the PSTN.
4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls.
5) A document describing a mechanism to mitigate SPAM issues.

The working group will carefully coordinate with the security area, O&M=
area, as well as the appropriate RAI WGs such as sipcore and p2psip.

- --
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-= huguenin.org <http://b= log.marc.petit-huguenin.org/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0zELIACgkQ9RoMZyVa61c8JQCZAYr/HaVyUZ2nV+bO+F4CWjOH
mD4AnjQatv9wxZfVJ4zwl0tT4d4SqEcj
=3DGueo
-----END PGP SIGNATURE-----
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
=

__________________________= _____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
--B_3379413699_112272622-- From pkyzivat@cisco.com Tue Feb 1 11:21:23 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8F03A6FE0 for ; Tue, 1 Feb 2011 11:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQLBKdD2BStb for ; Tue, 1 Feb 2011 11:21:22 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A88773A6F86 for ; Tue, 1 Feb 2011 11:21:13 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEHABftR01AZnwN/2dsb2JhbACWZo4jc6FxmyeFUwSFE4cQg0I Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Feb 2011 19:24:31 +0000 Received: from [10.86.251.91] (bxb-vpn3-859.cisco.com [10.86.251.91]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p11JOUlh019526 for ; Tue, 1 Feb 2011 19:24:31 GMT Message-ID: <4D485DEE.5060808@cisco.com> Date: Tue, 01 Feb 2011 14:24:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dispatch@ietf.org References: <4D3310B4.6020604@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] VIPR Charter V5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:21:23 -0000 1) yes 2) a bit 3) yes >> Also, we need answers to the following in order to consider whether it >> should be progressed for chartering: >> 1) Are you interested in this work? >> 2) Are you willing to contribute to the work (reviewing, contributing >> text, editing if needed, etc.) ? >> 3) Do you believe this work is ready to be chartered? From dworley@avaya.com Tue Feb 1 11:43:45 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080D63A6D07 for ; Tue, 1 Feb 2011 11:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn3JCKLrfMWy for ; Tue, 1 Feb 2011 11:43:44 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 3C0273A6C27 for ; Tue, 1 Feb 2011 11:43:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAATyR03GmAcF/2dsb2JhbAClCXOkIgKYfIVTBIUTim2Cew X-IronPort-AV: E=Sophos;i="4.60,411,1291611600"; d="scan'208";a="57120022" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 01 Feb 2011 14:47:01 -0500 X-IronPort-AV: E=Sophos;i="4.60,411,1291611600"; d="scan'208";a="577087207" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Feb 2011 14:47:01 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 1 Feb 2011 14:47:00 -0500 From: "Worley, Dale R (Dale)" To: DISPATCH list Date: Tue, 1 Feb 2011 14:46:09 -0500 Thread-Topic: [dispatch] VIPR Charter V5 Thread-Index: Acu/J8GJCmCnt9inQKyBgudO1uzSUwDIOq/R Message-ID: References: <4D3310B4.6020604@acm.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] VIPR Charter V5 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:43:45 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Ma= ry Barnes [mary.ietf.barnes@gmail.com] 1) Are you interested in this work? 2) Are you willing to contribute to the work (reviewing, contributing text= , editing if needed, etc.) ? 3) Do you believe this work is ready to be chartered? _______________________________________________ 1. Yes 2. Yes 3. Don't know (I haven't kept up on the charter discussion) Dale From paulej@packetizer.com Tue Feb 1 12:58:24 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EC43A6C7F for ; Tue, 1 Feb 2011 12:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZNmxyY3mONH for ; Tue, 1 Feb 2011 12:58:22 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id BFEB53A6C75 for ; Tue, 1 Feb 2011 12:58:22 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p11L1Xbi014079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Feb 2011 16:01:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1296594098; bh=J7EBkgFBxk1orkrXKvERndRULLHqqatSMTypnU9PY4I=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nBN6fPL2mtYzm523RJbwgTdRzMXcJxuk/5wdcrhTo3Jzx0yMqf7TeP3sccL+PWurr 00flPlf5xcwv/lF4oSfTfG7ZDlK63vcVAeKF38tu6qdlXbjvNoOjPZDs4VhBpLaAsL hWaWgWNZt/xNZ2ZGcA86YMzNikiRvaulg3JlkLJg= From: "Paul E. Jones" To: "'Parthasarathi R \(partr\)'" , References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <001901cbc1b8$91a90eb0$b4fb2c10$@packetizer.com> In-Reply-To: Date: Tue, 1 Feb 2011 16:01:17 -0500 Message-ID: <01f501cbc253$2f1cc5c0$8d565140$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA7Fy1vbvX3nVJZeZhtnW6LVnUIgG4H8jSANaP474DS90gJZNT+MDQ Content-Language: en-us Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:58:24 -0000 Partha, Usage in other protocols should be documented elsewhere. I intend to introduce the same Session-UUID in H.323 so that we do not lose the end-to-end identification when we cross protocol boundaries. For other protocols, I think we would need other documents. Paul > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Tuesday, February 01, 2011 12:29 AM > To: Paul E. Jones; dispatch@ietf.org > Subject: RE: [dispatch] draft-jones-ipmc-session-id-01 > > Paul, > > As multiple applications *may* use this Session-UUID, this draft has to > be tracked in generic fashion instead of going into specific application > or problem. SIPREC solution will be designed in a generic enough fashion > to handle different CS grouping (CSG) mechanism wherein Session-UUID > could be used as one of the CSG mechanism. > > IMO, This draft has to be tracked as separate WG or individual draft as > this draft claims for the usage of session-UUID in non-SIP protocols > like RSVP, RTCP. > > Thanks > Partha > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, February 01, 2011 8:05 AM > To: Parthasarathi R (partr); dispatch@ietf.org > Subject: RE: [dispatch] draft-jones-ipmc-session-id-01 > > Partha, > > Thanks for the feedback. The question is "where do we go from here?" I > have a number of applications for a unique end-to-end session ID. > SIPREC is certainly one where we can use it. I'd also like to use it > for tracing media flows, signaling exchanges, associating devices in a > conference, etc. > > Would this need a new WG unto its own? Could this be a part of the WG > proposed for looking at the "debugging" problem? Could we put this work > in SIPREC? > > Paul > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Monday, January 31, 2011 8:08 AM > > To: Paul E. Jones; dispatch@ietf.org > > Subject: RE: [dispatch] draft-jones-ipmc-session-id-01 > > > > Paul, > > > > The draft looks good in the high level. > > > > In case UUID is provided in two parts, it will helpful for analysis of > > > UUID as UUID composes of two parts from different devices and only one > > > portion will be helpful identify whether it is belongs to the same > > session. > > > > One of the usecase of UUID is SIPREC CS group id (CSG) mechanism . > > Here, Session Recording Client (SRC) shall create one portion of UUID, > > > multiple participants *may* change during the session, and SRC portion > > > of UUID will help to track the session. IMO, the syntax with two UUID > > part provides more clarity. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Sunday, January 30, 2011 10:38 PM > > To: dispatch@ietf.org > > Subject: [dispatch] draft-jones-ipmc-session-id-01 > > > > Folks, > > > > I just wanted to draw your attention to the revised Session ID draft > > we just submitted. Following the discussion we had on this topic > > previously, we introduced one important change: rather than using the > > Contact header, we introduce a new header to convey the UUID used by > > each endpoint that comprises the Session-ID. > > > > The revised draft is here: > > http://tools.ietf.org/html/draft-jones-ipmc-session-id > > > > We welcome any additional comments and input on a way to move this > > forward. > > > > Paul > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Tue Feb 1 14:47:19 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9243A6B30 for ; Tue, 1 Feb 2011 14:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.341 X-Spam-Level: X-Spam-Status: No, score=-103.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bBDDGxsKfRW for ; Tue, 1 Feb 2011 14:47:17 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id D4C353A6885 for ; Tue, 1 Feb 2011 14:47:16 -0800 (PST) Received: by ywk9 with SMTP id 9so3109206ywk.31 for ; Tue, 01 Feb 2011 14:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cu1gKQnPlasPMTx0b/pl0/4v2xS0Eo7jk0clTzBC41g=; b=tznsfZIDsZ8uqZAiRreSxcEsN9L4X/7wvymXMigqR1LPK+xe+amVrz1I1fEF4CBg5O K1GGf+LIKwyuy+q2hRb4Z72+ZMdowi/uvTw0yHI73x0mqByUfRjibpa+dAEmrhoLo6OI bz5A/wWR0b3OzPsaB5Py22Nggkonug6RyS0bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZzGB56yxJBEJXMQ4T6U/FH8PIJ4mq1L7Ax0KY2IXoZDj1IUuWE1Si5WCShrLvTnCrc RUrfWD9gX3chSSDig8LfUfr36UyArJ33471ViBDS6yFXKC4NehVxTMmJNZdg5hiylANe CAZW/V6XDQZljjQZuPyttKrZRu3t10Eo+SKUo= MIME-Version: 1.0 Received: by 10.236.109.168 with SMTP id s28mr131667yhg.74.1296600632795; Tue, 01 Feb 2011 14:50:32 -0800 (PST) Received: by 10.236.95.35 with HTTP; Tue, 1 Feb 2011 14:50:32 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 16:50:32 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=0023547c8b43222278049b405c30 Cc: rai-ads@tools.ietf.org Subject: [dispatch] Summary: topics put forth for IETF-80 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:47:19 -0000 --0023547c8b43222278049b405c30 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, The following summarizes the topics (in no particular order) that folks have put forth for discussion in the time preceeding IETF-80. Certainly, there has been lots of good discussion on some of the topics. However, for others, there has been little, if any, WG discussion. In order the chairs/ADs to determine how to dispatch the topics and allocate agenda time, we need feedback from the WG members. I have included links to the primary threads of discussion and annotated those which require more discussion with an asterisk (*). Please respond to the separate threads rather than this email so that we can better track feedback. If I missed your topic, please let us know ASAP. Note, that per the IETF-80 timeline, we will summarize the dispatchment of the items on Feb. 7th, announcing those that will be given f2f agenda time in Prague. Thanks, Mary DISPATCH WG co-chair 1) RTCWEB: http://www.ietf.org/mail-archive/web/dispatch/current/msg03171.html Excellent feedback and discussion thus far. An official Bof has been approved for this topic: http://trac.tools.ietf.org/bof/trac/#RAI 2) VIPR: http://www.ietf.org/mail-archive/web/dispatch/current/msg03300.html Updated charter posted. More responses requested. 3) Q4S: http://www.ietf.org/mail-archive/web/dispatch/current/msg03071.html Updated charter (version 2) posted. Feedback requested. 4) 3892bis (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03162.html Feedback required. 5) SIP Action Referral: http://www.ietf.org/mail-archive/web/dispatch/current/msg03211.html Proposal to move this to SPLICES WG. 6) Restful API for ACH (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03212.html This topic was previously discussed in BLISS, where there was support for it. However, BLISS is intending to close, thus the work item was sent to DISPATCH. Feedback requested as to whether this functionality is useful - i.e., will folks implement this? 7) SIP Interconnect guidelines (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html One question to consider is whether this is something within the scope of RAI or whether the work might be better done in another Forum (e.g., SIP Forum). Feedback as to whether folks think this document is useful is requested, as well as whether folks think it's relevant and whether it should be published in the IETF in some form. 8) Reason header in responses: http://www.ietf.org/mail-archive/web/dispatch/current/msg03296.html Roland has produced a new draft that documents the solution as an UPDATE to RFC 3326. Appears to be general agreement that this is the best approach. Details need to be worked. 9) End-to-End Session Identification (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03321.html A new draft has been submitted on this topic - draft-jones-ipmc-session-id. There's been a small amount of feedback and there's been no discussion of the Session ID topic since IETF-78. However, this topic comes up every 6 months or so. Group needs to decide if they want to solve this problem and the scope/applicability of the solution. --0023547c8b43222278049b405c30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,
The following summarizes the topics (in no particular order) that folk= s have put forth for discussion in the time preceeding IETF-80. =A0Certainl= y, there has been lots of good discussion on some of the topics. However, f= or others, there has been little, if any, WG discussion. =A0In order the ch= airs/ADs to determine how to dispatch the topics and allocate agenda time, = we need feedback from the WG members. =A0I have included links to the prima= ry threads of discussion and annotated those which require more discussion = with an asterisk (*). =A0Please respond to the separate threads rather than= this email so that we can better track feedback. =A0If I missed your topic= , please let us know ASAP. =A0Note, that per the IETF-80 timeline, we will = summarize the dispatchment of the items on Feb. 7th, announcing those that = will be given f2f agenda time in Prague.=A0

Thanks,
Mary=A0
DISPATCH WG co-chair


Excellent feedback and discussion thus far.=A0An official Bof has been= approved for this topic:
http://trac.tools.ietf.org/bof/trac/#RAI


Updated charter posted.=A0More responses=A0requested.=A0



Updated charter (version 2) =A0posted. =A0Feedback requested.


Feedback required.=A0



Proposal to move this to SPLICES WG.



This topic was previously discussed in BLISS, where there was support = for it. However, BLISS is intending to close, thus the work item was sent t= o DISPATCH. =A0Feedback requested as to whether this functionality is usefu= l - i.e., will folks implement this?=A0



One question to consider is whether this is something within the scope= of RAI or whether the work might be better done in another Forum (e.g., SI= P Forum). =A0Feedback as to whether folks think this document is useful is = requested, as well as whether folks think it's relevant and whether it = should be published in the IETF in some form.=A0
=A0


Roland has produced a new draft that documents the solution as an UPDA= TE to RFC 3326.=A0 Appears to be
general agreement that this is the best approach. Details need to be w= orked.

=A0

A new draft has been submitted on this topic - draft-j= ones-ipmc-session-id. =A0There's been a small amount of feedback and th= ere's been no discussion of the Session ID topic since IETF-78. =A0Howe= ver, this topic comes up every 6 months or so. Group needs to decide if the= y want to solve this problem=A0and the scope/applicability of the solution.= =A0





--0023547c8b43222278049b405c30-- From paulej@packetizer.com Tue Feb 1 14:49:12 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042603A6B30 for ; Tue, 1 Feb 2011 14:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW13X4gxTNoL for ; Tue, 1 Feb 2011 14:49:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 794633A6885 for ; Tue, 1 Feb 2011 14:49:10 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p11MqLAt019930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Feb 2011 17:52:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1296600747; bh=Ubv+Dz52qjJV77T++3Elgrp4aDsp5Wc0s2qjI3VVHjo=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q+4ExlBmrJ++ue/IGQRw3H6L8/V0xDU3pBFvFpPN/I7rfu2n1QoacE6O/DO6Eizo8 Vlj1Fueowq/li3dxUyBOEoGkjG21JJrbm5eelRshzgWp1PBbnoxw80taKAqvde7RbV 2VF8nRiTOqV6z8upVAi8TowLSs65EZMP+dgWt6Ys= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <4D46DF4E.8030805@cisco.com> In-Reply-To: <4D46DF4E.8030805@cisco.com> Date: Tue, 1 Feb 2011 17:52:06 -0500 Message-ID: <024401cbc262$a9a641e0$fcf2c5a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA7Fy1vbvX3nVJZeZhtnW6LVnUIgIMKh6ok3KDNdA= Content-Language: en-us Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:49:12 -0000 Paul, > - This seems much like a dialog id, which includes a to-tag and > from-tag. The UUIDs you describe are much like the tags. Yes, similar, though a tag is not globally unique. > - I guess the difference from tags is that the tags are supposed to > be unique for each new dialog, while the UUIDs you describe are > supposed to retain the same UUID across multiple dialogs in some > cases. Is that right? An MCU might consider using the same UUID value for each participant in the same conference: we probably need to discuss that a bit to see if it makes sense. For other endpoints, I'd expect the UUID to remain the same for a single dialog. If a call is forwarded (3xx), the same UUID would be retained. If the call is transferred via REFER, then we might want to keep the same value or create a new one. There are pros and cons with each approach. We're proposing to keep it unchanged across dialogs in this case. > - I don't quite follow the rules for when a UUID should remain > the same across dialogs and when it should be changed. This seems > to be related to implied definition of "session". Can you nail > that down in more detail? (You say the UUID must be retained when > the session is REFERed or redirected. But does that mean that all > processing of REFER and 3xx result in retaining the UUID, or only > when that preserves as "session"? If we agree there is value in retaining the session-UUID even when a call is redirected or transferred, yes. I think the 3xx is not a point of confusion, but REFER is. From a user perspective, a "session" lives from the moment a user calls a remote user to the time he/she hangs up the phone. The call might be redirected or forwarded any number of times. We can/should define this if folks agree that we should retain this value throughout the life of the "session". > - A particular case that seems to break your model is if you start > with a conference, where the focus has provided the same UUID to > all the participants, and then you partition that into two > independent conferences. (The same physical server may remain the > focus of both, but there is no mixing going on between the two.) > Do you expect in such a case that a new UUID would be assigned for > one (or both) of the resultant conferences? If a conference is partitioned like that, I would expect at least one or perhaps both partitions to assume a new UUID value. The reason is that at least one of these conferences is no longer the same conference. > There are even more complex examples of this - any time the mixing > is not the same for all participants. E.g. when some participants > move to a sidebar and then back to the main conference. It depends on how this is realized. Would those be separate distinct dialogs? > Another case would be a call center, where you have an agent > talking to a customer, and a supervisor listening in, receive only. > Then the supervisor might fully join it so there is equal mixing > among all three. Does that entail a change of UUID? In this case, there is a call A<->B and somehow C is receiving media. I assume B is forwarding that media to C in a separate B<->C session. B could have used the same UUID with C, since this is a form of a "conference". Or, B could have used a distinct UUID with C. The question as to which way is the right way to go is outside the scope of what we're defining. The Session-ID draft intends to define the UUID and composition. The rules for construction/conveyance under carious conferencing scenarios may need to be documented in a conferencing document somewhere, but not here. Multipoint conferencing can get complex in a hurry, which is likely a reason it's not fully addressed in 3261. > - You specify: > > "If performing interworking > between SIP and another session protocol, the intermediary MUST > convert the Session-ID-UUID header as necessary so that it preserves > the value of the UUID." > > But this is not always possible - it depends on the protocol > being interworked. This should at least be acknowledged. As stated, > a GW that can't do this would be non-conforming. Agreed. I'll make a note of this. > Something to consider here is whether this could be accomplished with an > extension pertaining to how the to/from-tags are assigned, rather than > introducing new tags for this purpose. We had it as a tag in the Contact header before, but folks preferred a separate header. I have no strong preference where it goes, so long as we retain the property that when A places a call, it sends a UUID in every message to the remote device for the duration of the "session". Paul From pkyzivat@cisco.com Tue Feb 1 17:10:00 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE163A6CA8 for ; Tue, 1 Feb 2011 17:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.028 X-Spam-Level: X-Spam-Status: No, score=-110.028 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_BACKHAIR_11=1, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm1nvMz4UBAO for ; Tue, 1 Feb 2011 17:09:59 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BB7623A7066 for ; Tue, 1 Feb 2011 17:09:57 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC8+SE1AZnwM/2dsb2JhbAClEHOhX5sehVMEhROHEINC Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 01:13:14 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p121DENe019875; Wed, 2 Feb 2011 01:13:14 GMT Message-ID: <4D48AFAA.7010709@cisco.com> Date: Tue, 01 Feb 2011 20:13:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Paul E. Jones" References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <4D46DF4E.8030805@cisco.com> <024401cbc262$a9a641e0$fcf2c5a0$@packetizer.com> In-Reply-To: <024401cbc262$a9a641e0$fcf2c5a0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 01:10:00 -0000 On 2/1/2011 5:52 PM, Paul E. Jones wrote: > Paul, > >> - This seems much like a dialog id, which includes a to-tag and >> from-tag. The UUIDs you describe are much like the tags. > > Yes, similar, though a tag is not globally unique. au contraire - From 3261 section 19.3: When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. (Of course this is often violated, but then you can't lose too much sleep over those who fail to follow the rules. If it hurts, don't do it.) >> - I guess the difference from tags is that the tags are supposed to >> be unique for each new dialog, while the UUIDs you describe are >> supposed to retain the same UUID across multiple dialogs in some >> cases. Is that right? > > An MCU might consider using the same UUID value for each participant in the > same conference: we probably need to discuss that a bit to see if it makes > sense. > > For other endpoints, I'd expect the UUID to remain the same for a single > dialog. If a call is forwarded (3xx), the same UUID would be retained. If > the call is transferred via REFER, then we might want to keep the same value > or create a new one. There are pros and cons with each approach. We're > proposing to keep it unchanged across dialogs in this case. > >> - I don't quite follow the rules for when a UUID should remain >> the same across dialogs and when it should be changed. This seems >> to be related to implied definition of "session". Can you nail >> that down in more detail? (You say the UUID must be retained when >> the session is REFERed or redirected. But does that mean that all >> processing of REFER and 3xx result in retaining the UUID, or only >> when that preserves as "session"? > > If we agree there is value in retaining the session-UUID even when a call is > redirected or transferred, yes. I think the 3xx is not a point of > confusion, but REFER is. From a user perspective, a "session" lives from > the moment a user calls a remote user to the time he/she hangs up the phone. > The call might be redirected or forwarded any number of times. We > can/should define this if folks agree that we should retain this value > throughout the life of the "session". > >> - A particular case that seems to break your model is if you start >> with a conference, where the focus has provided the same UUID to >> all the participants, and then you partition that into two >> independent conferences. (The same physical server may remain the >> focus of both, but there is no mixing going on between the two.) >> Do you expect in such a case that a new UUID would be assigned for >> one (or both) of the resultant conferences? > > If a conference is partitioned like that, I would expect at least one or > perhaps both partitions to assume a new UUID value. The reason is that at > least one of these conferences is no longer the same conference. > >> There are even more complex examples of this - any time the mixing >> is not the same for all participants. E.g. when some participants >> move to a sidebar and then back to the main conference. > > It depends on how this is realized. Would those be separate distinct > dialogs? > >> Another case would be a call center, where you have an agent >> talking to a customer, and a supervisor listening in, receive only. >> Then the supervisor might fully join it so there is equal mixing >> among all three. Does that entail a change of UUID? > > In this case, there is a call A<->B and somehow C is receiving media. I > assume B is forwarding that media to C in a separate B<->C session. B could > have used the same UUID with C, since this is a form of a "conference". Or, > B could have used a distinct UUID with C. The question as to which way is > the right way to go is outside the scope of what we're defining. The > Session-ID draft intends to define the UUID and composition. The rules for > construction/conveyance under carious conferencing scenarios may need to be > documented in a conferencing document somewhere, but not here. Multipoint > conferencing can get complex in a hurry, which is likely a reason it's not > fully addressed in 3261. > >> - You specify: >> >> "If performing interworking >> between SIP and another session protocol, the intermediary MUST >> convert the Session-ID-UUID header as necessary so that it preserves >> the value of the UUID." >> >> But this is not always possible - it depends on the protocol >> being interworked. This should at least be acknowledged. As stated, >> a GW that can't do this would be non-conforming. > > Agreed. I'll make a note of this. > > >> Something to consider here is whether this could be accomplished with an >> extension pertaining to how the to/from-tags are assigned, rather than >> introducing new tags for this purpose. > > We had it as a tag in the Contact header before, but folks preferred a > separate header. I have no strong preference where it goes, so long as we > retain the property that when A places a call, it sends a UUID in every > message to the remote device for the duration of the "session". > > Paul > > > From juberti@google.com Tue Feb 1 22:44:35 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FB23A6B1F for ; Tue, 1 Feb 2011 22:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.776 X-Spam-Level: X-Spam-Status: No, score=-104.776 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuvkDhciEQGs for ; Tue, 1 Feb 2011 22:44:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AE2753A69A7 for ; Tue, 1 Feb 2011 22:44:29 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p126llPo016377 for ; Tue, 1 Feb 2011 22:47:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296629268; bh=oX/ppemmS8BRShNdDB6wbaO6Gtc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gd64iWFw/httMV99xWd5tUVjRcxRJPpJtOTuIdg/psQzX9IER0ZnAtlOvFR2Mqhx0 qaH6/Gep7LBP57GUHaLoA== Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by hpaq3.eem.corp.google.com with ESMTP id p126lj0G032151 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Feb 2011 22:47:46 -0800 Received: by qyk34 with SMTP id 34so5312383qyk.10 for ; Tue, 01 Feb 2011 22:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qxo5Ls4/671l2Z0F44hiNcBLhl7WpB1oPy6RFER29Gs=; b=MU1gUrrGqoE1M2ybSBMy3Jnp8zowcHjS4tRbGOdPIM3XVc9rE6MZpDiHOWorlSUzXZ cyUj/BBn3gtPnxBMfQvA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=wpGbaili0Eq8ia4+mqTwYTJaE6fvPdQwqqLATxIE/iIKHsbgzSOrUA4KplgZPz78uU DcP28wc51eYbEVC2PqdQ== Received: by 10.229.241.69 with SMTP id ld5mr7839278qcb.189.1296629264598; Tue, 01 Feb 2011 22:47:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.7.201 with HTTP; Tue, 1 Feb 2011 22:47:24 -0800 (PST) In-Reply-To: <4D46DF69.6040503@skype.net> References: <4D4425C8.2080705@jdrosen.net> <4D46DF69.6040503@skype.net> From: Justin Uberti Date: Tue, 1 Feb 2011 22:47:24 -0800 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=00163630e871b8c932049b47065d X-System-Of-Record: true Cc: rtc-web@alvestrand.no, DISPATCH list Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 06:44:35 -0000 --00163630e871b8c932049b47065d Content-Type: text/plain; charset=UTF-8 Great example. And just like Gmail uses an SMTP gateway to connect its own HTTP-based protocol to the rest of the world, Gmail voice and video uses a XMPP gateway to connect its HTTP-based signaling to other XMPP clients. Others in this space have done similar things by implementing XMPP clients in Javascript. So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today. The two things that we need to specify are a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around) b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web). a) seems rather straightforward. b) will likely be trickier - we need something that can be mapped to SDP, for SIP gateways, but we probably want it to be represented as JSON for benefit of web developers. So the challenge becomes, what format can we define that can be unambiguously mapped to/from SDP, but doesn't bring with it all of the baggage of SDP? --justin On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman wrote: > On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote: > >> >> That said, even if one asks the question of whether it is a good idea for >> us to pick something, I think the answer is no. The enormous benefit of the >> web model is its ability for innovation and velocity. Standardization is not >> needed for communications within the domain of the provider; new features >> can be developed and deployed as quickly as they can be conceived. >> > > Agreed. Consider the case of Gmail (or any other web-based email) > > Did every web browser on the planet need to be upgraded to speak IMAP or > SMTP in order for Gmail to be implemented? No. > > Does the JavaScript that Gmail sends down to your browser in order to > implement its UI need to be standardized among web email platforms? No. > > Does Google need to use the same JavaScript libraries and PHP back-end that > SquirrelMail uses in order to implement a web email application? No. > > Can Google change that JavaScript tomorrow without breaking > interoperability? Yes, and they probably will. > > But could Gmail be as successful without the worldwide SMTP infrastructure > it ties in to? Probably not. > > I see the same situation here. A web browser with real-time communication > capabilities will work in conjunction with a web site that serves up the > HTML and JavaScript that makes up the calling application. For some > applications, this will be sufficient. For others, one will want to > implement SIP or XMPP/Jingle or something else in order to gateway these > calls to other networks. The SIP implementation can live in the JavaScript, > up in the web server, in a separate gateway, or any combination thereof. > > Matthew Kaufman > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > --00163630e871b8c932049b47065d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great example.=C2=A0

And just like Gmail uses an SMTP ga= teway to connect its own HTTP-based protocol to the rest of the world, Gmai= l voice and video uses a XMPP gateway to connect its HTTP-based signaling t= o other XMPP clients. Others in this space have done similar things by impl= ementing XMPP clients in Javascript.

So I think we have existence proofs that this approach,= in addition to being extremely flexible, is entirely workable today.
=

The two things that we need to specify are
a) the semantics of the signaling (i.e. the offer-answer mechanism that bot= h SIP and XMPP are patterned around)
b) the mechanism through whi= ch session offers and answers will be described (e.g. some SDP-ish thing th= at is suitable for the web).

a) seems rather straightforward. b) will likely be tric= kier - we need something that can be mapped to SDP, for SIP gateways, but w= e probably want it to be represented as JSON for benefit of web developers.= So the challenge becomes, what format can we define that can be unambiguou= sly mapped to/from SDP, but doesn't bring with it all of the baggage of= SDP?

--justin

On Mon,= Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net> = wrote:
On 1/29/2011 6:35 AM, Jon= athan Rosenberg wrote:

That said, even if one asks the question of whether it is a good idea for u= s to pick something, I think the answer is no. The enormous benefit of the = web model is its ability for innovation and velocity. Standardization is no= t needed for communications within the domain of the provider; new features= can be developed and deployed as quickly as they can be conceived.

Agreed. Consider the case of Gmail (or any other web-based email)

Did every web browser on the planet need to be upgraded to speak IMAP or SM= TP in order for Gmail to be implemented? No.

Does the JavaScript that Gmail sends down to your browser in order to imple= ment its UI need to be standardized among web email platforms? No.

Does Google need to use the same JavaScript libraries and PHP back-end that= SquirrelMail uses in order to implement a web email application? No.

Can Google change that JavaScript tomorrow without breaking interoperabilit= y? Yes, and they probably will.

But could Gmail be as successful without the worldwide SMTP infrastructure = it ties in to? Probably not.

I see the same situation here. A web browser with real-time communication c= apabilities will work in conjunction with a web site that serves up the HTM= L and JavaScript that makes up the calling application. For some applicatio= ns, this will be sufficient. For others, one will want to implement SIP or = XMPP/Jingle or something else in order to gateway these calls to other netw= orks. The SIP implementation can live in the JavaScript, up in the web serv= er, in a separate gateway, or any combination thereof.

Matthew Kaufman

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestra= nd.no
http://www.alvestrand.no/mailman/listinfo/rtc-web

--00163630e871b8c932049b47065d-- From paulej@packetizer.com Tue Feb 1 23:06:25 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87D43A7035 for ; Tue, 1 Feb 2011 23:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfG6XwweYrm2 for ; Tue, 1 Feb 2011 23:06:23 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 012A33A6E88 for ; Tue, 1 Feb 2011 23:06:19 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p1279UK0004683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Feb 2011 02:09:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1296630575; bh=I4S7idUFWGiJCtRCo9Be6CFng61kepRPdi72XV4LHZ4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KQWxvqMnRbr6hsO0conTU2JBSo/Ch9zZjYL0sDf0a9lIOqS02cRPWsIt3cjI0A6WP iPMY7eJ1bSmX/fk6HAt7ntvToGRZZBlNNKcBAWZJEKxnOY5h0mhHEgV+9IwX/DnSDr vZQXdLpzXddOhmOTn34Rj1hlETLdIgk+uKDT30+4= From: "Paul E. Jones" To: "'Salvatore Loreto'" , References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <001901cbc1b8$91a90eb0$b4fb2c10$@packetizer.com> <4D47B8E0.3090409@ericsson.com> In-Reply-To: <4D47B8E0.3090409@ericsson.com> Date: Wed, 2 Feb 2011 02:09:14 -0500 Message-ID: <032901cbc2a8$1c884ce0$5598e6a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA7Fy1vbvX3nVJZeZhtnW6LVnUIgG4H8jSANaP474BZV7b05Nj1k8A Content-Language: en-us Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 07:06:25 -0000 Sal, What changes would we need to meet the requirements of those two WGs? Any specifics in mind now? Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Salvatore Loreto > Sent: Tuesday, February 01, 2011 2:40 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 > > On 2/1/11 3:34 AM, Paul E. Jones wrote: > > Partha, > > > > Thanks for the feedback. The question is "where do we go from here?" > > I have a number of applications for a unique end-to-end session ID. > > SIPREC is certainly one where we can use it. I'd also like to use it > > for tracing media flows, signaling exchanges, associating devices in a > conference, etc. > > actually the draft can also be adapted to be also used in both the > loosely coupled sip devices (SPLICES wg) > and in the SIP interwork with XMPP (sixpac) > > /Sal > > -- > Salvatore Loreto > www.sloreto.com > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Wed Feb 2 00:21:33 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5083A7075 for ; Wed, 2 Feb 2011 00:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.623 X-Spam-Level: X-Spam-Status: No, score=-106.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXe0USBKwvuN for ; Wed, 2 Feb 2011 00:21:31 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 32E053A6CAC for ; Wed, 2 Feb 2011 00:21:30 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-b2-4d4914d1f69d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9F.33.13987.1D4194D4; Wed, 2 Feb 2011 09:24:49 +0100 (CET) Received: from [131.160.126.175] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Feb 2011 09:24:48 +0100 Message-ID: <4D4914D0.1090506@ericsson.com> Date: Wed, 2 Feb 2011 10:24:48 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , "rai-ads@tools.ietf.org" Subject: [dispatch] RTCWEB BOF was (Re: Summary: topics put forth for IETF-80) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:21:33 -0000 Folks, > 1) RTCWEB: > http://www.ietf.org/mail-archive/web/dispatch/current/msg03171.html > > Excellent feedback and discussion thus far. An official Bof has been > approved for this topic: > http://trac.tools.ietf.org/bof/trac/#RAI Yes, we will have an RTCWEB BOF in Prague. The goal is to try and form a new WG. As you all know, the process of chartering a WG is a scoping process aimed to define what is in and what is out of the scope of the WG. Given that RTCWEB is a large area, there may be topics that come up during the discussions that do not end up in the charter of the WG for some reason. If that was the case, we would decide what to do with them in DISPATCH afterward. Right now, our focus should be to work on a good charter proposal. Cheers, Gonzalo From Markus.Isomaki@nokia.com Wed Feb 2 00:22:32 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDAF3A7121 for ; Wed, 2 Feb 2011 00:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df-Va8NQYeip for ; Wed, 2 Feb 2011 00:22:30 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 402FF3A6E3D for ; Wed, 2 Feb 2011 00:22:30 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p128PaB0017877; Wed, 2 Feb 2011 10:25:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 10:25:00 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Feb 2011 09:24:59 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi; Wed, 2 Feb 2011 09:24:59 +0100 From: To: , Thread-Topic: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? Thread-Index: AQHLwqUnjPn2aJpqm0yYjZf4Rk4OX5Pt2qKQ Date: Wed, 2 Feb 2011 08:24:43 +0000 Message-ID: References: <4D4425C8.2080705@jdrosen.net> <4D46DF69.6040503@skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DD8B10B86502AB488CB2D3DB4C546E38E69896008AM1MPN1004mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2011 08:25:00.0270 (UTC) FILETIME=[AECB08E0:01CBC2B2] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:22:32 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E38E69896008AM1MPN1004mgdn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpJ4oCZbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIHRhc2sg YikgdGhhdCB5b3UgZGVzY3JpYmUgYmVsb3cuIFlvdSBhcmUgbm90IHRhbGtpbmcgYWJvdXQgYSBy ZXByZXNlbnRhdGlvbi9tZWNoYW5pc20gZm9yIGEgd2lyZSBwcm90b2NvbCwgYnV0IHNvbWV0aGlu ZyByZWxhdGVkIHRvIHRoZSBBUEk/IEkgbWVhbiwgaWYgZXZlcnlvbmUgaXMgZ29pbmcgdG8gZGVm aW5lIGFuZCBpbXBsZW1lbnQgdGhlaXIgb3duIOKAnHNpZ25hbGluZ+KAnSBwcm90b2NvbCBvbiBI VFRQIG9yIHdlYnNvY2tldHMsIHdoYXQgaXMgaXQgZXhhY3RseSB0aGF0IHdvdWxkIG5lZWQgdG8g YmUgc3RhbmRhcmRpemVkPw0KDQpJZiB3ZSB1c2Ugd2VibWFpbCBhcyBhbiBleGFtcGxlLCB0aGVy ZSBoYXMgYmVlbiBubyBuZWVkIHRvIGRlZmluZSBhbnkgbWFwcGluZy9mb3JtYXQgcmVsYXRlZCB0 byBTTVRQLiBTbyBpZiB0aGF0IGNhc2UgaXMgYW5hbG9nb3VzIHRvIHRoaXMgb25lLCB3aHkgd2Ug bmVlZCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGhlcmU/IEkga25vdyB0aGF0IHRoZSBkaWZm ZXJlbmNlIGlzIHRoYXQgaW4gUlRDLVdlYiB3ZSB3YW50IHRvIGVzdGFibGlzaCBtZWRpYSBzdHJl YW1zIGVuZC10by1lbmQgYmV0d2VlbiB0aGUgYnJvd3NlcnMsIHVubGlrZSBpbiBlLW1haWwuIFNv LCB0aGUgY2FzZXMgYXJlIG5vdCBmdWxseSBhbmFsb2dvdXMgYWZ0ZXIgYWxsLiBTb21lIGVsYWJv cmF0aW9uIG9uIHRoYXQgcG9pbnQgd291bGQgaGVscCBtYW55IHBlb3BsZSB0byB1bmRlcnN0YW5k IHRoZSBSVEMtV2ViIG5lZWQgYmV0dGVyLCBJIHRoaW5rLg0KDQpUaGFua3MsDQpNYXJrdXMNCg0K DQpGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBKdXN0aW4gVWJlcnRpDQpTZW50OiAwMiBGZWJy dWFyeSwgMjAxMSAwODo0Nw0KVG86IE1hdHRoZXcgS2F1Zm1hbg0KQ2M6IHJ0Yy13ZWJAYWx2ZXN0 cmFuZC5ubzsgRElTUEFUQ0ggbGlzdA0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gW1JUV10gRG9l cyBSVEMtV0VCIG5lZWQgdG8gcGljayBhIHNpZ25hbGluZyBwcm90b2NvbD8NCg0KR3JlYXQgZXhh bXBsZS4NCg0KQW5kIGp1c3QgbGlrZSBHbWFpbCB1c2VzIGFuIFNNVFAgZ2F0ZXdheSB0byBjb25u ZWN0IGl0cyBvd24gSFRUUC1iYXNlZCBwcm90b2NvbCB0byB0aGUgcmVzdCBvZiB0aGUgd29ybGQs IEdtYWlsIHZvaWNlIGFuZCB2aWRlbyB1c2VzIGEgWE1QUCBnYXRld2F5IHRvIGNvbm5lY3QgaXRz IEhUVFAtYmFzZWQgc2lnbmFsaW5nIHRvIG90aGVyIFhNUFAgY2xpZW50cy4gT3RoZXJzIGluIHRo aXMgc3BhY2UgaGF2ZSBkb25lIHNpbWlsYXIgdGhpbmdzIGJ5IGltcGxlbWVudGluZyBYTVBQIGNs aWVudHMgaW4gSmF2YXNjcmlwdC4NCg0KU28gSSB0aGluayB3ZSBoYXZlIGV4aXN0ZW5jZSBwcm9v ZnMgdGhhdCB0aGlzIGFwcHJvYWNoLCBpbiBhZGRpdGlvbiB0byBiZWluZyBleHRyZW1lbHkgZmxl eGlibGUsIGlzIGVudGlyZWx5IHdvcmthYmxlIHRvZGF5Lg0KDQpUaGUgdHdvIHRoaW5ncyB0aGF0 IHdlIG5lZWQgdG8gc3BlY2lmeSBhcmUNCmEpIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHNpZ25hbGlu ZyAoaS5lLiB0aGUgb2ZmZXItYW5zd2VyIG1lY2hhbmlzbSB0aGF0IGJvdGggU0lQIGFuZCBYTVBQ IGFyZSBwYXR0ZXJuZWQgYXJvdW5kKQ0KYikgdGhlIG1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIHNl c3Npb24gb2ZmZXJzIGFuZCBhbnN3ZXJzIHdpbGwgYmUgZGVzY3JpYmVkIChlLmcuIHNvbWUgU0RQ LWlzaCB0aGluZyB0aGF0IGlzIHN1aXRhYmxlIGZvciB0aGUgd2ViKS4NCg0KYSkgc2VlbXMgcmF0 aGVyIHN0cmFpZ2h0Zm9yd2FyZC4gYikgd2lsbCBsaWtlbHkgYmUgdHJpY2tpZXIgLSB3ZSBuZWVk IHNvbWV0aGluZyB0aGF0IGNhbiBiZSBtYXBwZWQgdG8gU0RQLCBmb3IgU0lQIGdhdGV3YXlzLCBi dXQgd2UgcHJvYmFibHkgd2FudCBpdCB0byBiZSByZXByZXNlbnRlZCBhcyBKU09OIGZvciBiZW5l Zml0IG9mIHdlYiBkZXZlbG9wZXJzLiBTbyB0aGUgY2hhbGxlbmdlIGJlY29tZXMsIHdoYXQgZm9y bWF0IGNhbiB3ZSBkZWZpbmUgdGhhdCBjYW4gYmUgdW5hbWJpZ3VvdXNseSBtYXBwZWQgdG8vZnJv bSBTRFAsIGJ1dCBkb2Vzbid0IGJyaW5nIHdpdGggaXQgYWxsIG9mIHRoZSBiYWdnYWdlIG9mIFNE UD8NCg0KLS1qdXN0aW4NCk9uIE1vbiwgSmFuIDMxLCAyMDExIGF0IDg6MTIgQU0sIE1hdHRoZXcg S2F1Zm1hbiA8bWF0dGhldy5rYXVmbWFuQHNreXBlLm5ldDxtYWlsdG86bWF0dGhldy5rYXVmbWFu QHNreXBlLm5ldD4+IHdyb3RlOg0KT24gMS8yOS8yMDExIDY6MzUgQU0sIEpvbmF0aGFuIFJvc2Vu YmVyZyB3cm90ZToNCg0KVGhhdCBzYWlkLCBldmVuIGlmIG9uZSBhc2tzIHRoZSBxdWVzdGlvbiBv ZiB3aGV0aGVyIGl0IGlzIGEgZ29vZCBpZGVhIGZvciB1cyB0byBwaWNrIHNvbWV0aGluZywgSSB0 aGluayB0aGUgYW5zd2VyIGlzIG5vLiBUaGUgZW5vcm1vdXMgYmVuZWZpdCBvZiB0aGUgd2ViIG1v ZGVsIGlzIGl0cyBhYmlsaXR5IGZvciBpbm5vdmF0aW9uIGFuZCB2ZWxvY2l0eS4gU3RhbmRhcmRp emF0aW9uIGlzIG5vdCBuZWVkZWQgZm9yIGNvbW11bmljYXRpb25zIHdpdGhpbiB0aGUgZG9tYWlu IG9mIHRoZSBwcm92aWRlcjsgbmV3IGZlYXR1cmVzIGNhbiBiZSBkZXZlbG9wZWQgYW5kIGRlcGxv eWVkIGFzIHF1aWNrbHkgYXMgdGhleSBjYW4gYmUgY29uY2VpdmVkLg0KDQpBZ3JlZWQuIENvbnNp ZGVyIHRoZSBjYXNlIG9mIEdtYWlsIChvciBhbnkgb3RoZXIgd2ViLWJhc2VkIGVtYWlsKQ0KDQpE aWQgZXZlcnkgd2ViIGJyb3dzZXIgb24gdGhlIHBsYW5ldCBuZWVkIHRvIGJlIHVwZ3JhZGVkIHRv IHNwZWFrIElNQVAgb3IgU01UUCBpbiBvcmRlciBmb3IgR21haWwgdG8gYmUgaW1wbGVtZW50ZWQ/ IE5vLg0KDQpEb2VzIHRoZSBKYXZhU2NyaXB0IHRoYXQgR21haWwgc2VuZHMgZG93biB0byB5b3Vy IGJyb3dzZXIgaW4gb3JkZXIgdG8gaW1wbGVtZW50IGl0cyBVSSBuZWVkIHRvIGJlIHN0YW5kYXJk aXplZCBhbW9uZyB3ZWIgZW1haWwgcGxhdGZvcm1zPyBOby4NCg0KRG9lcyBHb29nbGUgbmVlZCB0 byB1c2UgdGhlIHNhbWUgSmF2YVNjcmlwdCBsaWJyYXJpZXMgYW5kIFBIUCBiYWNrLWVuZCB0aGF0 IFNxdWlycmVsTWFpbCB1c2VzIGluIG9yZGVyIHRvIGltcGxlbWVudCBhIHdlYiBlbWFpbCBhcHBs aWNhdGlvbj8gTm8uDQoNCkNhbiBHb29nbGUgY2hhbmdlIHRoYXQgSmF2YVNjcmlwdCB0b21vcnJv dyB3aXRob3V0IGJyZWFraW5nIGludGVyb3BlcmFiaWxpdHk/IFllcywgYW5kIHRoZXkgcHJvYmFi bHkgd2lsbC4NCg0KQnV0IGNvdWxkIEdtYWlsIGJlIGFzIHN1Y2Nlc3NmdWwgd2l0aG91dCB0aGUg d29ybGR3aWRlIFNNVFAgaW5mcmFzdHJ1Y3R1cmUgaXQgdGllcyBpbiB0bz8gUHJvYmFibHkgbm90 Lg0KDQpJIHNlZSB0aGUgc2FtZSBzaXR1YXRpb24gaGVyZS4gQSB3ZWIgYnJvd3NlciB3aXRoIHJl YWwtdGltZSBjb21tdW5pY2F0aW9uIGNhcGFiaWxpdGllcyB3aWxsIHdvcmsgaW4gY29uanVuY3Rp b24gd2l0aCBhIHdlYiBzaXRlIHRoYXQgc2VydmVzIHVwIHRoZSBIVE1MIGFuZCBKYXZhU2NyaXB0 IHRoYXQgbWFrZXMgdXAgdGhlIGNhbGxpbmcgYXBwbGljYXRpb24uIEZvciBzb21lIGFwcGxpY2F0 aW9ucywgdGhpcyB3aWxsIGJlIHN1ZmZpY2llbnQuIEZvciBvdGhlcnMsIG9uZSB3aWxsIHdhbnQg dG8gaW1wbGVtZW50IFNJUCBvciBYTVBQL0ppbmdsZSBvciBzb21ldGhpbmcgZWxzZSBpbiBvcmRl ciB0byBnYXRld2F5IHRoZXNlIGNhbGxzIHRvIG90aGVyIG5ldHdvcmtzLiBUaGUgU0lQIGltcGxl bWVudGF0aW9uIGNhbiBsaXZlIGluIHRoZSBKYXZhU2NyaXB0LCB1cCBpbiB0aGUgd2ViIHNlcnZl ciwgaW4gYSBzZXBhcmF0ZSBnYXRld2F5LCBvciBhbnkgY29tYmluYXRpb24gdGhlcmVvZi4NCg0K TWF0dGhldyBLYXVmbWFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpSVEMtV2ViIG1haWxpbmcgbGlzdA0KUlRDLVdlYkBhbHZlc3RyYW5kLm5vPG1h aWx0bzpSVEMtV2ViQGFsdmVzdHJhbmQubm8+DQpodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFp bG1hbi9saXN0aW5mby9ydGMtd2ViDQoNCg== --_000_DD8B10B86502AB488CB2D3DB4C546E38E69896008AM1MPN1004mgdn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0K PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz5IaSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5J4oCZbSBub3Qgc3Vy ZSBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIHRhc2sgYikgdGhhdCB5b3UgZGVzY3JpYmUNCmJlbG93 LiBZb3UgYXJlIG5vdCB0YWxraW5nIGFib3V0IGEgcmVwcmVzZW50YXRpb24vbWVjaGFuaXNtIGZv ciBhIHdpcmUNCnByb3RvY29sLCBidXQgc29tZXRoaW5nIHJlbGF0ZWQgdG8gdGhlIEFQST8gSSBt ZWFuLCBpZiBldmVyeW9uZSBpcyBnb2luZyB0byBkZWZpbmUNCmFuZCBpbXBsZW1lbnQgdGhlaXIg b3duIOKAnHNpZ25hbGluZ+KAnSBwcm90b2NvbCBvbiBIVFRQIG9yIHdlYnNvY2tldHMsIHdoYXQg aXMgaXQNCmV4YWN0bHkgdGhhdCB3b3VsZCBuZWVkIHRvIGJlIHN0YW5kYXJkaXplZD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPklmIHdlIHVzZSB3ZWJtYWlsIGFzIGFuIGV4YW1wbGUs IHRoZXJlIGhhcyBiZWVuIG5vIG5lZWQgdG8NCmRlZmluZSBhbnkgbWFwcGluZy9mb3JtYXQgcmVs YXRlZCB0byBTTVRQLiBTbyBpZiB0aGF0IGNhc2UgaXMgYW5hbG9nb3VzIHRvIHRoaXMNCm9uZSwg d2h5IHdlIG5lZWQgdG8gZG8gc29tZXRoaW5nIGRpZmZlcmVudCBoZXJlPyBJIGtub3cgdGhhdCB0 aGUgZGlmZmVyZW5jZSBpcw0KdGhhdCBpbiBSVEMtV2ViIHdlIHdhbnQgdG8gZXN0YWJsaXNoIG1l ZGlhIHN0cmVhbXMgZW5kLXRvLWVuZCBiZXR3ZWVuIHRoZQ0KYnJvd3NlcnMsIHVubGlrZSBpbiBl LW1haWwuIFNvLCB0aGUgY2FzZXMgYXJlIG5vdCBmdWxseSBhbmFsb2dvdXMgYWZ0ZXIgYWxsLiBT b21lDQplbGFib3JhdGlvbiBvbiB0aGF0IHBvaW50IHdvdWxkIGhlbHAgbWFueSBwZW9wbGUgdG8g dW5kZXJzdGFuZCB0aGUgUlRDLVdlYiBuZWVkDQpiZXR0ZXIsIEkgdGhpbmsuPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMUY0OTdEJz5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjUuMjVwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPk1hcmt1czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSd0ZXh0LWluZGVudDo1LjI1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0Ow0KZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4N CmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYu b3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPmV4dA0KSnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6 PC9iPiAwMiBGZWJydWFyeSwgMjAxMSAwODo0Nzxicj4NCjxiPlRvOjwvYj4gTWF0dGhldyBLYXVm bWFuPGJyPg0KPGI+Q2M6PC9iPiBydGMtd2ViQGFsdmVzdHJhbmQubm87IERJU1BBVENIIGxpc3Q8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gW1JUV10gRG9lcyBSVEMtV0VCIG5l ZWQgdG8gcGljayBhIHNpZ25hbGluZw0KcHJvdG9jb2w/PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkdyZWF0IGV4YW1wbGUuJm5ic3A7PG86cD48L286 cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5BbmQganVzdCBsaWtl IEdtYWlsIHVzZXMgYW4gU01UUCBnYXRld2F5IHRvIGNvbm5lY3QgaXRzIG93bg0KSFRUUC1iYXNl ZCBwcm90b2NvbCB0byB0aGUgcmVzdCBvZiB0aGUgd29ybGQsIEdtYWlsIHZvaWNlIGFuZCB2aWRl byB1c2VzIGEgWE1QUA0KZ2F0ZXdheSB0byBjb25uZWN0IGl0cyBIVFRQLWJhc2VkIHNpZ25hbGlu ZyB0byBvdGhlciBYTVBQIGNsaWVudHMuIE90aGVycyBpbg0KdGhpcyBzcGFjZSBoYXZlIGRvbmUg c2ltaWxhciB0aGluZ3MgYnkgaW1wbGVtZW50aW5nIFhNUFAgY2xpZW50cyBpbiBKYXZhc2NyaXB0 LjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPlNvIEkgdGhpbmsgd2UgaGF2ZSBleGlzdGVuY2UgcHJvb2ZzIHRoYXQgdGhpcyBhcHBy b2FjaCwgaW4NCmFkZGl0aW9uIHRvIGJlaW5nIGV4dHJlbWVseSBmbGV4aWJsZSwgaXMgZW50aXJl bHkgd29ya2FibGUgdG9kYXkuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIHR3byB0aGluZ3MgdGhhdCB3ZSBuZWVkIHRvIHNw ZWNpZnkgYXJlPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+YSkgdGhlIHNlbWFudGljcyBvZiB0aGUgc2lnbmFsaW5nIChpLmUuIHRoZSBvZmZl ci1hbnN3ZXINCm1lY2hhbmlzbSB0aGF0IGJvdGggU0lQIGFuZCBYTVBQIGFyZSBwYXR0ZXJuZWQg YXJvdW5kKTxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPmIpIHRoZSBtZWNoYW5pc20gdGhyb3VnaCB3aGljaCBzZXNzaW9uIG9mZmVycyBhbmQg YW5zd2Vycw0Kd2lsbCBiZSBkZXNjcmliZWQgKGUuZy4gc29tZSBTRFAtaXNoIHRoaW5nIHRoYXQg aXMgc3VpdGFibGUgZm9yIHRoZSB3ZWIpLjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPmEpIHNlZW1zIHJhdGhlciBzdHJhaWdodGZv cndhcmQuIGIpIHdpbGwgbGlrZWx5IGJlIHRyaWNraWVyDQotIHdlIG5lZWQgc29tZXRoaW5nIHRo YXQgY2FuIGJlIG1hcHBlZCB0byBTRFAsIGZvciBTSVAgZ2F0ZXdheXMsIGJ1dCB3ZQ0KcHJvYmFi bHkgd2FudCBpdCB0byBiZSByZXByZXNlbnRlZCBhcyBKU09OIGZvciBiZW5lZml0IG9mIHdlYiBk ZXZlbG9wZXJzLiBTbw0KdGhlIGNoYWxsZW5nZSBiZWNvbWVzLCB3aGF0IGZvcm1hdCBjYW4gd2Ug ZGVmaW5lIHRoYXQgY2FuIGJlIHVuYW1iaWd1b3VzbHkNCm1hcHBlZCB0by9mcm9tIFNEUCwgYnV0 IGRvZXNuJ3QgYnJpbmcgd2l0aCBpdCBhbGwgb2YgdGhlIGJhZ2dhZ2Ugb2YgU0RQPzxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+LS1qdXN0aW48bzpwPjwvbzpwPjwv cD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgSmFuIDMxLCAyMDExIGF0 IDg6MTIgQU0sIE1hdHRoZXcgS2F1Zm1hbiAmbHQ7PGENCmhyZWY9Im1haWx0bzptYXR0aGV3Lmth dWZtYW5Ac2t5cGUubmV0Ij5tYXR0aGV3LmthdWZtYW5Ac2t5cGUubmV0PC9hPiZndDsNCndyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+T24gMS8yOS8y MDExIDY6MzUgQU0sIEpvbmF0aGFuIFJvc2VuYmVyZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxicj4NClRoYXQgc2FpZCwgZXZlbiBpZiBvbmUgYXNrcyB0aGUg cXVlc3Rpb24gb2Ygd2hldGhlciBpdCBpcyBhIGdvb2QgaWRlYSBmb3IgdXMgdG8NCnBpY2sgc29t ZXRoaW5nLCBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgbm8uIFRoZSBlbm9ybW91cyBiZW5lZml0IG9m IHRoZSB3ZWIgbW9kZWwNCmlzIGl0cyBhYmlsaXR5IGZvciBpbm5vdmF0aW9uIGFuZCB2ZWxvY2l0 eS4gU3RhbmRhcmRpemF0aW9uIGlzIG5vdCBuZWVkZWQgZm9yDQpjb21tdW5pY2F0aW9ucyB3aXRo aW4gdGhlIGRvbWFpbiBvZiB0aGUgcHJvdmlkZXI7IG5ldyBmZWF0dXJlcyBjYW4gYmUgZGV2ZWxv cGVkDQphbmQgZGVwbG95ZWQgYXMgcXVpY2tseSBhcyB0aGV5IGNhbiBiZSBjb25jZWl2ZWQuPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5BZ3JlZWQuIENvbnNpZGVyIHRoZSBjYXNl IG9mIEdtYWlsIChvciBhbnkgb3RoZXIgd2ViLWJhc2VkDQplbWFpbCk8YnI+DQo8YnI+DQpEaWQg ZXZlcnkgd2ViIGJyb3dzZXIgb24gdGhlIHBsYW5ldCBuZWVkIHRvIGJlIHVwZ3JhZGVkIHRvIHNw ZWFrIElNQVAgb3IgU01UUA0KaW4gb3JkZXIgZm9yIEdtYWlsIHRvIGJlIGltcGxlbWVudGVkPyBO by48YnI+DQo8YnI+DQpEb2VzIHRoZSBKYXZhU2NyaXB0IHRoYXQgR21haWwgc2VuZHMgZG93biB0 byB5b3VyIGJyb3dzZXIgaW4gb3JkZXIgdG8gaW1wbGVtZW50DQppdHMgVUkgbmVlZCB0byBiZSBz dGFuZGFyZGl6ZWQgYW1vbmcgd2ViIGVtYWlsIHBsYXRmb3Jtcz8gTm8uPGJyPg0KPGJyPg0KRG9l cyBHb29nbGUgbmVlZCB0byB1c2UgdGhlIHNhbWUgSmF2YVNjcmlwdCBsaWJyYXJpZXMgYW5kIFBI UCBiYWNrLWVuZCB0aGF0IFNxdWlycmVsTWFpbA0KdXNlcyBpbiBvcmRlciB0byBpbXBsZW1lbnQg YSB3ZWIgZW1haWwgYXBwbGljYXRpb24/IE5vLjxicj4NCjxicj4NCkNhbiBHb29nbGUgY2hhbmdl IHRoYXQgSmF2YVNjcmlwdCB0b21vcnJvdyB3aXRob3V0IGJyZWFraW5nIGludGVyb3BlcmFiaWxp dHk/DQpZZXMsIGFuZCB0aGV5IHByb2JhYmx5IHdpbGwuPGJyPg0KPGJyPg0KQnV0IGNvdWxkIEdt YWlsIGJlIGFzIHN1Y2Nlc3NmdWwgd2l0aG91dCB0aGUgd29ybGR3aWRlIFNNVFAgaW5mcmFzdHJ1 Y3R1cmUgaXQgdGllcw0KaW4gdG8/IFByb2JhYmx5IG5vdC48YnI+DQo8YnI+DQpJIHNlZSB0aGUg c2FtZSBzaXR1YXRpb24gaGVyZS4gQSB3ZWIgYnJvd3NlciB3aXRoIHJlYWwtdGltZSBjb21tdW5p Y2F0aW9uDQpjYXBhYmlsaXRpZXMgd2lsbCB3b3JrIGluIGNvbmp1bmN0aW9uIHdpdGggYSB3ZWIg c2l0ZSB0aGF0IHNlcnZlcyB1cCB0aGUgSFRNTA0KYW5kIEphdmFTY3JpcHQgdGhhdCBtYWtlcyB1 cCB0aGUgY2FsbGluZyBhcHBsaWNhdGlvbi4gRm9yIHNvbWUgYXBwbGljYXRpb25zLCB0aGlzDQp3 aWxsIGJlIHN1ZmZpY2llbnQuIEZvciBvdGhlcnMsIG9uZSB3aWxsIHdhbnQgdG8gaW1wbGVtZW50 IFNJUCBvciBYTVBQL0ppbmdsZQ0Kb3Igc29tZXRoaW5nIGVsc2UgaW4gb3JkZXIgdG8gZ2F0ZXdh eSB0aGVzZSBjYWxscyB0byBvdGhlciBuZXR3b3Jrcy4gVGhlIFNJUA0KaW1wbGVtZW50YXRpb24g Y2FuIGxpdmUgaW4gdGhlIEphdmFTY3JpcHQsIHVwIGluIHRoZSB3ZWIgc2VydmVyLCBpbiBhIHNl cGFyYXRlDQpnYXRld2F5LCBvciBhbnkgY29tYmluYXRpb24gdGhlcmVvZi48YnI+DQo8c3BhbiBz dHlsZT0nY29sb3I6Izg4ODg4OCc+PGJyPg0KTWF0dGhldyBLYXVmbWFuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpSVEMtV2Vi IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpSVEMtV2ViQGFsdmVzdHJhbmQubm8i IHRhcmdldD0iX2JsYW5rIj5SVEMtV2ViQGFsdmVzdHJhbmQubm88L2E+PGJyPg0KPGEgaHJlZj0i aHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vcnRjLXdlYiIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL3J0Yy13 ZWI8L2E+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_DD8B10B86502AB488CB2D3DB4C546E38E69896008AM1MPN1004mgdn_-- From xavier.marjou@gmail.com Wed Feb 2 00:54:53 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D68B3A712A for ; Wed, 2 Feb 2011 00:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVXAXrtWuDzA for ; Wed, 2 Feb 2011 00:54:51 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4C6573A6B75 for ; Wed, 2 Feb 2011 00:54:51 -0800 (PST) Received: by qwi2 with SMTP id 2so8130517qwi.31 for ; Wed, 02 Feb 2011 00:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=u61YoPJjfhsVKFKhtrDGDXqrMfclpfHjhJ7VUuMglRQ=; b=GlZowBWgEkZhmAfsCFdyS0b2fKxOeOASKT1biEs4409RYamh+s+gK8dSaKHl8GOZ1o /5CSb/btGKSPuCTbwkotx1VmkkEDtRGHFv9rPPTnM9NuFs4NZQSlgr3dJgnVPXvNqsOg 6WlQzjRSi15RBrt6+TvOY1v3sYGtDVWbeq1Sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=qEyAJndcocSZRiIkhQMiGFD059o/PzMiRotXCdqyeBPCZjykXVVCj6q57M/p1JZBpt C40V1STHqcKcOvxRzIxhUS/opeEMdrRsrMsAPi5ZZD+4QrlLPY0sd5RelvOrP4YVVBau 63I1qFAvLsjfXCtA+NqCvuKvZr2ZBO3q/Rm3M= MIME-Version: 1.0 Received: by 10.224.11.75 with SMTP id s11mr8426330qas.16.1296637089932; Wed, 02 Feb 2011 00:58:09 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.220.187.9 with HTTP; Wed, 2 Feb 2011 00:58:09 -0800 (PST) In-Reply-To: References: <4D4425C8.2080705@jdrosen.net> <4D46DF69.6040503@skype.net> Date: Wed, 2 Feb 2011 09:58:09 +0100 X-Google-Sender-Auth: 8yoDmPgBx6nQ0YGnVV0fqyXK2BQ Message-ID: From: Xavier Marjou To: Justin Uberti Content-Type: multipart/alternative; boundary=0015175cdae825e622049b48d998 Cc: DISPATCH list , rtc-web@alvestrand.no Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:54:53 -0000 --0015175cdae825e622049b48d998 Content-Type: text/plain; charset=ISO-8859-1 I agree that it is important to have rtcweb interoperable with the rest of the world (i.e. millions of existing end-points that use SIP or XMPP). I think that interoperability with such protocols - which are IETF protocols by the way - should really be in the scope of the charter. On Wed, Feb 2, 2011 at 7:47 AM, Justin Uberti wrote: > Great example. > > And just like Gmail uses an SMTP gateway to connect its own HTTP-based > protocol to the rest of the world, Gmail voice and video uses a XMPP gateway > to connect its HTTP-based signaling to other XMPP clients. Others in this > space have done similar things by implementing XMPP clients in Javascript. > > So I think we have existence proofs that this approach, in addition to > being extremely flexible, is entirely workable today. > > The two things that we need to specify are > a) the semantics of the signaling (i.e. the offer-answer mechanism that > both SIP and XMPP are patterned around) > b) the mechanism through which session offers and answers will be described > (e.g. some SDP-ish thing that is suitable for the web). > > a) seems rather straightforward. b) will likely be trickier - we need > something that can be mapped to SDP, for SIP gateways, but we probably want > it to be represented as JSON for benefit of web developers. So the challenge > becomes, what format can we define that can be unambiguously mapped to/from > SDP, but doesn't bring with it all of the baggage of SDP? > > --justin > > > On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman < > matthew.kaufman@skype.net> wrote: > >> On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote: >> >>> >>> That said, even if one asks the question of whether it is a good idea for >>> us to pick something, I think the answer is no. The enormous benefit of the >>> web model is its ability for innovation and velocity. Standardization is not >>> needed for communications within the domain of the provider; new features >>> can be developed and deployed as quickly as they can be conceived. >>> >> >> Agreed. Consider the case of Gmail (or any other web-based email) >> >> Did every web browser on the planet need to be upgraded to speak IMAP or >> SMTP in order for Gmail to be implemented? No. >> >> Does the JavaScript that Gmail sends down to your browser in order to >> implement its UI need to be standardized among web email platforms? No. >> >> Does Google need to use the same JavaScript libraries and PHP back-end >> that SquirrelMail uses in order to implement a web email application? No. >> >> Can Google change that JavaScript tomorrow without breaking >> interoperability? Yes, and they probably will. >> >> But could Gmail be as successful without the worldwide SMTP infrastructure >> it ties in to? Probably not. >> >> I see the same situation here. A web browser with real-time communication >> capabilities will work in conjunction with a web site that serves up the >> HTML and JavaScript that makes up the calling application. For some >> applications, this will be sufficient. For others, one will want to >> implement SIP or XMPP/Jingle or something else in order to gateway these >> calls to other networks. The SIP implementation can live in the JavaScript, >> up in the web server, in a separate gateway, or any combination thereof. >> >> Matthew Kaufman >> >> _______________________________________________ >> RTC-Web mailing list >> RTC-Web@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtc-web >> > > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > > --0015175cdae825e622049b48d998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that it is important to have rtcweb interoperable with the res= t of the world (i.e. millions of existing end-points that use SIP or XMPP).= I think that interoperability with such protocols - which are=A0IETF proto= cols by the way - should really be in the scope of the charter.

On Wed, Feb 2, 2011 at 7:47 AM, Justin Ubert= i <juberti@googl= e.com> wrote:
Great example.=A0

And just like Gmail uses an SMTP gatew= ay to connect its own HTTP-based protocol to the rest of the world, Gmail v= oice and video uses a XMPP gateway to connect its HTTP-based signaling to o= ther XMPP clients. Others in this space have done similar things by impleme= nting XMPP clients in Javascript.

So I think we have existence proofs that this approach,= in addition to being extremely flexible, is entirely workable today.
=

The two things that we need to specify are
a) the semantics of the signaling (i.e. the offer-answer mechanism that bot= h SIP and XMPP are patterned around)
b) the mechanism through whi= ch session offers and answers will be described (e.g. some SDP-ish thing th= at is suitable for the web).

a) seems rather straightforward. b) will likely be tric= kier - we need something that can be mapped to SDP, for SIP gateways, but w= e probably want it to be represented as JSON for benefit of web developers.= So the challenge becomes, what format can we define that can be unambiguou= sly mapped to/from SDP, but doesn't bring with it all of the baggage of= SDP?

--justin
<= /div>


On Mon, Jan 31, 2= 011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net>= wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenber= g wrote:

That said, even if one asks the question of whether it is a good idea for u= s to pick something, I think the answer is no. The enormous benefit of the = web model is its ability for innovation and velocity. Standardization is no= t needed for communications within the domain of the provider; new features= can be developed and deployed as quickly as they can be conceived.

Agreed. Consider the case of Gmail (or any other web-based email)

Did every web browser on the planet need to be upgraded to speak IMAP or SM= TP in order for Gmail to be implemented? No.

Does the JavaScript that Gmail sends down to your browser in order to imple= ment its UI need to be standardized among web email platforms? No.

Does Google need to use the same JavaScript libraries and PHP back-end that= SquirrelMail uses in order to implement a web email application? No.

Can Google change that JavaScript tomorrow without breaking interoperabilit= y? Yes, and they probably will.

But could Gmail be as successful without the worldwide SMTP infrastructure = it ties in to? Probably not.

I see the same situation here. A web browser with real-time communication c= apabilities will work in conjunction with a web site that serves up the HTM= L and JavaScript that makes up the calling application. For some applicatio= ns, this will be sufficient. For others, one will want to implement SIP or = XMPP/Jingle or something else in order to gateway these calls to other netw= orks. The SIP implementation can live in the JavaScript, up in the web serv= er, in a separate gateway, or any combination thereof.

Matthew Kaufman

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestra= nd.no
http://www.alvestrand.no/mailman/listinfo/rtc-web


_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web


--0015175cdae825e622049b48d998-- From partr@cisco.com Wed Feb 2 01:28:02 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992553A713C for ; Wed, 2 Feb 2011 01:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGEAKID2ygjx for ; Wed, 2 Feb 2011 01:28:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 438913A7138 for ; Wed, 2 Feb 2011 01:28:01 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswCAKqySE1AaMHG/2dsb2JhbACWNo5ic6Famx6Ce4JYBIR2ihg Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2011 09:31:19 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p129UxTd022258; Wed, 2 Feb 2011 09:31:18 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 15:01:15 +0530 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: Wed, 2 Feb 2011 15:01:13 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP based Media overload control draft Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVA= References: From: "Parthasarathi R (partr)" To: "DRAGE, Keith (Keith)" , "Elwell, John" , , X-OriginalArrivalTime: 02 Feb 2011 09:31:15.0678 (UTC) FILETIME=[F05227E0:01CBC2BB] Subject: Re: [dispatch] SIP based Media overload control draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 09:28:02 -0000 Keith/John/Dale, Mediactrl (MRB) discusses about Resource monitoring at media server and currently, there is no mechanism exists for overload control. I attached SoC WG stance on SIP based Media overload control as a note of this mail. As a follow up query, Please let me know your take on whether SIP based media overload has to be solved as part of=20 1) Mediactrl WG=20 2) Any other WG exists. If so, Please name it. 3) New WG has to be created. 4) solve as individual draft. 5) or any other IETF way Thanks in advance Partha Note: Sec 1 of draft-ietf-soc-overload-design-04 There are cases in which a SIP server runs other services that do not involve the processing of SIP messages (e.g., processing of RTP packets, database queries, software updates and event handling). These services may, or may not, be correlated with the SIP message volume. These services can use up a substantial share of resources available on the server (e.g., CPU cycles) and leave the server in a condition where it is unable to process all incoming SIP requests. -----Original Message----- From: Parthasarathi R (partr)=20 Sent: Tuesday, January 25, 2011 6:23 PM To: 'DRAGE, Keith (Keith)'; Elwell, John; dispatch@ietf.org Cc: 'dworley@avaya.com' Subject: RE: SIP based Media overload control draft =20 Keith, AFAIK, the mentioned issue is not solved in MRB. Including Dale Worley (Mediactrl WG Chair) in this mail thread to double confirm my understanding. Apart from the Mediactrl Mediaservers, I'm trying to find the solution for devices which acts as both Application server(AS) and Media Server (MS) at the same time. In the deployment, these devices shall be realized as PSTN GW, SBC, IP PBX with media handling.=20 Thanks Partha -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Tuesday, January 25, 2011 3:31 PM To: Elwell, John; Parthasarathi R (partr); dispatch@ietf.org Subject: RE: SIP based Media overload control draft If they are mediaservers, then does not the media resource broker in mediactrl already address this issue. Regards Keith -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John Sent: 25 January 2011 08:28 To: Parthasarathi R (partr); dispatch@ietf.org Subject: Re: [dispatch] SIP based Media overload control draft Partha, A fundamental difference between the problem addressed by SOC and the problem stated in your draft is as follows. SOC addresses the problem where a SIP server is so overloaded that receipt of further SIP requests will compound the problem, and therefore it is essential to take steps to reduce the number of SIP requests arriving at the overloaded server. The problem described in your draft is where the server is not overloaded in the sense of being unable to handle further SIP requests, but is overloaded in terms of media it can handle. Therefore it can still receive SIP requests, but it would have to reject some of them if the necessary media resources are not available. There may still be some benefit in preventing SIP requests arriving if media resources are not available. The main benefit would be that those SIP requests can more quickly be rerouted elsewhere, thereby reducing call set-up time. One scenario that might benefit would be where there are several, perhaps 10 or more, candidate media servers for a particular request, and trying each of these in turn would definitely impact call establishment times (or call rejection times on occasions when all candidates are overloaded). Is this the essence of the problem you are trying to address? It seems the document could certainly do with more on use cases and potential benefits that a solution might bring. John > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > (partr) > Sent: 24 January 2011 19:38 > To: dispatch@ietf.org > Subject: [dispatch] SIP based Media overload control draft >=20 > Hi all, >=20 > IETF SoC WG is created for overload control solution of dedicated SIP=20 > signaling server only. There is an another kind of SIP servers exists=20 > in SIP deployment which handle SIP signaling and its related media=20 > (RTP, > T.38) in the same physical device. Those servers needs separate SIP=20 > based overload control solution. SIP based Media overload control=20 > draft summarizes problem specific to SIP media servers overload,=20 > requirements for SIP based media overload control solution and the=20 > draft is available at >=20 > http://datatracker.ietf.org/doc/draft-partha-dispatch-sip-medi > a-overload > -control/ >=20 > draft-partha-dispatch-resource-availability-00 and=20 > draft-jones-sip-overload-sce-00 are submitted in IETF-78 SoC WG for=20 > addressing the same problem. But, SIP based media overload control is=20 > considered as outside the scope of SoC WG. I'm interested in hearing=20 > from you whether this is a worth solving problem in IETF. >=20 > This draft is in straw-horse proposal state. I post this draft in=20 > dispatch to identify which WG is right place to solve this issue in=20 > IETF in case it is considered as worth solving problem. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, January 25, 2011 12:37 AM > To: Parthasarathi R (partr) > Subject: New Version Notification for > draft-partha-dispatch-sip-media-overload-control-00 >=20 >=20 > A new version of I-D, > draft-partha-dispatch-sip-media-overload-control-00.txt has been=20 > successfully submitted by Parthasarathi R and posted to the IETF=20 > repository. >=20 > Filename: draft-partha-dispatch-sip-media-overload-control > Revision: 00 > Title: Session Initiation Protocol (SIP)=20 > based Media overload > control Requirement > Creation_date: 2011-01-24 > WG ID: Independent Submission > Number_of_pages: 6 >=20 > Abstract: > Overload occurs in Session Initiation Protocol (SIP) networks when SIP > servers have insufficient resources to handle all SIP messages they=20 > receive. SIP based overload mechanism exists for dedicated SIP=20 > signaling servers. But there is a need for overload control solution=20 > of SIP based media servers like PSTN GW, Session border controllers=20 > (SBC), Session Recording Server(SRS). This document summarizes=20 > problem specific to SIP media servers, requirements for the solution=20 > of SIP based media overload control. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Wed Feb 2 03:10:12 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630A63A7142 for ; Wed, 2 Feb 2011 03:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAXMbIR5yzSg for ; Wed, 2 Feb 2011 03:10:11 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6EF6E3A6C98 for ; Wed, 2 Feb 2011 03:10:11 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3232935 for dispatch@ietf.org; Wed, 2 Feb 2011 12:13:29 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id A54EA23F0290 for ; Wed, 2 Feb 2011 12:13:29 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Feb 2011 12:13:29 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Wed, 2 Feb 2011 12:13:28 +0100 Thread-Topic: Basic Telephony SIP Interconnect Guideline Draft Thread-Index: AcvCyjd+JF6W5cDSRQ+ZdtY9QWj7Mw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 11:10:12 -0000 http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html If this is just profiling work, perhaps the SIP Forum would be a better ven= ue. John From christer.holmberg@ericsson.com Wed Feb 2 03:37:38 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490923A6C48 for ; Wed, 2 Feb 2011 03:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95cgiP3iWaU7 for ; Wed, 2 Feb 2011 03:37:37 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 390943A6C14 for ; Wed, 2 Feb 2011 03:37:37 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-3a-4d4942c7a8a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 58.0F.23694.7C2494D4; Wed, 2 Feb 2011 12:40:56 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 2 Feb 2011 12:40:55 +0100 From: Christer Holmberg To: "Elwell, John" , "dispatch@ietf.org" Date: Wed, 2 Feb 2011 12:40:54 +0100 Thread-Topic: Basic Telephony SIP Interconnect Guideline Draft Thread-Index: AcvCyjd+JF6W5cDSRQ+ZdtY9QWj7MwAAtFTw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519442D6074@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Basic Telephony SIP Interconnect Guideline Draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 11:37:38 -0000 Hi, In addition, at least ITU-T and 3GPP also have interconnect specifications. Regarding THIS draft, I am a little confused about that fact that it descri= bes UA procedures, e.g. how a UA shall handle forking. I don't see what tha= t has to do with interconnect. (I DO agree that it would be good to have common forking procedures in gene= ral, but that's another story :) Having said that, specifying that forking shall be supported over interconn= ect could be useful. ...unless, of course, you want to deploy SBCs at the interconnect point in = order to handle forked sessions :) Regards, Christer > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 2. helmikuuta 2011 13:13 > To: dispatch@ietf.org > Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft >=20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html >=20 > If this is just profiling work, perhaps the SIP Forum would=20 > be a better venue. >=20 > John >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From salvatore.loreto@ericsson.com Wed Feb 2 07:54:19 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35C73A6D2D for ; Wed, 2 Feb 2011 07:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smpGupVDLxi4 for ; Wed, 2 Feb 2011 07:54:16 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 173D03A6D0B for ; Wed, 2 Feb 2011 07:54:15 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-81-4d497eef55ec Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0C.96.13987.FEE794D4; Wed, 2 Feb 2011 16:57:35 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Feb 2011 16:57:35 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9EE3B2598; Wed, 2 Feb 2011 17:57:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5E1D6507F6; Wed, 2 Feb 2011 17:57:34 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82D32506D0; Wed, 2 Feb 2011 17:57:33 +0200 (EET) Message-ID: <4D497EED.5030706@ericsson.com> Date: Wed, 2 Feb 2011 16:57:33 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Paul E. Jones" References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <001901cbc1b8$91a90eb0$b4fb2c10$@packetizer.com> <4D47B8E0.3090409@ericsson.com> <032901cbc2a8$1c884ce0$5598e6a0$@packetizer.com> In-Reply-To: <032901cbc2a8$1c884ce0$5598e6a0$@packetizer.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 15:54:20 -0000 On 2/2/11 8:09 AM, Paul E. Jones wrote: > Sal, > > What changes would we need to meet the requirements of those two WGs? > Any > specifics in mind now? nothing specific at moment /Sal > Paul > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Salvatore Loreto >> Sent: Tuesday, February 01, 2011 2:40 AM >> To: dispatch@ietf.org >> Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 >> >> On 2/1/11 3:34 AM, Paul E. Jones wrote: >>> Partha, >>> >>> Thanks for the feedback. The question is "where do we go from here?" >>> I have a number of applications for a unique end-to-end session ID. >>> SIPREC is certainly one where we can use it. I'd also like to use it >>> for tracing media flows, signaling exchanges, associating devices in a >> conference, etc. >> >> actually the draft can also be adapted to be also used in both the >> loosely coupled sip devices (SPLICES wg) >> and in the SIP interwork with XMPP (sixpac) >> >> /Sal >> >> -- >> Salvatore Loreto >> www.sloreto.com >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Wed Feb 2 08:39:15 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB46A3A6D2C for ; Wed, 2 Feb 2011 08:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amsAGon02hVj for ; Wed, 2 Feb 2011 08:39:15 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id EF8923A6D81 for ; Wed, 2 Feb 2011 08:39:13 -0800 (PST) Received: by ewy8 with SMTP id 8so126320ewy.31 for ; Wed, 02 Feb 2011 08:42:33 -0800 (PST) Received: by 10.216.86.195 with SMTP id w45mr8294235wee.92.1296664951649; Wed, 02 Feb 2011 08:42:31 -0800 (PST) Received: from [10.114.119.215] ([62.50.234.185]) by mx.google.com with ESMTPS id n18sm12214106wee.16.2011.02.02.08.42.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 08:42:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> Date: Wed, 2 Feb 2011 16:42:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1082) Cc: DISPATCH list Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:39:15 -0000 Hi,=20 I find the lack of a some specific examples is leaving me with a = question I cannot answer by reading the spec (unless I missed = something).=20 So in a dialog startup: A sends Session-ID with just it's UUID in it. Final endpoint B responds with the combined UUIDs in a Session-ID header = (it's own plus A's in sorted order) So in e.g. debugging - if I want to correlate the INVITE with the = response I am comparing a one UUID header with a two UUID header? I don't think that is a huge deal - although it seems a bit more awkward = than just having the initiators UUID used throughout. It would be good = to make the benefits of 2 UUIDs in a header very clear.=20 Regards, Peter Musgrave On 2011-01-30, at 5:07 PM, Paul E. Jones wrote: > Folks, >=20 > I just wanted to draw your attention to the revised Session ID draft = we just > submitted. Following the discussion we had on this topic previously, = we > introduced one important change: rather than using the Contact header, = we > introduce a new header to convey the UUID used by each endpoint that > comprises the Session-ID. >=20 > The revised draft is here: > http://tools.ietf.org/html/draft-jones-ipmc-session-id >=20 > We welcome any additional comments and input on a way to move this = forward. >=20 > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Wed Feb 2 09:25:46 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339823A6D7C for ; Wed, 2 Feb 2011 09:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIDubri4g4xA for ; Wed, 2 Feb 2011 09:25:44 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 7289B3A6D79 for ; Wed, 2 Feb 2011 09:25:44 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p12HSvk8010941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Feb 2011 12:29:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1296667743; bh=uBBVf3pQOwQf3RDX6ycRMTLllrqMax5NzOF7vr2V43c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=E+73JOfdP9m056yFDzVQE8wuYN3U1D5GjPhBaW3+yZznknTvgGeVezenTcxuFWk99 I2o2eQoj8XpzBMOtwmbDy5U3tiNVSc45L0LB3MPpjwGcAKVg+6T8bkjZNk7IWc/DLD yMs/V02/YDns7CZNfVp5+LNCvWjgyRKCWA644Lh8= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <4D46DF4E.8030805@cisco.com> <024401cbc262$a9a641e0$fcf2c5a0$@packetizer.com> <4D48AFAA.7010709@cisco.com> In-Reply-To: <4D48AFAA.7010709@cisco.com> Date: Wed, 2 Feb 2011 12:28:40 -0500 Message-ID: <044a01cbc2fe$a58cf030$f0a6d090$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA7Fy1vbvX3nVJZeZhtnW6LVnUIgIMKh6oAWgWcysBg1mAYZNcY4LQ Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:25:46 -0000 Paul, > On 2/1/2011 5:52 PM, Paul E. Jones wrote: > > Paul, > > > >> - This seems much like a dialog id, which includes a to-tag and > >> from-tag. The UUIDs you describe are much like the tags. > > > > Yes, similar, though a tag is not globally unique. > > au contraire - From 3261 section 19.3: > > When a tag is generated by a UA for insertion into a request or > response, it MUST be globally unique and cryptographically random > with at least 32 bits of randomness. Ah, I thought they were locally unique. I stand corrected. Would we want to use these as a session ID? What are the limitations? They are not re-used when a call is REFERred, AFAIK. Are there other limitations (e.g., 3xx)? The tags are also unbounded in length, which gives me some concern when trying to use it in a protocol like RSVP. > (Of course this is often violated, but then you can't lose too much > sleep over those who fail to follow the rules. If it hurts, don't do > it.) I think I've seen too many flows with rule violations ;-) Paul From bernard.aboba@gmail.com Wed Feb 2 09:52:45 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6528F3A6DAA for ; Wed, 2 Feb 2011 09:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vum5a-WCfOWu for ; Wed, 2 Feb 2011 09:52:41 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D3EA93A6D79 for ; Wed, 2 Feb 2011 09:52:40 -0800 (PST) Received: by wyf23 with SMTP id 23so240091wyf.31 for ; Wed, 02 Feb 2011 09:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RGWlzCbTDT/E4dYHcWYINeNCIB9Uq6ZXi7vDL8P5zIc=; b=Jemw54L8C3vuqKUL34jj3/oNrzqK/lMiY82bh32jSMsjO+utBQ9qwTE4Ez++bsfSXs oR7P0gzvn8mQ/tIu3saL32k98KfFVLnu2kiq4PZtqoFKXw8npQCfM9zdrFKqKf+u0M7d b/5d9QQXyf1Z9SURmYMSHDn3o8jBROtAB+wxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=K2nT4IRDoKSbWL3dfyQZq7j28vuhibk0IRwxsMSyblomZWSKN/5a4R1Z7+fjBnB9ba 8tKgw/owgJjRlL/qZgRINP4mpN62SE/VafB0BQomohpCnpG4lAOEYSOKkhXj+Z/vQDOx mutDHD7OwYe2sQfpCajBfwsDJhDHX399gwD+g= Received: by 10.216.155.205 with SMTP id j55mr2030879wek.90.1296669355070; Wed, 02 Feb 2011 09:55:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.27.21 with HTTP; Wed, 2 Feb 2011 09:55:33 -0800 (PST) In-Reply-To: References: <4D4425C8.2080705@jdrosen.net> <4D46DF69.6040503@skype.net> From: Bernard Aboba Date: Wed, 2 Feb 2011 09:55:33 -0800 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001485f8f0184cd512049b505c9b X-Mailman-Approved-At: Wed, 02 Feb 2011 10:26:34 -0800 Cc: DISPATCH list , rtc-web@alvestrand.no Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:52:45 -0000 --001485f8f0184cd512049b505c9b Content-Type: text/plain; charset=ISO-8859-1 With respect to b) one challenge is obtaining the IP addresses necessary to create the SDP offer. (see http://javascript.about.com/library/blip.htm). On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti wrote: > Great example. > > And just like Gmail uses an SMTP gateway to connect its own HTTP-based > protocol to the rest of the world, Gmail voice and video uses a XMPP gateway > to connect its HTTP-based signaling to other XMPP clients. Others in this > space have done similar things by implementing XMPP clients in Javascript. > > So I think we have existence proofs that this approach, in addition to > being extremely flexible, is entirely workable today. > > The two things that we need to specify are > a) the semantics of the signaling (i.e. the offer-answer mechanism that > both SIP and XMPP are patterned around) > b) the mechanism through which session offers and answers will be described > (e.g. some SDP-ish thing that is suitable for the web). > > a) seems rather straightforward. b) will likely be trickier - we need > something that can be mapped to SDP, for SIP gateways, but we probably want > it to be represented as JSON for benefit of web developers. So the challenge > becomes, what format can we define that can be unambiguously mapped to/from > SDP, but doesn't bring with it all of the baggage of SDP? > > --justin > > On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman < > matthew.kaufman@skype.net> wrote: > >> On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote: >> >>> >>> That said, even if one asks the question of whether it is a good idea for >>> us to pick something, I think the answer is no. The enormous benefit of the >>> web model is its ability for innovation and velocity. Standardization is not >>> needed for communications within the domain of the provider; new features >>> can be developed and deployed as quickly as they can be conceived. >>> >> >> Agreed. Consider the case of Gmail (or any other web-based email) >> >> Did every web browser on the planet need to be upgraded to speak IMAP or >> SMTP in order for Gmail to be implemented? No. >> >> Does the JavaScript that Gmail sends down to your browser in order to >> implement its UI need to be standardized among web email platforms? No. >> >> Does Google need to use the same JavaScript libraries and PHP back-end >> that SquirrelMail uses in order to implement a web email application? No. >> >> Can Google change that JavaScript tomorrow without breaking >> interoperability? Yes, and they probably will. >> >> But could Gmail be as successful without the worldwide SMTP infrastructure >> it ties in to? Probably not. >> >> I see the same situation here. A web browser with real-time communication >> capabilities will work in conjunction with a web site that serves up the >> HTML and JavaScript that makes up the calling application. For some >> applications, this will be sufficient. For others, one will want to >> implement SIP or XMPP/Jingle or something else in order to gateway these >> calls to other networks. The SIP implementation can live in the JavaScript, >> up in the web server, in a separate gateway, or any combination thereof. >> >> Matthew Kaufman >> >> _______________________________________________ >> RTC-Web mailing list >> RTC-Web@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtc-web >> > > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > > --001485f8f0184cd512049b505c9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With respect to b) one challenge is obtaining the IP addresses necessary to= create the SDP offer.=A0=A0 (see http://javascript.about.com/library/blip.htm ).=A0
=
On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <juberti@google.com> wrote:
Great example.=A0

And just like Gmail uses an SMTP gatew= ay to connect its own HTTP-based protocol to the rest of the world, Gmail v= oice and video uses a XMPP gateway to connect its HTTP-based signaling to o= ther XMPP clients. Others in this space have done similar things by impleme= nting XMPP clients in Javascript.

So I think we have existence proofs that this approach,= in addition to being extremely flexible, is entirely workable today.
=

The two things that we need to specify are
a) the semantics of the signaling (i.e. the offer-answer mechanism that bot= h SIP and XMPP are patterned around)
b) the mechanism through whi= ch session offers and answers will be described (e.g. some SDP-ish thing th= at is suitable for the web).

a) seems rather straightforward. b) will likely be tric= kier - we need something that can be mapped to SDP, for SIP gateways, but w= e probably want it to be represented as JSON for benefit of web developers.= So the challenge becomes, what format can we define that can be unambiguou= sly mapped to/from SDP, but doesn't bring with it all of the baggage of= SDP?

--justin

On Mon,= Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.n= et> wrote:
On 1/29/2011= 6:35 AM, Jonathan Rosenberg wrote:

That said, even if one asks the question of whether it is a good idea for u= s to pick something, I think the answer is no. The enormous benefit of the = web model is its ability for innovation and velocity. Standardization is no= t needed for communications within the domain of the provider; new features= can be developed and deployed as quickly as they can be conceived.

Agreed. Consider the case of Gmail (or any other web-based email)

Did every web browser on the planet need to be upgraded to speak IMAP or SM= TP in order for Gmail to be implemented? No.

Does the JavaScript that Gmail sends down to your browser in order to imple= ment its UI need to be standardized among web email platforms? No.

Does Google need to use the same JavaScript libraries and PHP back-end that= SquirrelMail uses in order to implement a web email application? No.

Can Google change that JavaScript tomorrow without breaking interoperabilit= y? Yes, and they probably will.

But could Gmail be as successful without the worldwide SMTP infrastructure = it ties in to? Probably not.

I see the same situation here. A web browser with real-time communication c= apabilities will work in conjunction with a web site that serves up the HTM= L and JavaScript that makes up the calling application. For some applicatio= ns, this will be sufficient. For others, one will want to implement SIP or = XMPP/Jingle or something else in order to gateway these calls to other netw= orks. The SIP implementation can live in the JavaScript, up in the web serv= er, in a separate gateway, or any combination thereof.

Matthew Kaufman

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestra= nd.no
http://www.alvestrand.no/mailman/listinfo/rtc-web


_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web


--001485f8f0184cd512049b505c9b-- From pkyzivat@cisco.com Wed Feb 2 10:29:19 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8893A6DD4 for ; Wed, 2 Feb 2011 10:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnEYbvBkJz9c for ; Wed, 2 Feb 2011 10:29:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 58A233A6DD9 for ; Wed, 2 Feb 2011 10:29:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO4xSU1AZnwN/2dsb2JhbAClHHOgXZsmhVMEhHiGaYMq Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2011 18:32:38 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p12IWb9I006792; Wed, 2 Feb 2011 18:32:38 GMT Message-ID: <4D49A345.50004@cisco.com> Date: Wed, 02 Feb 2011 13:32:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Paul E. Jones" References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <4D46DF4E.8030805@cisco.com> <024401cbc262$a9a641e0$fcf2c5a0$@packetizer.com> <4D48AFAA.7010709@cisco.com> <044a01cbc2fe$a58cf030$f0a6d090$@packetizer.com> In-Reply-To: <044a01cbc2fe$a58cf030$f0a6d090$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:29:19 -0000 On 2/2/2011 12:28 PM, Paul E. Jones wrote: > Paul, > >> On 2/1/2011 5:52 PM, Paul E. Jones wrote: >>> Paul, >>> >>>> - This seems much like a dialog id, which includes a to-tag and >>>> from-tag. The UUIDs you describe are much like the tags. >>> >>> Yes, similar, though a tag is not globally unique. >> >> au contraire - From 3261 section 19.3: >> >> When a tag is generated by a UA for insertion into a request or >> response, it MUST be globally unique and cryptographically random >> with at least 32 bits of randomness. > > Ah, I thought they were locally unique. I stand corrected. Would we want > to use these as a session ID? What are the limitations? They are not > re-used when a call is REFERred, AFAIK. Are there other limitations (e.g., > 3xx)? The tags are also unbounded in length, which gives me some concern > when trying to use it in a protocol like RSVP. While the similarities are striking, so are the differences. The text *requires* that the tags be unique in cases where you want your ID to be non-unique. It might be helpful to specify your ids so that the same values could be used as tags too. Then when appropriate, the tag and the id could be the same - being different only when to *point* is to reuse an old one. Thanks, Paul (K) From henry.sinnreich@gmail.com Wed Feb 2 11:21:03 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020A03A6CDC for ; Wed, 2 Feb 2011 11:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc+9yQQkh4t4 for ; Wed, 2 Feb 2011 11:20:55 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AE3413A6D79 for ; Wed, 2 Feb 2011 11:20:54 -0800 (PST) Received: by gwb20 with SMTP id 20so159302gwb.31 for ; Wed, 02 Feb 2011 11:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type; bh=I0IFYuEH2LYiovL6Ik2wJnDQ9m/8BCx7ZlAV6tKH8n4=; b=n479vyGX2XkrlEQ5GiZ9+FQNqyPZ6yeQE6USiSJrLZFXHZRgfveAepXMp2leyMXNBx 9UPZOHTQV6NnTETxWq8HNugFcPNNC5juplgMRm43zNiJCyR1sy3zSC4AhYhxpM7hcoU7 ah+/8hAS8/G8RHCQN/Sr/yzzTMuD4gq+aYPtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=fUtAAAvqh1ch0kHnGI0b0m6WHf8gMdJgoA+YQFeSxAyqSEL7uPecKayQYtWrOn8yQQ /zQPgBxEIV65ggalsT4s+Yj7o3tc+/rrn41Nk9Wj3Dk9JGNf8hPfzE4ihUdAJVVnDt8o KCVRhp5Nfbo1Kljel9i+Eelc3/oiKHotcJ1Bg= Received: by 10.100.232.1 with SMTP id e1mr6211607anh.13.1296674352060; Wed, 02 Feb 2011 11:19:12 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id p14sm6985983ank.14.2011.02.02.11.19.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 11:19:10 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Feb 2011 13:19:08 -0600 From: Henry Sinnreich To: Bernard Aboba , Justin Uberti Message-ID: Thread-Topic: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? Thread-Index: AcvDDhBDL3zMQ1q2g0CMQk5QCTMJTw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379497549_2007001" Cc: rtc-web@alvestrand.no, DISPATCH list , Joerg Ott Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:21:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379497549_2007001 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? http://www.rfc-editor.org/rfc/rfc3424.txt =B3...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.=B2 Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07 Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities= . Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure. Or are the no =B3sound technical approaches=B2 available at all? Thanks, Henry On 2/2/11 11:55 AM, "Bernard Aboba" wrote: > With respect to b) one challenge is obtaining the IP addresses necessary = to > create the SDP offer.=A0=A0 (see http://javascript.about.com/library/blip.htm= ).=A0 >=20 > On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti wrote= : >> Great example.=A0 >>=20 >> And just like Gmail uses an SMTP gateway to connect its own HTTP-based >> protocol to the rest of the world, Gmail voice and video uses a XMPP gat= eway >> to connect its HTTP-based signaling to other XMPP clients. Others in thi= s >> space have done similar things by implementing XMPP clients in Javascrip= t. >>=20 >> So I think we have existence proofs that this approach, in addition to b= eing >> extremely flexible, is entirely workable today. >>=20 >> The two things that we need to specify are >> a) the semantics of the signaling (i.e. the offer-answer mechanism that = both >> SIP and XMPP are patterned around) >> b) the mechanism through which session offers and answers will be descri= bed >> (e.g. some SDP-ish thing that is suitable for the web). >>=20 >> a) seems rather straightforward. b) will likely be trickier - we need >> something that can be mapped to SDP, for SIP gateways, but we probably w= ant >> it to be represented as JSON for benefit of web developers. So the chall= enge >> becomes, what format can we define that can be unambiguously mapped to/f= rom >> SDP, but doesn't bring with it all of the baggage of SDP? >>=20 >> --justin >>=20 >> On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman >> wrote: >>> On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote: >>>>=20 >>>> That said, even if one asks the question of whether it is a good idea = for >>>> us to pick something, I think the answer is no. The enormous benefit o= f the >>>> web model is its ability for innovation and velocity. Standardization = is >>>> not needed for communications within the domain of the provider; new >>>> features can be developed and deployed as quickly as they can be conce= ived. >>>=20 >>> Agreed. Consider the case of Gmail (or any other web-based email) >>>=20 >>> Did every web browser on the planet need to be upgraded to speak IMAP o= r >>> SMTP in order for Gmail to be implemented? No. >>>=20 >>> Does the JavaScript that Gmail sends down to your browser in order to >>> implement its UI need to be standardized among web email platforms? No. >>>=20 >>> Does Google need to use the same JavaScript libraries and PHP back-end = that >>> SquirrelMail uses in order to implement a web email application? No. >>>=20 >>> Can Google change that JavaScript tomorrow without breaking >>> interoperability? Yes, and they probably will. >>>=20 >>> But could Gmail be as successful without the worldwide SMTP infrastruct= ure >>> it ties in to? Probably not. >>>=20 >>> I see the same situation here. A web browser with real-time communicati= on >>> capabilities will work in conjunction with a web site that serves up th= e >>> HTML and JavaScript that makes up the calling application. For some >>> applications, this will be sufficient. For others, one will want to >>> implement SIP or XMPP/Jingle or something else in order to gateway thes= e >>> calls to other networks. The SIP implementation can live in the JavaScr= ipt, >>> up in the web server, in a separate gateway, or any combination thereof= . >>>=20 >>> Matthew Kaufman >>>=20 >>> _______________________________________________ >>> RTC-Web mailing list >>> RTC-Web@alvestrand.no >>> http://www.alvestrand.no/mailman/listinfo/rtc-web >>=20 >>=20 >> _______________________________________________ >> RTC-Web mailing list >> RTC-Web@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtc-web >>=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --B_3379497549_2007001 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?= Is there some understanding on the list on how the IP addresses in SDP can= be reconciled with the USAF RFC 3424?
http://www.rfc-editor.o= rg/rfc/rfc3424.txt

“...= a process whereby some
   originating process attempts to determine or fix the addr= ess (and
   port) by which it is known - e.g. to be able to use addre= ss data in
   the protocol exchange, or to advertise a public address f= rom which it
   will receive connections.
There are only heuristics and workarounds to attempt to achieve this
   effect; there is no 100% solution.  Since NATs may a= lso dynamically
   reclaim or readjust translations, "keep-alive" = and periodic re-
   polling may be required.  Use of these workarounds M= UST be considered
   transitional in IETF protocols, and a better architectura= l solution
   is being sought.  The explicit intention is to depre= cate any such
   workarounds when sound technical approaches are available= .”

Obviously there is much more dead stuff in SDP besides using the misleading= IP addresses, but this seems to be a deep architectural flaw.
There were some early attempts to do SDPng and we know today much more:
http://tool= s.ietf.org/html/draft-ietf-mmusic-sdpng-07

Why not replace SDP, since it deals only with a/v codec negotiation with a = more general, standards based metadata approach?
For example including Web conferencing displays and UI control capabilities= .
Of course such a new approach must be easily mapped to the existing global = SIP VoIP infrastructure.

Or are the no  “sound technical approaches” available at all?

Thanks, Henry


On 2/2/11 11:55 AM, "Bernard Aboba" <bernard.aboba@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>With respect to b) one challenge is obtaining th= e IP addresses necessary to create the SDP offer.=A0=A0 (see http://javascript.about.com/library/blip= .htm ).=A0

On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <juberti@google.com> wrote:
<= SPAN STYLE=3D'font-size:13pt'>Great example.=A0

And just like Gmail uses an SMTP gateway to connect its own HTTP-based prot= ocol to the rest of the world, Gmail voice and video uses a XMPP gateway to = connect its HTTP-based signaling to other XMPP clients. Others in this space= have done similar things by implementing XMPP clients in Javascript.

So I think we have existence proofs that this approach, in addition to bein= g extremely flexible, is entirely workable today.

The two things that we need to specify are
a) the semantics of the signaling (i.e. the offer-answer mechanism that bot= h SIP and XMPP are patterned around)
b) the mechanism through which session offers and answers will be described= (e.g. some SDP-ish thing that is suitable for the web).

a) seems rather straightforward. b) will likely be trickier - we need somet= hing that can be mapped to SDP, for SIP gateways, but we probably want it to= be represented as JSON for benefit of web developers. So the challenge beco= mes, what format can we define that can be unambiguously mapped to/from SDP,= but doesn't bring with it all of the baggage of SDP?

--justin

On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
<= SPAN STYLE=3D'font-size:13pt'>On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:<= BR>
<= SPAN STYLE=3D'font-size:13pt'>
That said, even if one asks the question of whether it is a good idea for u= s to pick something, I think the answer is no. The enormous benefit of the w= eb model is its ability for innovation and velocity. Standardization is not = needed for communications within the domain of the provider; new features ca= n be developed and deployed as quickly as they can be conceived.
=
Agreed. Consider the case of Gmail (or any other web-based email)

Did every web browser on the planet need to be upgraded to speak IMAP or SM= TP in order for Gmail to be implemented? No.

Does the JavaScript that Gmail sends down to your browser in order to imple= ment its UI need to be standardized among web email platforms? No.

Does Google need to use the same JavaScript libraries and PHP back-end that= SquirrelMail uses in order to implement a web email application? No.

Can Google change that JavaScript tomorrow without breaking interoperabilit= y? Yes, and they probably will.

But could Gmail be as successful without the worldwide SMTP infrastructure = it ties in to? Probably not.

I see the same situation here. A web browser with real-time communication c= apabilities will work in conjunction with a web site that serves up the HTML= and JavaScript that makes up the calling application. For some applications= , this will be sufficient. For others, one will want to implement SIP or XMP= P/Jingle or something else in order to gateway these calls to other networks= . The SIP implementation can live in the JavaScript, up in the web server, i= n a separate gateway, or any combination thereof.

Matthew Kaufman

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alve= strand.no/mailman/listinfo/rtc-web
=

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alve= strand.no/mailman/listinfo/rtc-web

=

__________________________= _____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
--B_3379497549_2007001-- From singer@apple.com Wed Feb 2 11:33:01 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE50E3A6C41 for ; Wed, 2 Feb 2011 11:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.4 X-Spam-Level: X-Spam-Status: No, score=-106.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y355hMlwaFn for ; Wed, 2 Feb 2011 11:33:00 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id D26E03A6BEE for ; Wed, 2 Feb 2011 11:33:00 -0800 (PST) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 13733CFAFC16 for ; Wed, 2 Feb 2011 11:36:21 -0800 (PST) X-AuditID: 11807135-b7cf8ae0000007ed-61-4d49b2344fd3 Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay12.apple.com (Apple SCV relay) with SMTP id 14.5B.02029.432B94D4; Wed, 2 Feb 2011 11:36:21 -0800 (PST) From: David Singer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 11:36:20 -0800 References: <20110202192623.BFFB03A6C41@core3.amsl.com> To: dispatch@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Fwd: New Version Notification for draft-gellens-mime-bucket-bis-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:33:01 -0000 Friends I have been working on a minor update to RFC 4281 (the 'buckets RFC' as = it is sometimes known), This does various minor updates: * clarify what mime types it can be used with * integrate the text from 3GPP on handling AVC (aka H.264) * extend that to clarify the handling of SVC and MVC * add the profiles parameter (file compatibility indicators) * other minor cleanups (e.g. case corrections) I am unsure how to get this update proceeding along towards RFC status, = or who at the IETF could/should review it. Guidance from this group would be welcome. Thanks! Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 2, 2011 11:26:23 PST > To: singer@apple.com > Cc: randy@qualcomm.com, Per.Frojdh@ericsson.com > Subject: New Version Notification for draft-gellens-mime-bucket-bis-02 >=20 >=20 > A new version of I-D, draft-gellens-mime-bucket-bis-02.txt has been = successfully submitted by David Singer and posted to the IETF = repository. >=20 > Filename: draft-gellens-mime-bucket-bis > Revision: 02 > Title: The Codecs and Profiles Parameters for "Bucket" = Media Types > Creation_date: 2011-02-01 > WG ID: Independent Submission > Number_of_pages: 23 >=20 > Abstract: > Several MIME type/subtype combinations exist that can contain > different media formats. A receiving agent thus needs to examine the > details of such media content to determine if the specific elements > can be rendered given an available set of codecs. Especially when > the end system has limited resources, or the connection to the end > system has limited bandwidth, it would be helpful to know from the > Content-Type alone if the content can be rendered. >=20 > This document specifies two parameters, "codecs" and "profiles", > which are used with various MIME types or type/subtype combinations > to allow for unambiguous specification of the codecs and/or profiles > employed by the media formats contained within. >=20 > By labeling content with the specific codecs indicated to render the > contained media, receiving systems can determine if the codecs are > supported by the end system, and if not, can take appropriate action > (such as rejecting the content, sending notification of the > situation, transcoding the content to a supported type, fetching and > installing the required codecs, further inspection to determine if it > will be sufficient to support a subset of the indicated codecs, etc.) >=20 > Similarly, the profiles can provide an overall indication, to the > receiver, of the specifications with which the content complies. The > receiver may be able to work out the extent to which it can handle > and render the content by examining to see which of the declared > profiles it supports, and what they mean. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 David Singer Multimedia and Software Standards, Apple Inc. From ricky.kaura@samsung.com Wed Feb 2 11:37:11 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125273A6C41 for ; Wed, 2 Feb 2011 11:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhJFkph2EC1e for ; Wed, 2 Feb 2011 11:37:03 -0800 (PST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by core3.amsl.com (Postfix) with ESMTP id 45A363A6C0B for ; Wed, 2 Feb 2011 11:37:03 -0800 (PST) Received: from eu_spt1 (mailout2.w1.samsung.com [210.118.77.12]) by mailout2.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0LG0002689B9D7@mailout2.w1.samsung.com> for dispatch@ietf.org; Wed, 02 Feb 2011 19:40:21 +0000 (GMT) Received: from dc2.seri.co.uk ([106.1.8.33]) by spt1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0LG000F0D9B9CO@spt1.w1.samsung.com> for dispatch@ietf.org; Wed, 02 Feb 2011 19:40:21 +0000 (GMT) Date: Wed, 02 Feb 2011 19:40:18 +0000 From: Ricky Kaura To: dispatch@ietf.org Message-id: <454CFC84C5CDDD46AC9CF438F0CFDC7D0265A66E@dc2.seri.co.uk> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="Boundary_(ID_g3sXcHaQUHysUU5cGwezfg)" Content-class: urn:content-classes:message Thread-topic: Re: [dispatch] Revision ofdraft-allen-dispatch-imei-urn-as-instanceid Thread-index: AcvDEQVMaNmKnHSTS5SkPTmpKwo+6w== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [dispatch] Revision ofdraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:43:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_g3sXcHaQUHysUU5cGwezfg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, I work for Samsung and attend 3GPP CT1/CT meetings and GSM Association (GSMA) Interworking, Roaming Expert Group (IREG), Roaming in LTE (RiLTE) subgroup meetings. I would like to express my support of draft-montemurro-gsma-imei-urn and the associated draft-allen-dispatch-imei-urn-as-instanceid for the following reasons: * 3GPP has specified IMS emergency calls over LTE and GPRS in 3GPP Release 9. When originating an emergency call over these access technologies, it is required to include the IMEI-URN as the instance ID in the "+sip.instance" header field parameter in the Contact header of the SIP INVITE (see 3GPP TS 23.237 and 3GPP TS 24.237). This is required in order to support access transfer of emergency calls from the PS domain to the CS domain. The IMEI is used at the Emergency Access Transfer Function (EATF) to correlate the original IMS emergency session with the session transfer request that was initiated from the MSC (Mobile services Switching Centre) upon handover to the CS domain. Specifically, in the case of limited service mode, where an IMS registration does not necessarily occur, the IMEI is the only available identifier that can be used to allow the EATF to correlate the source and target access legs. * Recently in 3GPP TS 24.229, a CR was approved which states that if a UE has an IMEI available, it shall always include the IMEI in the "+sip.instance" header field parameter in the Contact header of the SIP Register. The requirement for the inclusion of the IMEI came from GSMA and is included in PRD IR.92. IR.92 is a user-to-network (UNI) profile of the key 3GPP IMS specifications for voice and SMS over LTE and has been developed in GSMA IREG RiLTE by a number of operators, network vendors and device manufacturers. The requirement to include the IMEI (if available) in the SIP Register is to support operator requirements for the IMS network to perform an IMEI check when the UE is IMS registered, as stated in the Stage 1 requirements in 3GPP TS 22.016 (section 5). * 3GPP developed a feature in Release 8 called "IMS Centralised Services" (ICS) (see TS 23.292 and TS 24.292) which allows a user to have a consistent set of features independent of whether the UE is on PS access or CS access. 3GPP have defined the MSC server enhanced for ICS to control voice sessions set up using circuit bearers. To enabled this feature, the MSC server performs a SIP registration on behalf of the UE when the UE is in the circuit domain. However, a registration for the user may also exist in the PS domain. The IMEI included as the Instance Id is used as a way of allowing the IMS network to identify that the SIP registrations below to the same UE and to allow correct handling of session establishment requests using GRUU. * The ICS feature in 3GPP also allows the use of specialised functionality on the UE (i.e. an ICS client). Such a UE is called an ICS UE. When the ICS UE performs a SIP registration, it identifies itself by using the IMEI and includes this as the Instance Id in the SIP REGISTER. When used in conjunction with an MSC server enhanced for ICS, the application server in IMS can use the GRUU to correlate the SIP signalling that comes directly from the UE with the SIP signalling that comes via the MSC server when the ICE UE initiates an ICS session. In summary, these drafts are very important for the support of key features in 3GPP. I request that this work is progressed as quickly as possible in IETF. Regards, Ricky Kaura. Principal Standards Engineer Standands and Industry Affairs (SIA) Samsung Electronics Research Institute Tel: +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: +44 (0) 1784 428 610 Email: ricky.kaura@samsung.com ; Skype: rickykaura; Yahoo: rkaura1969 Samsung Electronics (UK) Limited Registered number: 03086621 Registered address: Communications house, South Street, Staines, Middlesex TW18 4QE. --Boundary_(ID_g3sXcHaQUHysUU5cGwezfg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Dear all,

 

I work for Samsung and attend 3GPP CT1/CT meetings and GSM Association = (GSMA) Interworking, Roaming Expert Group (IREG), Roaming in LTE (RiLTE) = subgroup meetings.

 

I would like to express my support of draft-montemurro-gsma-imei-urn = and the associated draft-allen-dispatch-imei-urn-as-instanceid for the following = reasons:

 

·         3GPP has specified IMS emergency calls over LTE and GPRS in 3GPP Release 9. = When originating an emergency call over these access technologies, it is = required to include the IMEI-URN as the instance ID in the "+sip.instance" header field parameter in the Contact header of the SIP INVITE (see 3GPP TS 23.237 = and 3GPP TS 24.237). This is required in order to support access transfer of = emergency calls from the PS domain to the CS domain. The IMEI is used at the = Emergency Access Transfer Function (EATF) to correlate the original IMS emergency = session with the session transfer request that was initiated from the MSC = (Mobile services Switching Centre) upon handover to the CS domain. Specifically, = in the case of limited service mode, where an IMS registration does not = necessarily occur, the IMEI is the only available identifier that can be used to allow the = EATF to correlate the source and target access legs.

 

·         Recently in 3GPP TS 24.229, a CR was approved which states that if a UE has an = IMEI available, it shall always include the IMEI in the "+sip.in= stance" header field parameter in the Contact header of the SIP Register. The requirement for the inclusion of the IMEI came from GSMA and is included = in PRD IR.92. IR.92 is a user-to-network (UNI) profile of the key 3GPP IMS specifications for voice and SMS over LTE and has been developed in GSMA = IREG RiLTE by a number of operators, network vendors and device manufacturers. The requirement to include the IMEI (if available) in the SIP Register is to support operator requirements for the IMS network to perform an IMEI = check when the UE is IMS registered, as stated in the Stage 1 requirements in 3GPP = TS 22.016 (section 5).  

 

·         3GPP developed a feature in Release 8 called “IMS Centralised = Services” (ICS) (see TS 23.292 and TS 24.292) which allows a user to have a = consistent set of features independent of whether the UE is on PS access or CS = access. 3GPP have defined the MSC server enhanced for ICS to control voice sessions = set up using circuit bearers. To enabled this feature, the MSC server performs = a SIP registration on behalf of the UE when the UE is in the circuit domain. = However, a registration for the user may also exist in the PS domain. The IMEI = included as the Instance Id is used as a way of allowing the IMS network to = identify that the SIP registrations below to the same UE and to allow correct = handling of session establishment requests using GRUU.

 

·         The ICS feature in 3GPP also allows the use of specialised functionality on = the UE (i.e. an ICS client). Such a UE is called an ICS UE. When the ICS UE = performs a SIP registration, it identifies itself by using the IMEI and includes = this as the Instance Id in the SIP REGISTER. When used in conjunction with an = MSC server enhanced for ICS, the application server in IMS can use the GRUU = to correlate the SIP signalling that comes directly from the UE with the = SIP signalling that comes via the MSC server when the ICE UE initiates an = ICS session.

 

In summary, these drafts are very important for the support of key features = in 3GPP.

 

I request that this work is progressed as quickly as possible in IETF. =

 

 

Regards,=

 

Ricky Kaura.

 

Principal Standards Engineer

Standands and Industry Affairs (SIA)

Samsung Electronics Research Institute

Tel:   +44 (0) 1784 428 600 = Ext 635; Mob: +44 (0) 7760 761514; Fax: +44 (0) 1784 428 610

Email: ricky.kaura@samsung.com; Skype: = rickykaura; Yahoo: rkaura1969

Samsung = Electronics (UK) Limited

Registered = number: 03086621

Registered = address: Communications house, South Street, Staines, Middlesex TW18 = 4QE.

 

--Boundary_(ID_g3sXcHaQUHysUU5cGwezfg)-- From D.Malas@cablelabs.com Wed Feb 2 12:21:12 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411793A6D43 for ; Wed, 2 Feb 2011 12:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.313 X-Spam-Level: X-Spam-Status: No, score=-100.313 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T6pdzN0ukla for ; Wed, 2 Feb 2011 12:21:11 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CE14E3A6D07 for ; Wed, 2 Feb 2011 12:21:10 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p12KOROu021484; Wed, 2 Feb 2011 13:24:27 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 2 Feb 2011 13:24:27 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 2 Feb 2011 13:24:28 -0700 From: Daryl Malas To: Christer Holmberg , "dispatch@ietf.org" Date: Wed, 2 Feb 2011 13:24:24 -0700 Thread-Topic: [dispatch] Basic Telephony SIP Interconnect Guideline Draft Thread-Index: AcvDFzBfpaeIitkrTyCsZFGqAn929A== Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058519442D6074@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: David Hancock Subject: Re: [dispatch] Basic Telephony SIP Interconnect Guideline Draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:21:12 -0000 Christer, David Hancock provided an analysis of how this draft compares to other industry work in a previous SPEERMINT mailing list discussion. I have recopied this below for reference. Note: replace the "work done in SPEERMINT" as this draft. Here is a link to the original email: http://www.ietf.org/mail-archive/web/speermint/current/msg02635.html Regards, Daryl =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BEGIN Interconnect Standards = Compare =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D EXECUTIVE SUMMARY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here is the list of standards, and my conclusions as to whether each standard overlaps or duplicates the interconnect work being done in SPEERMINT. 3GPP IMS:=20 - 3GPP TS 29.165 Inter-IMS Network to Network Interface (Sept 2009) - Conclusion: does overlap to a certain extent, but is too IMS-centric to be viewed as a interface standard for the entire industry ITU-T Study Group 11: - Q.3401 - NGN NNI signalling profile (March 2007) - Conclusion: does overlap to a certain extent, but too broad and high-level to meet the goals set out by the SPEERMINT interconnect guidelines draft (i.e., ITU spec is more a list of SIP extensions supported on the interface, rather than the SPEERMINT draft which provides more focused and detailed procedures to resolve common interworking issues) i3 Forum: - IP international interconnections for voice and other related services (June 2009) - Conclusion: doesn't duplicate the SPEERMINT draft. This i3 spec provides very high-level requirements for the interface between two international IP carriers. GSM Association: - Inter-Service Provider IP Backbone Guidelines (June 2008) - Conclusion: doesn't duplicate the SPEERMINT draft. Instead of direct peering, the GSM spec defines an indirect peering model where each SSP has a single connection to a common "Inter-Service Provider IP backbone". This backbone acts a hub that indirectly connects all peering SSPs. Very light on SIP interworking. ETSI - ETSI SR 00008-NGN-R3 and ETSI DTR/TISPAN-07043-NGN-R3 I didn't include these documents in the comparison, mainly because this area seems to be still in early stages. The SR 00008-NGN document references a number of other ETSI documents, including the ETSI version of 3GPP TS 24.229 (the IMS base SIP/SDP spec). DTR/TISPAN-07043 (according to the title) is about security, which is currently out-of-scope for the SPEERMINT draft. My assumption at this point is that the SSP SIP interworking procedures for ETSI are or will-be harmonized with 3GPP/IMS. ATIS Unfortunately, I don't have a copy of the ATIS interworking spec, so didn't include ATIS in the comparison. Would appreciate it if someone who has access to these documents could provide info on this. DETAILED ANALYSIS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following is a more detailed comparison among these different standards. 3GPP TS 29.165 - Inter-IMS Network to Network Interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Purpose: -------- To collect all the II-NNI related requirements spread across multiple IMS specifications into a single document. 29.165 consists primarily of NNI-impacting references to other IMS specs, such as... Numbering, addressing & identification --> 23.003 Multi-Media Telephony (MMTEL) Services --> 24.173 Base (app-agnostic) SIP procedures --> 24.229 Media & Codecs --> 26.114 IP Version Interworking --> 29.162 Call Charging --> 32.260 Security --> 33.210 Reference Architecture: ----------------------- +--29.165 defines this SIP/RTP interface | | +---------------------+ | +-----------------+ | IMS Network | | | IMS Network | | | V | | | IBCF-------SIP---------IBCF | | x-CSCFs,etc | | | | | | TrGW-------RTP---------TrGW | | | | | +---------------------+ +-----------------+ Scope:=20 ------ 29.165 is similar to the SPEERMINT draft in that it covers signaling (SIP & SDP) and media (RTP) requirements at NNI. However, 29.165 is much broader than the SPEERMINT interconnect draft; e.g., - mandates mandatory/optional NNI support for an exhaustive number of SIP extensions (~80) - mandates procedures for a large number of voice telephony features (~20) Conclusion: ----------- 29.165 does overlap and duplicate the SPEERMINT guidelines to a certain extent. However, it is much broader (more extensions, more services) than the SPEERMINT document, and more IMS-centric, and therefore it would probably not serve as general industry interface specification. Some examples of IMS-specific procedures/mechanism include: a) Private headers unique to IMS such as P-Access-Network P-Asserted-Service P-Charging-Vector P-Charging-Function-Addresses P-Profile-Key P-Private-Network-Indication P-Served-User b) Use-cases unique to IMS, such as... In IMS roaming scenarios a roaming UE in a visited network registers with its home network via the NNI interface. As a result, procedures that normally show up only on a UNI interface such as registration and visual message waiting indication can appear on the NNI interface. c) IMS-specific mechanisms e.g., MMTEL Service URN urn:urn-7:3gpp-service.ims.icsi.mmtel ITU-T Q.3401 (03/2007) Signaling requirements and protocols for the NGN - Service and session control protocols =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Purpose: -------- To define a common interface profile between peering SSPs. Reference Architecture: ----------------------- +--Q.3401 defines this SIP/RTP interface | | +----------+ | +---------+ | | V | | | SSPa |----SIP-------| SSPb | | | | | | |----RTP-------| | +----------+ +---------+ Scope: ------ Similar to the SPEERMING guidelines -- define SIP/RTP guidelines for support of basic voice services. Level of Detail: ---------------- Much broader and less detailed than SPEERMINT interconnect guidelines. - contains a few high-level guidelines - a long list (~40) of mandatory/optional RFCs - a high-level profile of RFC3261 that... - lists supported methods & headers - identifies minor divergences from RFC3261 Conclusion: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Does not contain the level of detail of the SPEERMINT interconnect guidelines. ITU Q.3401 is more a list of SIP extensions that can appear on the NNI, in contrast to the SPEERMINT draft which focuses on providing more detail on a narrower set of topics, sufficient to resolve a bounded set of common interworking issues. i3 Forum has two documents... IP international interconnections for voice and related services (V 1.0) June 2009 and Technical Interconnection Model for International Voice Services (Release 2.0) May 2009 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Purpose:=20 -------- Describes interworking interface between international carrier networks connecting two domestic service provider networks Reference Architecture: ----------------------- +-- describes this SIP/RTP interface | Country-X | Country-Y +------------+ | +------------+ | Domestic | +-----------+ V +-----------+ | Domestic | | TDM/VoIP |----| Carrier-A |------| Carrier-B |----| TDM/VoIP | | Provider-A | +-----------+ +-----------+ | Provider-B | | | | | +------------+ +------------+ Scope: ------ - Describes SIP & RTP interface between international carriers - Describe layers below SIP (e.g., IP, physical) - In addition to SIP, describes procedures for signaling ISUP & TCAP over IP - Defines voice quality metrics measures - Defines charging requirements, and accounting data Level of detail: ---------------- Detail much lower than SPEERMINT interconnect guidelines - Defines high-level profile of RFC 3261 - Lists mandatory SIP methods and headers with no additional detail - Aside from application of ring-back tone, does not describe any procedures or call flows Conclusion: ----------- These i3 Forum documents augment rather than replace/duplicate the SPEERMINT interconnect guidelines, since they... - contain much less detail w.r.t. SIP procedures - target a different problem space (international carrier, more TDM/SS7 focused) GSM - Inter-Service Provider IP Backbone Guidelines =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Purpose:=20 -------- To define an architecture built around a common Inter-Service Provider IP Backbone that enables different SSPs to easily peer with each other. Reference Architecture: ----------------------- +-- GSM guidelines describe this entity | | V +------------+ +-------------+ | SSPb | +------------+ | |-----| | | SSPa |----| Inter-SP | +------------+ +------------+ | IP Backbone | | | +------------+ | |-----| SSPc | +-------------+ | | +------------+ This document solves the peering problem by defining an active entity (the Inter-SP IP backbone) at the peering interface that takes care of the complexities of establishing multiple peering relationships. Using this arrangement, a single SSP can reach many peer SSPs via a single connection to the Inter-SP IP Backbone. Scope: ------ Describes the architecture, and basic connectivity requirements to make it work. Very thin on SIP requirements. Conclusion: ---------- Does not overlap/replace the SPEERMINT interconnect guidelines. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D END Interconnect Standards Co= mpare =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 2/2/11 4:40 AM, "Christer Holmberg" wrote: > >Hi, > >In addition, at least ITU-T and 3GPP also have interconnect >specifications. > >Regarding THIS draft, I am a little confused about that fact that it >describes UA procedures, e.g. how a UA shall handle forking. I don't see >what that has to do with interconnect. > >(I DO agree that it would be good to have common forking procedures in >general, but that's another story :) > >Having said that, specifying that forking shall be supported over >interconnect could be useful. > >...unless, of course, you want to deploy SBCs at the interconnect point >in order to handle forked sessions :) > >Regards, > >Christer > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John >> Sent: 2. helmikuuta 2011 13:13 >> To: dispatch@ietf.org >> Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft >>=20 >> http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html >>=20 >> If this is just profiling work, perhaps the SIP Forum would >> be a better venue. >>=20 >> John >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Wed Feb 2 22:29:48 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5841E3A67AD for ; Wed, 2 Feb 2011 22:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xyb1PTw4xNo for ; Wed, 2 Feb 2011 22:29:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id ACE4B3A677C for ; Wed, 2 Feb 2011 22:29:46 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p136WvHK016324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Feb 2011 01:33:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1296714783; bh=gTiTYgUTonkxeAKR0a6wyFIOQfacKbgbSU8kXqjlcjs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tAvHSlT4kk3X7t/57eJIBGPnDMZB7lhw2XogtPIA4FMG4Qi5qBftJPNJ++ViHTG2h KuRxE8VBWBTAvKh1sFPWFn0cIPnF63dxzuq0ATuwBRzg4EptkH3Zm64RdeQZ0bOrvG c2ecy95NbOvsTBv4SAGlHaSG6EONO76ubrTpJL4Y= From: "Paul E. Jones" To: "'Peter Musgrave'" References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> In-Reply-To: Date: Thu, 3 Feb 2011 01:32:40 -0500 Message-ID: <051101cbc36c$2b4fde90$81ef9bb0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA7Fy1vbvX3nVJZeZhtnW6LVnUIgHIr7ark3YR5GA= Content-Language: en-us Cc: 'DISPATCH list' Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 06:29:48 -0000 Peter, The idea as currently presented is that A sends its UUID to B and B sends its UUID to A. A and B both compose the Session-ID locally for whatever purpose they might have for it. So, in debugging, you would look at the INVITE that goes out. There may be multiple messages coming back due to forking. One would use current approaches (e.g., Call-ID, tags) to relate a response with an initial request. While we didn't propose extracting the Session-ID directly from any single message, it can be constructed and used in logging, recording, etc. We could insert a UUID in the INVITE and a complete Session-ID in response messages. I have no objection to describing the procedure in that way, but I'm not sure how much value there is in doing that. It might make it easier to see the Session-ID more readily, but any application that might need to use it would already know one UUID already. The uses of the Session-ID are several, including functions like logging, recording, and relating media flows to sessions (e.g., use in RTCP and RSVP). The reason for not using a single UUID is that, in real systems, call legs get joined/spliced/diced/chopped. A might call B and C might call B and a PBX managing B might join the call legs A and C together. In so doing, we have a new end-to-end call, but there may not be any session signaling on the wire. There would be a new INVITE sent from B's server (I assume), but we need to ensure that A and C have a common understanding as to what the new end-to-end Session-ID value is. By conveying A's UUID to C and C's UUID to A, each endpoint would know the end-to-end session has changed (device change) and could use that new value in RTCP, RSVP, logging, etc. Billing systems or logging systems could also record that change. I welcome any proposed changes to make this clearer, or changes that might make the Session-ID easier to use. We felt transmitting two UUID values was simple and consistent, but I can see how it might not be perceived as so simple by an external entity looking at the exchanges on the wire. Paul > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Wednesday, February 02, 2011 11:42 AM > To: Paul E. Jones > Cc: DISPATCH list > Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 > > Hi, > > I find the lack of a some specific examples is leaving me with a > question I cannot answer by reading the spec (unless I missed > something). > > So in a dialog startup: > A sends Session-ID with just it's UUID in it. > Final endpoint B responds with the combined UUIDs in a Session-ID header > (it's own plus A's in sorted order) > > So in e.g. debugging - if I want to correlate the INVITE with the > response I am comparing a one UUID header with a two UUID header? > > I don't think that is a huge deal - although it seems a bit more awkward > than just having the initiators UUID used throughout. It would be good > to make the benefits of 2 UUIDs in a header very clear. > > Regards, > > Peter Musgrave > > On 2011-01-30, at 5:07 PM, Paul E. Jones wrote: > > > Folks, > > > > I just wanted to draw your attention to the revised Session ID draft > > we just submitted. Following the discussion we had on this topic > > previously, we introduced one important change: rather than using the > > Contact header, we introduce a new header to convey the UUID used by > > each endpoint that comprises the Session-ID. > > > > The revised draft is here: > > http://tools.ietf.org/html/draft-jones-ipmc-session-id > > > > We welcome any additional comments and input on a way to move this > forward. > > > > Paul > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Wed Feb 2 22:40:38 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D753A67D7 for ; Wed, 2 Feb 2011 22:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN6fW1l5SgpF for ; Wed, 2 Feb 2011 22:40:26 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B9B113A677C for ; Wed, 2 Feb 2011 22:40:18 -0800 (PST) Received: by wwa36 with SMTP id 36so844760wwa.13 for ; Wed, 02 Feb 2011 22:43:28 -0800 (PST) Received: by 10.216.199.81 with SMTP id w59mr2634519wen.100.1296715408465; Wed, 02 Feb 2011 22:43:28 -0800 (PST) Received: from [10.114.118.108] (62-50-199-254.client.stsn.net [62.50.199.254]) by mx.google.com with ESMTPS id n78sm246708weq.3.2011.02.02.22.43.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 22:43:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <051101cbc36c$2b4fde90$81ef9bb0$@packetizer.com> Date: Thu, 3 Feb 2011 06:43:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <69BD36D9-9801-489E-B90F-ADCD08A12E77@magorcorp.com> References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <051101cbc36c$2b4fde90$81ef9bb0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1082) Cc: 'DISPATCH list' Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 06:40:38 -0000 Hi Paul,=20 Thanks for the clarification. Hopefully the next version of the draft = can include some concrete examples.=20 >=20 > We could insert a UUID in the INVITE and a complete Session-ID in = response > messages. I have no objection to describing the procedure in that = way, but > I'm not sure how much value there is in doing that. It might make it = easier > to see the Session-ID more readily, but any application that might = need to > use it would already know one UUID already. I see strong value in this - since I can then look at 200 OKs heading = back through a chain of B2BUAs and make an association with an INVITE = sent from the far end.=20 > I welcome any proposed changes to make this clearer, or changes that = might > make the Session-ID easier to use. We felt transmitting two UUID = values was > simple and consistent, but I can see how it might not be perceived as = so > simple by an external entity looking at the exchanges on the wire. You're right, I do have the perspective of looking at packets on the = wire when I look at these things...and if we can make that simple with = no real impact on the kernel of your idea then I think that is = worthwhile.=20 Thanks,=20 Peter Musgrave= From pkyzivat@cisco.com Thu Feb 3 06:27:44 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3836B3A6980 for ; Thu, 3 Feb 2011 06:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85ttb+eeT0jZ for ; Thu, 3 Feb 2011 06:27:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AF8A63A690B for ; Thu, 3 Feb 2011 06:27:41 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYBAC9LSk1AZnwM/2dsb2JhbACWR45kc6JlmxSFWASEeYZtgy0 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2011 14:31:03 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p13EV3nP027019 for ; Thu, 3 Feb 2011 14:31:03 GMT Message-ID: <4D4ABC27.5070801@cisco.com> Date: Thu, 03 Feb 2011 09:31:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dispatch@ietf.org References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <051101cbc36c$2b4fde90$81ef9bb0$@packetizer.com> In-Reply-To: <051101cbc36c$2b4fde90$81ef9bb0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:27:44 -0000 As I mentioned earlier in this thread, this approach is coming very close to reinventing the dialog-id. The dialog-id consists of three parts: - call-id - from-tag - to-tag All three are required to be globally unique when assigned, and the combination is unique to a single dialog. If you omit the to-tag, then the combination of call-id and from-tag identifies all early and final dialogs that may arise as the result of a single dialog-establishing request (such as INVITE) after it is forked. The call-id is normally reused, with a different from-tag, to retry dialog establishment after a 3xx. Its my impression that some implementations violate some of the uniqueness rules here, assuming that its not necessary for each of the parts to be unique in order to get the combination to be unique. But of course doing that means that some of the partial combinations won't be unique. The existing rules for tags and callid won't give a way to do the correlations that Paul J is looking for. But there is so much similarity that I think it makes sense to consider some way to tie it all together. For instance, perhaps there could be an optional "correlation-tag", which is just the sender's from/to-tag from a related (e.g. by transfer) dialog. Or maybe there could be multiple correlation-tags. We could also *think* (very carefully) about changing the rules for when from-tags, to-tags, and callids are reused. (Even small changes have the potential to break things.) Of course that all depends on SBCs not messing with the tags, and that could be a problem. But any of these schemes depend on SBCs not messing with *some* id. Thanks, Paul On 2/3/2011 1:32 AM, Paul E. Jones wrote: > Peter, > > The idea as currently presented is that A sends its UUID to B and B sends > its UUID to A. A and B both compose the Session-ID locally for whatever > purpose they might have for it. > > So, in debugging, you would look at the INVITE that goes out. There may be > multiple messages coming back due to forking. One would use current > approaches (e.g., Call-ID, tags) to relate a response with an initial > request. While we didn't propose extracting the Session-ID directly from > any single message, it can be constructed and used in logging, recording, > etc. > > We could insert a UUID in the INVITE and a complete Session-ID in response > messages. I have no objection to describing the procedure in that way, but > I'm not sure how much value there is in doing that. It might make it easier > to see the Session-ID more readily, but any application that might need to > use it would already know one UUID already. > > The uses of the Session-ID are several, including functions like logging, > recording, and relating media flows to sessions (e.g., use in RTCP and > RSVP). > > The reason for not using a single UUID is that, in real systems, call legs > get joined/spliced/diced/chopped. A might call B and C might call B and a > PBX managing B might join the call legs A and C together. In so doing, we > have a new end-to-end call, but there may not be any session signaling on > the wire. There would be a new INVITE sent from B's server (I assume), but > we need to ensure that A and C have a common understanding as to what the > new end-to-end Session-ID value is. By conveying A's UUID to C and C's UUID > to A, each endpoint would know the end-to-end session has changed (device > change) and could use that new value in RTCP, RSVP, logging, etc. Billing > systems or logging systems could also record that change. > > I welcome any proposed changes to make this clearer, or changes that might > make the Session-ID easier to use. We felt transmitting two UUID values was > simple and consistent, but I can see how it might not be perceived as so > simple by an external entity looking at the exchanges on the wire. > > Paul > >> -----Original Message----- >> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >> Sent: Wednesday, February 02, 2011 11:42 AM >> To: Paul E. Jones >> Cc: DISPATCH list >> Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 >> >> Hi, >> >> I find the lack of a some specific examples is leaving me with a >> question I cannot answer by reading the spec (unless I missed >> something). >> >> So in a dialog startup: >> A sends Session-ID with just it's UUID in it. >> Final endpoint B responds with the combined UUIDs in a Session-ID header >> (it's own plus A's in sorted order) >> >> So in e.g. debugging - if I want to correlate the INVITE with the >> response I am comparing a one UUID header with a two UUID header? >> >> I don't think that is a huge deal - although it seems a bit more awkward >> than just having the initiators UUID used throughout. It would be good >> to make the benefits of 2 UUIDs in a header very clear. >> >> Regards, >> >> Peter Musgrave >> >> On 2011-01-30, at 5:07 PM, Paul E. Jones wrote: >> >>> Folks, >>> >>> I just wanted to draw your attention to the revised Session ID draft >>> we just submitted. Following the discussion we had on this topic >>> previously, we introduced one important change: rather than using the >>> Contact header, we introduce a new header to convey the UUID used by >>> each endpoint that comprises the Session-ID. >>> >>> The revised draft is here: >>> http://tools.ietf.org/html/draft-jones-ipmc-session-id >>> >>> We welcome any additional comments and input on a way to move this >> forward. >>> >>> Paul >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jose_javier.garcia_aranda@alcatel-lucent.com Thu Feb 3 08:06:19 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122043A69F7 for ; Thu, 3 Feb 2011 08:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.79 X-Spam-Level: X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMyi8WlbGsBw for ; Thu, 3 Feb 2011 08:06:17 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 852D13A69E3 for ; Thu, 3 Feb 2011 08:06:17 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p13G5W0T005847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Feb 2011 17:05:33 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 3 Feb 2011 17:05:33 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "'dispatch@ietf.org'" Date: Thu, 3 Feb 2011 17:05:31 +0100 Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 3 Thread-Index: AcugSvRWsT7gbY+GSyqLnLGU53HqvAAGPezQA4BiV1AFVZaPQA== Message-ID: <3349FECF788C984BB34176D70A51782F1882C802@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F1882C802FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:06:19 -0000 --_000_3349FECF788C984BB34176D70A51782F1882C802FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi folks, that's the version 3 of Q4S charter , after including more received feedbac= k and integration with rtcweb initiative into our objetives regards - jose javier Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide themselves a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed for. Four Network Parameters comprises the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. A Q4S protocol monitors and sends alerts, which are useful to know when those types of solutions should be taken, but it does not assume that that the network is not doing deep packet inspection or differential treatment of services. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design to be used in interactive applications (including virtualized videogames,and interative-video applications) 2. Ensuring interoperability with all existing transport protocols 3. Optimize to use low bit rates in the Q4S control flow (typlically below 2.4 kbps) in order to produce a minimum disturbance in the application flows. 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers 5. Integration into rtcweb inititative as a part of the set of component= s used to communicate universally in real-time communications. Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. 4. Analysis of benefits of Q4S in real-time internet applications and how Q4S complements the rest of components of rtcweb initiative Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Jan 2011 Submision of Q4S protocol Internet-Draft as improvement of Q-HTTP protocol Feb 2011 Proposed charter for Q4S WG Informational document with rules for dimensioning and performance analysis Specification of architecture document for implementation --_000_3349FECF788C984BB34176D70A51782F1882C802FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
hi folks,
 
that's the version 3 of Q4S charter , after including <= SPAN=20 class=3D014520216-03022011>more received feedback and integration with rtcweb initiative into ou= r=20 objetives
 
regards
 
- jose=20 javier
 
 
 
Description of Working=20 group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 
   Problem=20 Statement:
  
   The QoS over Internet is a hot = issue=20 today. Current QoS handling
   mechanisms used in  modern= =20 network transport layers (MPLS, RSVP,
   Diffserv,Traffic=20 Engineering) do not provide  themselves a
   QoS-on-dema= nd=20 end-to-end solution and existing adaptative
   solutions base= d on=20 In-band Control protocols (such as RTCP)
   are very difficul= t to=20 combine with any other protocols for which
   they have not b= een=20 designed for.
 
   Four Network Parameters comprises t= he=20 QoS at application level:
   Bandwidth, packet-loss, latency a= nd=20 Jitter.
  
   Interactive-video applications def= ine=20 flows in both directions.
   Different applications require=20 different constraints (in terms of
   latency, jitter, packet= =20 loss) in one or both directions and
   different responsivene= ss.=20 The proposed solution must be an
   effective out-of-band=20 application level protocol capable of
   reacting when any of= =20 these constraints are violated. Such protocol
   must trigger= =20 adaptive solutions and/or QoS network profile changes.
 
 &= nbsp;=20 A Q4S protocol monitors and sends alerts, which are useful to know when=20
   those types of solutions should be taken, but it does not= =20 assume that
   that the network is not doing deep packet=20 inspection or differential
   treatment of=20 services.
  
   Currently content providers are = only=20 able to provide services based
   on adaptative methods or=20 last-mille deployments which prefer
   dedicated network reso= urces=20 (vs. Internet), and therefore, restricts
   the subscriber=20 population and increases the costs.
  
  =20 Objetives:
 
   The goal of this working group is to d= efine=20 a
   QoS application-level  standard protocol optimized = for=20 its use over
   the internet that may be widely implemented a= nd=20 easily managed
   by application developers and service=20 providers.
  
   The core technical consideratio= ns=20 for such protocol include, but
   are not necessarily limited= to,=20 the following:
  
   1. Protocol design to be us= ed in=20 interactive applications (including
     =20 virtualized videogames,and interative-video applications)
  =20
   2. Ensuring interoperability with all existing transport=20 protocols
  
   3. Optimize to use low bit rates= in=20 the Q4S control flow (typlically
      below 2= .4=20 kbps) in order to produce a minimum disturbance in=20
      the application flows.
  =20
   4. To ensure a feasible practical implementation based on= =20
      policy servers and interoperability betw= een=20 service providers
 
   5. Integratio= n into=20 rtcweb inititative as a part of the set of=20 components
       used to communicate=20 universally in real-time communications. 
  =20
     
  =20 Deliverables:
  
   1. Specification of protocol= that=20 meets the requirements in the
      form of an= =20 Internet-Draft that defines the negotiation of=20 QoS
      parameters, the measurement process a= nd=20 alert mechanisms.
  
   2. Dimensioning rules an= d=20 performance analysis
  
   3. A set of technical= =20 requirements for a practical
      implementati= on=20 which may include adaptative solutions and/or
    &n= bsp;=20 QoS profile modification.
 
   4. Analysis o= f benefits=20 of Q4S in real-time internet applications
     = and=20 how Q4S complements the rest of components of
    &= nbsp;=20 rtcweb initiative
 
 
Goals and=20 Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
 
 Nov=20 2010  Submit Internet-Draft as a proposed standard for=20 QoS 
          &n= bsp;     application-level=20 protocol
 
Jan 2011  Submis= ion of Q4S=20 protocol Internet-Draft as=20
            = ;  =20 improvement of Q-HTTP=20 protocol
          &nb= sp; =20
Feb 2011  Proposed charter for Q4S=20 WG
           &nb= sp;=20
            = ;=20 Informational document with rules for dimensioning=20
            = ; and=20 performance=20 analysis
          &nb= sp; =20
            = ;=20 Specification of architecture document for implementation
 
 
 
= --_000_3349FECF788C984BB34176D70A51782F1882C802FRMRSSXCHMBSB3d_-- From john.elwell@siemens-enterprise.com Thu Feb 3 09:38:27 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7753A6A22 for ; Thu, 3 Feb 2011 09:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzDXCaT9uDUw for ; Thu, 3 Feb 2011 09:38:26 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 552713A6A51 for ; Thu, 3 Feb 2011 09:38:26 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3266535 for dispatch@ietf.org; Thu, 3 Feb 2011 18:41:48 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 447051EB82AB for ; Thu, 3 Feb 2011 18:41:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 3 Feb 2011 18:41:45 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Thu, 3 Feb 2011 18:41:44 +0100 Thread-Topic: ACH RESTful interface Thread-Index: AcvDyZ+F+xbwfQUFSdqKsevYgjOXTg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] ACH RESTful interface X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:38:27 -0000 The chairs have asked for folks to express interest in various topics propo= sed for the next DISPATCH meeting. Concerning the ACH RESTful interface, I = had some interest when it was first proposed in BLISS some 3 or 4 years ago= . However, I think it has missed its window of opportunity. John = From bernard_aboba@hotmail.com Thu Feb 3 10:07:01 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04A23A67F9 for ; Thu, 3 Feb 2011 10:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNQoEwcxqrB8 for ; Thu, 3 Feb 2011 10:07:00 -0800 (PST) Received: from blu0-omc1-s19.blu0.hotmail.com (blu0-omc1-s19.blu0.hotmail.com [65.55.116.30]) by core3.amsl.com (Postfix) with ESMTP id EF6143A695E for ; Thu, 3 Feb 2011 10:06:59 -0800 (PST) Received: from BLU152-W62 ([65.55.116.9]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 10:10:21 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_50b8dae5-70a4-42ee-9f39-c360ce486bff_" X-Originating-IP: [131.107.0.76] From: Bernard Aboba To: , Date: Thu, 3 Feb 2011 10:10:21 -0800 Importance: Normal In-Reply-To: <4D4ADCD3.3070708@alvestrand.no> References: , <4D49F24C.5000105@alvestrand.no>, , , <4D4ADCD3.3070708@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2011 18:10:21.0935 (UTC) FILETIME=[9F598FF0:01CBC3CD] Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:07:02 -0000 --_50b8dae5-70a4-42ee-9f39-c360ce486bff_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Given that people have been using workarounds to obtain IP addresses=2C the= value of keeping this out of Javascript seems marginal.=20 However=2C since the W3C will be handling APIs=2C not the IETF=2C this does= raise the question of how issues like this will be coordinated. Date: Thu=2C 3 Feb 2011 08:50:27 -0800 From: harald@alvestrand.no To: juberti@google.com CC: bernard_aboba@hotmail.com=3B rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protoco= l? =20 =20 =20 =20 On 02/03/11 01:32=2C Justin Uberti wrote: =20 I would expect that the APIs that this group creates would handle the details of obtaining any needed addresses (whether they be local=2C server reflexive=2C or relayed endpoints). Do we think there is a significant security concern here (above and beyond exposing the ability to send audio and video from your computer)? =20 =20 Apart from the known security concerns that come automatically from sharing IP addresses (such as revealing your network attachment location to whoever gets the IP address)=2C I don't see any huge ones. =20 =20 On Wed=2C Feb 2=2C 2011 at 7:49 PM=2C Bernard Aboba wrote: =20 =20 Alternatives can be explored for how to represent the information provided by SDP=2C but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245)=2C and is also a potential means for demonstrating media authorization. If the Javascript limitations on enumeration of physical or logical addresses can't be overcome=2C we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). =20 Date: Wed=2C 2 Feb 2011 16:09:48 -0800 From: harald@alvestrand.no To: rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? =20 =20 =20 On 02/02/11 11:19=2C Henry Sinnreich wrote: Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? =20 Nit: UNSAF=2C not USAF. http://www.rfc-editor.org/rfc/rfc3424.txt =20 =20 =93...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange=2C or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect=3B there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations=2C "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols=2C and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.=94 =20 In our case=2C the answer that has proved workable is called STUN. =20 Obviously there is much more dead stuff in SDP besides using the misleading IP addresses=2C but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-= 07 =20 Why not replace SDP=2C since it deals only with a/v codec negotiation with a more general=2C standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure.=20 =20 Or are the no =93sound technical approaches=94 available at all? =20 I'm all in favour of replacing SDP=2C but would not like to require that before we can produce any output from this group. =20 Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever. =20 Harald =20 =20 =20 =20 _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web =20 =20 _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web = --_50b8dae5-70a4-42ee-9f39-c360ce486bff_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Given that people have been using workarounds to obtain IP addresses=2C the= value of keeping this out of Javascript seems marginal.

However=2C= since the W3C will be handling APIs=2C not the IETF=2C this does raise the= question of how issues like this will be coordinated.

Date: Thu=2C 3 Feb 2011 08:50:27 -0800
From: harald@alvestran= d.no
To: juberti@google.com
CC: bernard_aboba@hotmail.com=3B rtc-web@= alvestrand.no
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a = signaling protocol?

=20 =20 =20 =20 On 02/03/11 01:32=2C Justin Uberti wrote:
I would expect that the APIs that this group creates would handle the details of obtaining any needed addresses (whether they be local=2C server reflexive=2C or relayed endpoints). Do we think there is a significant security concern here (above and beyond exposing the ability to send audio and video from your computer)?

Apart from the known security concerns that come automatically from sharing IP addresses (such as revealing your network attachment location to whoever gets the IP address)=2C I don't see any huge ones.<= br>

On Wed=2C Feb 2=2C 2011 at 7:49 PM=2C= Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B wrote:
Alternatives can be explored for how to represent the information provided by SDP=2C but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245)=2C and is also a potential means for demonstrating media authorization. = =3B If the Javascript limitations on enumeration of physical or logical addresses can't be overcome=2C we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). =3B Replacin= g addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). =3B
Date: Wed=2C 2 Feb 2011 16:09:48 -0800
From: harald@alvestra= nd.no
To: rtc-web@alvestra= nd.no
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?


On 02/02/11 11:19=2C Henry Sinnreich wrote:
Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424?
Nit: UNSAF=2C not USAF.
http://www.rf= c-editor.org/rfc/rfc3424.txt

=93...a process wher= eby some
 =3B =3B =3Boriginating process attem= pts to determine or fix the address (and
 =3B =3B =3Bport) by which it is know= n - e.g. to be able to use address data in
 =3B =3B =3Bthe protocol exchange=2C = or to advertise a public address from which it
 =3B =3B =3Bwill receive connections.=
There are only heuristics and workarounds to attempt to achieve this
 =3B =3B =3Beffect=3B there is no 100= % solution.  =3BSince NATs may also dynamically
 =3B =3B =3Breclaim or readjust trans= lations=2C "keep-alive" and periodic re-
 =3B =3B =3Bpolling may be required. =  =3BUse of these workarounds MUST be considered
 =3B =3B =3Btransitional in IETF prot= ocols=2C and a better architectural solution
 =3B =3B =3Bis being sought.  =3B= The explicit intention is to deprecate any such
 =3B =3B =3Bworkarounds when sound te= chnical approaches are available.=94
In our case=2C the answer that has proved workable is called STUN.

Obviously there is much more dead stuff in SDP besides using the misleading IP addresses=2C but this seems to be a deep architectural flaw.
There were some early attempts to do SDPng and we know today much more:
http://tools.ietf.org/html/draft-ietf-mmus= ic-sdpng-07

Why not replace SDP=2C since it deals only with a/v codec negotiation with a more general=2C standards based metadata approach?
For example including Web conferencing displays and UI control capabilities.
Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure.

Or are the no  =3B=93sound technical approaches= =94 available at all?
I'm all in favour of replacing SDP=2C but would not like to require that before we can produce any output from this group.

Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever.

 =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B Harald


_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.n= o http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no<= /a>
http://www.alvestrand.no/mailman/listinfo/rtc-web



=20
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web = --_50b8dae5-70a4-42ee-9f39-c360ce486bff_-- From mary.ietf.barnes@gmail.com Thu Feb 3 10:24:45 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8B23A65A6 for ; Thu, 3 Feb 2011 10:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntKZmn5hyxrM for ; Thu, 3 Feb 2011 10:24:44 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C3C4D3A6452 for ; Thu, 3 Feb 2011 10:24:43 -0800 (PST) Received: by gyd12 with SMTP id 12so664501gyd.31 for ; Thu, 03 Feb 2011 10:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a9MznGnP4nkoSiI5d/7mUXh3gO2dMXTPvVxwXuq+ZsQ=; b=gzbxYzKglFIg57mlYJarSOpIlMj860UMTA6Tj9NqqmZKKd5wLtsIpsk2tZDY1cb5sH ZoyEj2J8nXSbDPNFAfLLqfNKamef6aUnK0ZX75l5ngEIoMTd9AtJHEFkID6XGlJvKsOE +HEldocW/oEDN80b+BAxLez3UX5tXSkE6J3bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DFntSWSyaIKTDklNS1eicInwcMY0NUXxcvtYoWpiXiULWF6zxY9uym2CZhDKgFtRJZ /BSibBVIJmXTdZzfOS4yOjtsoIYvNHvy7jt8VQZVhRB+Ugg/cibbWqO+7ab0N9h/VW8r SN01KrNBIZnutS1qX+cqJ+VfbPTK/MgEubvkw= MIME-Version: 1.0 Received: by 10.236.109.168 with SMTP id s28mr5259221yhg.74.1296757686243; Thu, 03 Feb 2011 10:28:06 -0800 (PST) Received: by 10.236.95.35 with HTTP; Thu, 3 Feb 2011 10:28:06 -0800 (PST) In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822082B69C6@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822082B69C6@DC-US1MBEX4.global.avaya.com> Date: Thu, 3 Feb 2011 12:28:06 -0600 Message-ID: From: Mary Barnes To: "Shekh-Yusef, Rifaat (Rifaat)" Content-Type: multipart/alternative; boundary=0023547c8b433fa2db049b64ed11 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP Action Referral X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:24:45 -0000 --0023547c8b433fa2db049b64ed11 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Based on the ML discussion of this topic and conferring with the ADs and chairs of the SPLICES WG, this work item is being dispatched to the SPLICES WG. Regards, Mary. DISPATCH WG co-chair On Fri, Jan 14, 2011 at 12:41 PM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Hi, > > We have submitted the following SIP Action Referral draft to the IETF and > we would like to discuss it during the upcoming DISPATCH meeting in IETF80. > https://datatracker.ietf.org/doc/draft-yusef-dispatch-action-ref/ > A charter proposal will follow by the end of next week. > > We would appreciate any comments or feedback on this draft. > > Thanks, > Rifaat > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, January 14, 2011 8:15 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: fluffy@cisco.com; alan.b.johnston@gmail.com; francois.audet@skype.net > Subject: New Version Notification for draft-yusef-dispatch-action-ref-00 > > > A new version of I-D, draft-yusef-dispatch-action-ref-00.txt has been > successfully submitted by Rifaat Shekh-Yusef and posted to the IETF > repository. > > Filename: draft-yusef-dispatch-action-ref > Revision: 00 > Title: Action Referral in the Session Initiation Protocol (SIP) > Creation_date: 2011-01-14 > WG ID: Independent Submission > Number_of_pages: 24 > > Abstract: > This specification defines action referral that allows an application > to make a high level request to a User Agent to perform an action, > and let the the User Agent execute the action as it sees fit. Action > referral uses the SIP REFER method with a Refer-To header field > containing a URN, which indicates the requested action. > > This specification also defines the option tag 'action-ref' to allow > the UA to indicate its support for action referral. > > > > The IETF Secretariat. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0023547c8b433fa2db049b64ed11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Based on the ML discussion of this topic and c= onferring with the ADs and chairs of the SPLICES WG, this work item is bein= g dispatched to the SPLICES WG. =A0

Regards,
Mary.
DISPATCH WG co-chair=A0

On Fri, Jan 14, 2011 at 12:41 PM, Shekh-Yusef, Rifaat (Rifaat) <= span dir=3D"ltr"><rifatyu@avaya.com= > wrote:
Hi,

We have submitted the following SIP Action Referral draft to the IETF and w= e would like to discuss it during the upcoming DISPATCH meeting in IETF80.<= br> https://datatracker.ietf.org/doc/draft-yusef-dispatch-= action-ref/
A charter proposal will follow by the end of next week.

We would appreciate any comments or feedback on this draft.

Thanks,
=A0Rifaat


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Friday, January 14, 2011 8:15 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: fluffy@cisco.com; alan.b.johnston@gmail.com; francois.audet@skype.net
Subject: New Version Notification for draft-yusef-dispatch-action-ref-00

A new version of I-D, draft-yusef-dispatch-action-ref-00.txt has been succe= ssfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository.<= br>
Filename: =A0 =A0 =A0 =A0draft-yusef-dispatch-action-ref
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Action Referral in the Session Initiation Protoc= ol (SIP)
Creation_date: =A0 2011-01-14
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 24

Abstract:
This specification defines action referral that allows an application
to make a high level request to a User Agent to perform an action,
and let the the User Agent execute the action as it sees fit. Action
referral uses the SIP REFER method with a Refer-To header field
containing a URN, which indicates the requested action.

This specification also defines the option tag 'action-ref' to allo= w
the UA to indicate its support for action referral.



The IETF Secretariat.


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0023547c8b433fa2db049b64ed11-- From harald@alvestrand.no Thu Feb 3 16:52:18 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED353A68F3 for ; Thu, 3 Feb 2011 16:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0hhsAVJlaI7 for ; Thu, 3 Feb 2011 16:52:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 684283A68E7 for ; Thu, 3 Feb 2011 16:52:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE24339E113; Fri, 4 Feb 2011 01:55:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vty8ItNYiHES; Fri, 4 Feb 2011 01:55:07 +0100 (CET) Received: from [172.22.71.26] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DB16039E0C4; Fri, 4 Feb 2011 01:55:05 +0100 (CET) Message-ID: <4D4B4E85.5090907@alvestrand.no> Date: Thu, 03 Feb 2011 16:55:33 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> <3349FECF788C984BB34176D70A51782F1882C802@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F1882C802@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------040307050108020207060602" Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:52:18 -0000 This is a multi-part message in MIME format. --------------040307050108020207060602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think the milestones may need some more tuning - as presently presented, all the work of the group will be done in February 2011. What timescale do you anticipate for this work, and who do you think will participate (as opposed to who you *want* to participate)? On 02/03/11 08:05, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > hi folks, > that's the version 3 of Q4S charter , after including more received > feedback and integration with rtcweb initiative into our objetives > regards > - jose javier > Description of Working group > ============================ > > Problem Statement: > > The QoS over Internet is a hot issue today. Current QoS handling > mechanisms used in modern network transport layers (MPLS, RSVP, > Diffserv,Traffic Engineering) do not provide themselves a themselves -> // (superfluous word) > QoS-on-demand end-to-end solution and existing adaptative > solutions based on In-band Control protocols (such as RTCP) > are very difficult to combine with any other protocols for which > they have not been designed for. remove extra "for" > > Four Network Parameters comprises the QoS at application level: > Bandwidth, packet-loss, latency and Jitter. actually perceived quality is likely to be affected not just by the values of these parameters, but by the *changes* in these parameters - if available bandwidth suddenly drops, creating dropouts, people are going to perceive the quality as worse than the quality of a lower-bandwidth channel that's there all the time. I would suggest "comprises" -> "are commonly used to measure". > > Interactive-video applications define flows in both directions. > Different applications require different constraints (in terms of > latency, jitter, packet loss) in one or both directions and > different responsiveness. The proposed solution must be an > effective out-of-band application level protocol capable of > reacting when any of these constraints are violated. Such protocol > must trigger adaptive solutions and/or QoS network profile changes. > > A Q4S protocol monitors and sends alerts, which are useful to know > when > those types of solutions should be taken, but it does not assume that > that the network is not doing deep packet inspection or differential > treatment of services. > > Currently content providers are only able to provide services based > on adaptative methods or last-mille deployments which prefer > dedicated network resources (vs. Internet), and therefore, restricts > the subscriber population and increases the costs. > > Objetives: > > The goal of this working group is to define a > QoS application-level standard protocol optimized for its use over > the internet that may be widely implemented and easily managed > by application developers and service providers. does the protocol require service providers to implement it before it's useful? The charter should state whether the goal is a protocol that can be deployed by end-nodes, or whether it needs in-the-network help. > > The core technical considerations for such protocol include, but > are not necessarily limited to, the following: > > 1. Protocol design to be used in interactive applications (including > virtualized videogames,and interative-video applications) suggest "to be used in" -> "should be useful for" > > 2. Ensuring interoperability with all existing transport protocols suggest "Q4S should be applicable for measuring quality of connections using all existing transport protocols". > > 3. Optimize to use low bit rates in the Q4S control flow (typlically > below 2.4 kbps) in order to produce a minimum disturbance in > the application flows. > > 4. To ensure a feasible practical implementation based on > policy servers and interoperability between service providers This seems to clearly indicate that the protocol is not deployable by end-nodes only. Is this true? > 5. Integration into rtcweb inititative as a part of the set of > components > used to communicate universally in real-time communications. Suggest "Q4S should be useful for applications using the protocols defined by the rtcweb initiative" - I have no real comprehension of what specific action would be required by the existing text. > > > Deliverables: > > 1. Specification of protocol that meets the requirements in the > form of an Internet-Draft that defines the negotiation of QoS > parameters, the measurement process and alert mechanisms. > > 2. Dimensioning rules and performance analysis > > 3. A set of technical requirements for a practical > implementation which may include adaptative solutions and/or > QoS profile modification. > 4. Analysis of benefits of Q4S in real-time internet applications > and how Q4S complements the rest of components of > rtcweb initiative Please fill in the goals and milestones with when you expect to deliver the deliverables. Also, indicating which of the items are intended to be standards-track woudl be useful. > Goals and Milestiones > ===================== > > Nov 2010 Submit Internet-Draft as a proposed standard for QoS > application-level protocol > Jan 2011 Submision of Q4S protocol Internet-Draft as > improvement of Q-HTTP protocol > > Feb 2011 Proposed charter for Q4S WG > > Informational document with rules for dimensioning > and performance analysis > > Specification of architecture document for implementation > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------040307050108020207060602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think the milestones may need some more tuning - as presently presented, all the work of the group will be done in February 2011.

What timescale do you anticipate for this work, and who do you think will participate (as opposed to who you *want* to participate)?



On 02/03/11 08:05, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:
hi folks,
 
that's the version 3 of Q4S charter , after including more received feedback and integration with rtcweb initiative into our objetives
 
regards
 
- jose javier
 
 
 
Description of Working group
============================
 
   Problem Statement:
  
   The QoS over Internet is a hot issue today. Current QoS handling
   mechanisms used in  modern network transport layers (MPLS, RSVP,
   Diffserv,Traffic Engineering) do not provide  themselves a
themselves -> // (superfluous word)
   QoS-on-demand end-to-end solution and existing adaptative
   solutions based on In-band Control protocols (such as RTCP)
   are very difficult to combine with any other protocols for which
   they have not been designed for.
remove extra "for"
 
   Four Network Parameters comprises the QoS at application level:
   Bandwidth, packet-loss, latency and Jitter.
actually perceived quality is likely to be affected not just by the values of these parameters, but by the *changes* in these parameters - if available bandwidth suddenly drops, creating dropouts, people are going to perceive the quality as worse than the quality of a lower-bandwidth channel that's there all the time. I would suggest "comprises" -> "are commonly used to measure".
  
   Interactive-video applications define flows in both directions.
   Different applications require different constraints (in terms of
   latency, jitter, packet loss) in one or both directions and
   different responsiveness. The proposed solution must be an
   effective out-of-band application level protocol capable of
   reacting when any of these constraints are violated. Such protocol
   must trigger adaptive solutions and/or QoS network profile changes.
 
   A Q4S protocol monitors and sends alerts, which are useful to know when
   those types of solutions should be taken, but it does not assume that
   that the network is not doing deep packet inspection or differential
   treatment of services.
  
   Currently content providers are only able to provide services based
   on adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs. Internet), and therefore, restricts
   the subscriber population and increases the costs.
  
   Objetives:
 
   The goal of this working group is to define a
   QoS application-level  standard protocol optimized for its use over
   the internet that may be widely implemented and easily managed
   by application developers and service providers.
does the protocol require service providers to implement it before it's useful? The charter should state whether the goal is a protocol that can be deployed by end-nodes, or whether it needs in-the-network help.
  
   The core technical considerations for such protocol include, but
   are not necessarily limited to, the following:
  
   1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)
suggest "to be used in" -> "should be useful for"
  
   2. Ensuring interoperability with all existing transport protocols
suggest "Q4S should be applicable for measuring quality of connections using all existing transport protocols".
  
   3. Optimize to use low bit rates in the Q4S control flow (typlically
      below 2.4 kbps) in order to produce a minimum disturbance in
      the application flows.
  
   4. To ensure a feasible practical implementation based on
      policy servers and interoperability between service providers
This seems to clearly indicate that the protocol is not deployable by end-nodes only. Is this true?
 
   5. Integration into rtcweb inititative as a part of the set of components
       used to communicate universally in real-time communications. 
Suggest "Q4S should be useful for applications using the protocols defined by the rtcweb initiative" - I have no real comprehension of what specific action would be required by the existing text.
  
     
   Deliverables:
  
   1. Specification of protocol that meets the requirements in the
      form of an Internet-Draft that defines the negotiation of QoS
      parameters, the measurement process and alert mechanisms.
  
   2. Dimensioning rules and performance analysis
  
   3. A set of technical requirements for a practical
      implementation which may include adaptative solutions and/or
      QoS profile modification.
 
   4. Analysis of benefits of Q4S in real-time internet applications
      and how Q4S complements the rest of components of
      rtcweb initiative
Please fill in the goals and milestones with when you expect to deliver the deliverables. Also, indicating which of the items are intended to be standards-track woudl be useful.
 
 
Goals and Milestiones
=====================
 
 Nov 2010  Submit Internet-Draft as a proposed standard for QoS 
                application-level protocol
 
Jan 2011  Submision of Q4S protocol Internet-Draft as
               improvement of Q-HTTP protocol
            
Feb 2011  Proposed charter for Q4S WG
            
             Informational document with rules for dimensioning
             and performance analysis
            
             Specification of architecture document for implementation
 
 
 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------040307050108020207060602-- From jose_javier.garcia_aranda@alcatel-lucent.com Thu Feb 3 23:40:51 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D993A6886 for ; Thu, 3 Feb 2011 23:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A6lsd0S70O2 for ; Thu, 3 Feb 2011 23:40:49 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A80943A6882 for ; Thu, 3 Feb 2011 23:40:47 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p147i70h026195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 08:44:10 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 4 Feb 2011 08:44:08 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Harald Alvestrand Date: Fri, 4 Feb 2011 08:44:06 +0100 Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 4 Thread-Index: AcvEBkHbkL8EPdDjSFaj432KnMMFGgAM2l0w Message-ID: <3349FECF788C984BB34176D70A51782F1882C99A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> <3349FECF788C984BB34176D70A51782F1882C802@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D4B4E85.5090907@alvestrand.no> In-Reply-To: <4D4B4E85.5090907@alvestrand.no> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F1882C99AFRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 07:40:51 -0000 --_000_3349FECF788C984BB34176D70A51782F1882C99AFRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable first, thanks for your suggestions, i have made changes in the document bas= ed on them. we are working in a two and a half years long project for deploy Q4S in a f= ixed network and in a mobile (LTE) network. The initial steps are the definition of the protocol, but after implementat= ion and checking some use cases we will get some interesting measurements and dimensioning rules in terms of number of = users, traffic, number of Q4S transactions vs number of sessions, etc The deployment in which we are working now is based on a policy server, whi= ch receives the Q4S alerts and acts over network elements in real-time to provide a better QoS. If the protocol= is only implemented in end-nodes then the measurements and the alerts can be only used for adaptative mechan= isms. However, if a policy server is able to receive Q4S alerts and send commands to network elements to chan= ge QoS profiles ( in terms of priorities, queue-sizes, bandwidth, resource reservation, path changes, etc= ) then the Q4S becomes a high potential tool. The other possible implementation consists of a "Q4S network aware", in whi= ch network elements detects by themselves the QoS alerts and auto-tune. This implementation needs specific= HW and SW to be achieved. in this new version i have tuned the milestones in order to be more clear = in our commitments, and i have made the changes according with your right suggestions Thanks, - Jose Javier Description of Working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Problem Statement: The QoS over Internet is a hot issue today. Current QoS handling mechanisms used in modern network transport layers (MPLS, RSVP, Diffserv,Traffic Engineering) do not provide a QoS-on-demand end-to-end solution and existing adaptative solutions based on In-band Control protocols (such as RTCP) are very difficult to combine with any other protocols for which they have not been designed. Four Network Parameters are commonly used to measure the QoS at application level: Bandwidth, packet-loss, latency and Jitter. Interactive-video applications define flows in both directions. Different applications require different constraints (in terms of latency, jitter, packet loss) in one or both directions and different responsiveness. The proposed solution must be an effective out-of-band application level protocol capable of reacting when any of these constraints are violated. Such protocol must trigger adaptive solutions and/or QoS network profile changes. A Q4S protocol monitors and sends alerts, which are useful to know when those types of solutions should be taken, but it does not assume that that the network is not doing deep packet inspection or differential treatment of services. Currently content providers are only able to provide services based on adaptative methods or last-mille deployments which prefer dedicated network resources (vs. Internet), and therefore, restricts the subscriber population and increases the costs. Objetives: The goal of this working group is to define a QoS application-level standard protocol optimized for its use over the internet that may be widely implemented and easily managed by application developers and service providers. If the protocol is only implemented in end-nodes then the measurements and the alerts can be only used for adaptative mechanisms. However, if a policy server is able to receive Q4S alerts and send commands to network elements to change QoS profiles ( in terms of priorities, queue-sizes, bandwidth, resource reservation, path changes, = etc) then the Q4S becomes a high potential tool for internet real-time applic= ations The core technical considerations for such protocol include, but are not necessarily limited to, the following: 1. Protocol design should be used for interactive applications (includin= g virtualized videogames,and interative-video applications) 2. Q4S should be applicable for measuring quality of connections using all existing transport protocols 3. Optimize to use low bit rates in the Q4S control flow (typlically below 2.4 kbps) in order to produce a minimum disturbance in the application flows. 4. To ensure a feasible practical implementation based on policy servers and interoperability between service providers 5. Q4S should be useful for applications using the protocols defined by the rtcweb initiative. Deliverables: 1. Specification of protocol that meets the requirements in the form of an Internet-Draft that defines the negotiation of QoS parameters, the measurement process and alert mechanisms. 2. Dimensioning rules and performance analysis 3. A set of technical requirements for a practical implementation which may include adaptative solutions and/or QoS profile modification. 4. Analysis of benefits of Q4S in real-time internet applications and how Q4S complements the rest of components of rtcweb initiative Goals and Milestiones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nov 2010 Submit Internet-Draft as a proposed standard for QoS application-level protocol Jan 2011 Submision of Q4S protocol Internet-Draft as improvement of Q-HTTP protocol ( Standard-track) Feb 2011 Proposed charter for Q4S WG Jul 2011 informational document about use-cases and virtualized videogames perceived quality under network QoS changes Jun 2012 Specification of architecture document for implementation Dic 2012 Informational document with rules for dimensioning and performance analysis --_000_3349FECF788C984BB34176D70A51782F1882C99AFRMRSSXCHMBSB3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
first, thanks for your suggestions, i have made = changes=20 in the document based on them.
 
we are working in a two and a half years long pr= oject=20 for deploy Q4S in a fixed network and in a mobile (LTE) network.=20
The initial steps are the definition of the prot= ocol,=20 but after implementation and checking some use cases we will=20 get
some interesting measurements and dimensioning r= ules in=20 terms of number of users, traffic, number of Q4S
transactions vs number of sessions,=20 etc
 
The deployment in which we are working now = is=20 based on a policy server, which receives the Q4S alerts  and acts=20
over network elements in real-time to provide a = better=20 QoS. If the protocol is only implemented in end-nodes
then the measurements and the alerts can be only= used=20 for adaptative mechanisms. However, if a policy server
is able to receive Q4S alerts and send commands = to=20 network elements to change QoS profiles ( in terms of
priorities, queue-sizes, bandwidth, resource=20 reservation, path changes, etc) then the Q4S becomes a high
potential tool.
 
The other possible implementation consists of a = "Q4S=20 network aware", in which network elements detects by
themselves the QoS alerts and auto-tune. This=20 implementation needs specific HW and SW to be achieved.
 
 
in this new version  i have tuned the miles= tones=20 in order to be more clear in our commitments, and i have
made the changes according with your right=20 suggestions
 
Thanks,
 
- Jose Javier
 
 
Description of Worki= ng=20 group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 
   Problem=20 Statement:
  
   The QoS over Internet is a hot = issue=20 today. Current QoS handling
   mechanisms used in  modern= =20 network transport layers (MPLS, RSVP,
   Diffserv,Traffic=20 Engineering) do not provide  a QoS-on-demand end-to-end=20
   solution and existing=20 adaptative solutions based on In-band Control
   protocols (such as RTCP)&nbs= p;are=20 very difficult to combine with any other
   protocols for which the= y have=20 not been designed.
   Four Network= =20 Parameters are commonly used to=20 measure the QoS at
   application level: Bandwidth= ,=20 packet-loss, latency and Jitter.
   Interactive-v= ideo=20 applications define flows in both directions.
   Different=20 applications require different constraints (in terms of
  =20 latency, jitter, packet loss) in one or both directions and
  = ;=20 different responsiveness. The proposed solution must be an
  = =20 effective out-of-band application level protocol capable of
  = ;=20 reacting when any of these constraints are violated. Such protocol=20
   must trigger adaptive solutions and/or QoS network profile= =20 changes.
 
   A Q4S protocol monitors and sends alerts= ,=20 which are useful to know when
   those types of solutions sho= uld=20 be taken, but it does not assume that
   that the network is = not=20 doing deep packet inspection or differential
   treatment of= =20 services.
  
   Currently content providers are = only=20 able to provide services based
   on adaptative methods or=20 last-mille deployments which prefer
   dedicated network reso= urces=20 (vs. Internet), and therefore, restricts
   the subscriber=20 population and increases the costs.
  
  =20 Objetives:
 
   The goal of this working group is to d= efine=20 a
   QoS application-level  standard protocol optimized = for=20 its use over
   the internet that may be widely implemented a= nd=20 easily managed
   by application developers and service=20 providers.
 
   = If the protocol is only implemented in end-nodes=20 then the
   measurements and the alerts can be = only=20 used for adaptative mechanisms.
   However, if a policy=20 server is able to receive Q4S alerts and send=20
   commands to network elements to cha= nge QoS=20 profiles ( in terms of
   priorities, queue= -sizes,=20 bandwidth, resource reservation, path changes, etc)
   then the Q4S becomes a high=20 potential tool for internet real-time=20 applications
  
   The core technical considerations for= such=20 protocol include, but
   are not necessarily limited to, the= =20 following:
  
   1. Protocol design should be used for interactive applications=20 (including
      virtualized videogames,and=20 interative-video applications)
  
   2. Q4S should be applicable for measu= ring=20 quality of connections using
       all= =20 existing transport protocols
  
   3. Optimize to use low bit rates in t= he Q4S=20 control flow (typlically
      below 2.4 kbps)= in=20 order to produce a minimum disturbance in
     = ; the=20 application flows.
  
   4. To ensure a feasible= =20 practical implementation based on
      policy= =20 servers and interoperability between service providers
 
&nb= sp;  5.=20 Q4S should be useful for applications using the protocols
       defi= ned by=20 the rtcweb initiative. 
      
  =20 Deliverables:
  
   1. Specification of protocol= that=20 meets the requirements in the
      form of an= =20 Internet-Draft that defines the negotiation of=20 QoS
      parameters, the measurement process a= nd=20 alert mechanisms.
  
   2. Dimensioning rules an= d=20 performance analysis
  
   3. A set of technical= =20 requirements for a practical
      implementati= on=20 which may include adaptative solutions and/or
    &n= bsp;=20 QoS profile modification.
 
&nb= sp;  4.=20 Analysis of benefits of Q4S in real-time internet=20 applications
      and how Q4S complements the = rest=20 of components of
      rtcweb=20 initiative
Goals=20 and Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
 
Nov 2010  Submit=20 Internet-Draft as a proposed standard for=20 QoS 
          &n= bsp;     application-level protocol
 
<= FONT=20 color=3D#0000ff>Jan 2011  Submision of Q4S protoco= l=20 Internet-Draft as=20
            = ;  =20 improvement of Q-HTTP protocol (=20 Standard-track)
        &= nbsp;   =20
Feb 2011  Proposed charter for Q4S=20 WG
           &nb= sp; 
Jul 2011   informational document about use-cases=20 and virtualized=20
        =       =20 videogames perceived quality under network QoS=20 changes
 
<= FONT=20 color=3D#0000ff>Jun 2012=20 Specification of architecture document for=20 implementation
Dic  2012  Informational docume= nt with=20 rules for=20 dimensioning 
         = ;      and performance=20 analysis
          &nb= sp;  

--_000_3349FECF788C984BB34176D70A51782F1882C99AFRMRSSXCHMBSB3d_-- From harald@alvestrand.no Fri Feb 4 09:26:30 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B383A69A8 for ; Fri, 4 Feb 2011 09:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 610zc5k3Kg9o for ; Fri, 4 Feb 2011 09:26:28 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 0EF843A69AF for ; Fri, 4 Feb 2011 09:26:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF2C439E165; Fri, 4 Feb 2011 18:29:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPsWlaY+qkaU; Fri, 4 Feb 2011 18:29:23 +0100 (CET) Received: from [172.19.103.174] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C3F7B39E038; Fri, 4 Feb 2011 18:29:22 +0100 (CET) Message-ID: <4D4C378E.3040903@alvestrand.no> Date: Fri, 04 Feb 2011 09:29:50 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> <3349FECF788C984BB34176D70A51782F1882C802@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D4B4E85.5090907@alvestrand.no> <3349FECF788C984BB34176D70A51782F1882C99A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F1882C99A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:26:30 -0000 Thank you, this makes it much clearer. Harald From dworley@avaya.com Fri Feb 4 11:10:47 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F17A3A6A3B for ; Fri, 4 Feb 2011 11:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD3fgmAJEyhB for ; Fri, 4 Feb 2011 11:10:45 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7133D3A69CF for ; Fri, 4 Feb 2011 11:10:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIveS03GmAcF/2dsb2JhbAClLXOgRQKYd4VaBIR6ijQ X-IronPort-AV: E=Sophos;i="4.60,427,1291611600"; d="scan'208";a="230949325" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Feb 2011 14:14:09 -0500 X-IronPort-AV: E=Sophos;i="4.60,427,1291611600"; d="scan'208";a="578703617" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Feb 2011 14:14:09 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 4 Feb 2011 14:14:08 -0500 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Fri, 4 Feb 2011 14:12:37 -0500 Thread-Topic: ACH RESTful interface Thread-Index: AcvDyZ+F+xbwfQUFSdqKsevYgjOXTgA1dw/v Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] ACH RESTful interface X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:10:47 -0000 The chairs have asked for folks to express interest in various topics propo= sed for the next DISPATCH meeting. Concerning the ACH RESTful interface, I = think there is value in progressing this work. In closed-world situations = where the phone and the PBX are made by the same (large) vendor, there are = proprietary solutions to these problems. But there is no standardized solu= tion that allows generic phones to communicate this information with open-a= rchitecture PBXs. Dale From jdrosen@jdrosen.net Fri Feb 4 11:49:13 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDE23A692E for ; Fri, 4 Feb 2011 11:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np5pwZOyayqB for ; Fri, 4 Feb 2011 11:49:11 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.118]) by core3.amsl.com (Postfix) with ESMTP id 94E733A69A9 for ; Fri, 4 Feb 2011 11:49:11 -0800 (PST) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PlRhp-0002oR-Vu; Fri, 04 Feb 2011 14:52:34 -0500 Message-ID: <4D4C5903.4090200@jdrosen.net> Date: Fri, 04 Feb 2011 14:52:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bernard Aboba References: , <4D49F24C.5000105@alvestrand.no>, , , <4D4ADCD3.3070708@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: harald@alvestrand.no, rtc-web@alvestrand.no, dispatch@ietf.org, juberti@google.com Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:49:13 -0000 I think it is well within the scope of the IETF activity to define the protocols and, consequently, their semantics which must be exposed by the browser. The actual API is then the problem of the W3C. As it relates to this question about IP addresses - I don't see the need to specify any kind of syntax at all around how IP addresses are conveyed. Rather, we just need to be certain that APIs exist which allow a Javacript application to obtain the IP addresses needed to construct the SDP. Thanks, Jonathan R. On 2/3/2011 1:10 PM, Bernard Aboba wrote: > Given that people have been using workarounds to obtain IP addresses, > the value of keeping this out of Javascript seems marginal. > > However, since the W3C will be handling APIs, not the IETF, this does > raise the question of how issues like this will be coordinated. > > ------------------------------------------------------------------------ > Date: Thu, 3 Feb 2011 08:50:27 -0800 > From: harald@alvestrand.no > To: juberti@google.com > CC: bernard_aboba@hotmail.com; rtc-web@alvestrand.no > Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling > protocol? > > On 02/03/11 01:32, Justin Uberti wrote: > > I would expect that the APIs that this group creates would handle > the details of obtaining any needed addresses (whether they be > local, server reflexive, or relayed endpoints). Do we think there is > a significant security concern here (above and beyond exposing the > ability to send audio and video from your computer)? > > > Apart from the known security concerns that come automatically from > sharing IP addresses (such as revealing your network attachment location > to whoever gets the IP address), I don't see any huge ones. > > > On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba > > wrote: > > Alternatives can be explored for how to represent the > information provided by SDP, but the enumeration and testing of > potential endpoints within an offer-answer exchange is at the > core of ICE (RFC 5245), and is also a potential means for > demonstrating media authorization. If the Javascript limitations > on enumeration of physical or logical addresses can't be > overcome, we might have to live with server reflexive and > relayed endpoint identifiers (assuming that server reflexive and > relayed endpoint identifiers don't trigger similar concerns). > Replacing addresses with names could be done prior to the > offer/answer exchange but this might introduce vulnerabilities > (e.g. voice hammer attacks based on DNS cache poisoning). > ------------------------------------------------------------------------ > Date: Wed, 2 Feb 2011 16:09:48 -0800 > From: harald@alvestrand.no > To: rtc-web@alvestrand.no > Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a > signaling protocol? > > > On 02/02/11 11:19, Henry Sinnreich wrote: > > Is there some understanding on the list on how the IP > addresses in SDP can be reconciled with the USAF RFC 3424? > > Nit: UNSAF, not USAF. > > http://www.rfc-editor.org/rfc/rfc3424.txt > > “...a process whereby some > originating process attempts to determine or fix the address > (and > port) by which it is known - e.g. to be able to use address > data in > the protocol exchange, or to advertise a public address from > which it > will receive connections. > There are only heuristics and workarounds to attempt to > achieve this > effect; there is no 100% solution. Since NATs may also > dynamically > reclaim or readjust translations, "keep-alive" and periodic re- > polling may be required. Use of these workarounds MUST be > considered > transitional in IETF protocols, and a better architectural > solution > is being sought. The explicit intention is to deprecate any such > workarounds when sound technical approaches are available.” > > In our case, the answer that has proved workable is called STUN. > > > Obviously there is much more dead stuff in SDP besides using > the misleading IP addresses, but this seems to be a deep > architectural flaw. > There were some early attempts to do SDPng and we know today > much more: > http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07 > > Why not replace SDP, since it deals only with a/v codec > negotiation with a more general, standards based metadata > approach? > For example including Web conferencing displays and UI > control capabilities. > Of course such a new approach must be easily mapped to the > existing global SIP VoIP infrastructure. > > Or are the no “sound technical approaches” available at all? > > I'm all in favour of replacing SDP, but would not like to > require that before we can produce any output from this group. > > Justin's idea of sorting out what information we need and > specifying how that maps into SDP (just like is currently done > by Jingle) might be a reasonable approach that can allow us to > not fossilize SDP's misfeatures forever. > > Harald > > > _______________________________________________ RTC-Web mailing > list RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > > > > > _______________________________________________ RTC-Web mailing list > RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Sat Feb 5 10:10:21 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1763A69E1 for ; Sat, 5 Feb 2011 10:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWjnqxNVVvSg for ; Sat, 5 Feb 2011 10:10:20 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 443823A69E0 for ; Sat, 5 Feb 2011 10:10:20 -0800 (PST) Received: (qmail 20738 invoked by uid 0); 5 Feb 2011 18:13:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 5 Feb 2011 18:13:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=iIe96kT+e3+c8pTsxzI4DDNAdy+lK1UOJpCsj7ol+k9GDuuuwcmzMFUi6n4iIHUR4b9Fi73FNxDAQA1ey+HYgsNnNCG2ofVWF0a6AafMR4GZtOlXFSYzrqLCrC6WY3Ru; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Plmdo-0004kh-1C; Sat, 05 Feb 2011 11:13:48 -0700 From: "Richard Shockey" To: "'Elwell, John'" , References: In-Reply-To: Date: Sat, 5 Feb 2011 13:13:46 -0500 Message-ID: <000701cbc560$6e87d8c0$4b978a40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvCyjd+JF6W5cDSRQ+ZdtY9QWj7MwClgDmw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: Re: [dispatch] Basic Telephony SIP Interconnect Guideline Draft X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 18:10:21 -0000 I have privately informed the authors that if they wish this document to have a home they are more than welcome to bring it to the SIP Forum. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype-linkedin-facebook: rshockey101 http//www.sipforum.org -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, February 02, 2011 6:13 AM To: dispatch@ietf.org Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html If this is just profiling work, perhaps the SIP Forum would be a better venue. John _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Sun Feb 6 21:09:04 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E39E3A6CA1 for ; Sun, 6 Feb 2011 21:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhvWIHqLs+nw for ; Sun, 6 Feb 2011 21:09:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D2E2F3A6C9F for ; Sun, 6 Feb 2011 21:09:02 -0800 (PST) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p1758ucP000945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Feb 2011 00:09:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1297055342; bh=RUns+arfDQ/nsHB1Uv5D9wbfQIHkjLeo8MONFDbYCac=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SmB9DcvwcqNEX/dg26RIzbEsJNAIJVjfAg6Yi6sJZjtTBNMx6eaL5XryMTswk/8gZ /qwJP5tyX2WoVd9dT2YZve3kl7/6JygXCyc3awvRxG/UWCvbGosLP+3B7EabFwWdyP zRkxY5atwP7WhaSfJGM8/i4OGHXn8gkasyDCQXG4= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <069601cbc0a0$3b2f5850$b18e08f0$@packetizer.com> <051101cbc36c$2b4fde90$81ef9bb0$@packetizer.com> <4D4ABC27.5070801@cisco.com> In-Reply-To: <4D4ABC27.5070801@cisco.com> Date: Mon, 7 Feb 2011 00:08:31 -0500 Message-ID: <00aa01cbc685$13d46df0$3b7d49d0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA7Fy1vbvX3nVJZeZhtnW6LVnUIgHIr7arAoSLiZkCEqdA8JNYMROA Content-Language: en-us Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 05:09:04 -0000 Paul, The fact that, in practice, many of these values are changed is an issue. The fact that any scheme that relies on these existing attributes will also not allow tracking a call end-to-end when interworking with other session protocols (e.g., H.323) is an issue. We need something that allows us to side-step current implementation issues and also allows us to work cross-protocol. What I'd like to be able to do, also, is have something that works with 3xx and REFER. I'd like to have something that will allow conference correlation. We'd have to bend a few existing rules to make that happen. So, my opinion is that the best solution is to introduce a new identifier. As Mary noted, this has come up a few times before and I suspect it will again. I don't care with this identifier is in a separate header or a parameter of a header. It's all the same to me. I did have it in the Contact header, but folks wanted it as its own header. Paul > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, February 03, 2011 9:31 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 > > As I mentioned earlier in this thread, this approach is coming very > close to reinventing the dialog-id. > > The dialog-id consists of three parts: > - call-id > - from-tag > - to-tag > > All three are required to be globally unique when assigned, and the > combination is unique to a single dialog. If you omit the to-tag, then > the combination of call-id and from-tag identifies all early and final > dialogs that may arise as the result of a single dialog-establishing > request (such as INVITE) after it is forked. > > The call-id is normally reused, with a different from-tag, to retry > dialog establishment after a 3xx. > > Its my impression that some implementations violate some of the > uniqueness rules here, assuming that its not necessary for each of the > parts to be unique in order to get the combination to be unique. But of > course doing that means that some of the partial combinations won't be > unique. > > The existing rules for tags and callid won't give a way to do the > correlations that Paul J is looking for. But there is so much similarity > that I think it makes sense to consider some way to tie it all together. > For instance, perhaps there could be an optional "correlation-tag", > which is just the sender's from/to-tag from a related (e.g. by transfer) > dialog. Or maybe there could be multiple correlation-tags. > > We could also *think* (very carefully) about changing the rules for when > from-tags, to-tags, and callids are reused. (Even small changes have the > potential to break things.) > > Of course that all depends on SBCs not messing with the tags, and that > could be a problem. But any of these schemes depend on SBCs not messing > with *some* id. > > Thanks, > Paul > > On 2/3/2011 1:32 AM, Paul E. Jones wrote: > > Peter, > > > > The idea as currently presented is that A sends its UUID to B and B > > sends its UUID to A. A and B both compose the Session-ID locally for > > whatever purpose they might have for it. > > > > So, in debugging, you would look at the INVITE that goes out. There > > may be multiple messages coming back due to forking. One would use > > current approaches (e.g., Call-ID, tags) to relate a response with an > > initial request. While we didn't propose extracting the Session-ID > > directly from any single message, it can be constructed and used in > > logging, recording, etc. > > > > We could insert a UUID in the INVITE and a complete Session-ID in > > response messages. I have no objection to describing the procedure in > > that way, but I'm not sure how much value there is in doing that. It > > might make it easier to see the Session-ID more readily, but any > > application that might need to use it would already know one UUID > already. > > > > The uses of the Session-ID are several, including functions like > > logging, recording, and relating media flows to sessions (e.g., use in > > RTCP and RSVP). > > > > The reason for not using a single UUID is that, in real systems, call > > legs get joined/spliced/diced/chopped. A might call B and C might > > call B and a PBX managing B might join the call legs A and C together. > > In so doing, we have a new end-to-end call, but there may not be any > > session signaling on the wire. There would be a new INVITE sent from > > B's server (I assume), but we need to ensure that A and C have a > > common understanding as to what the new end-to-end Session-ID value > > is. By conveying A's UUID to C and C's UUID to A, each endpoint would > > know the end-to-end session has changed (device > > change) and could use that new value in RTCP, RSVP, logging, etc. > > Billing systems or logging systems could also record that change. > > > > I welcome any proposed changes to make this clearer, or changes that > > might make the Session-ID easier to use. We felt transmitting two > > UUID values was simple and consistent, but I can see how it might not > > be perceived as so simple by an external entity looking at the > exchanges on the wire. > > > > Paul > > > >> -----Original Message----- > >> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > >> Sent: Wednesday, February 02, 2011 11:42 AM > >> To: Paul E. Jones > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] draft-jones-ipmc-session-id-01 > >> > >> Hi, > >> > >> I find the lack of a some specific examples is leaving me with a > >> question I cannot answer by reading the spec (unless I missed > >> something). > >> > >> So in a dialog startup: > >> A sends Session-ID with just it's UUID in it. > >> Final endpoint B responds with the combined UUIDs in a Session-ID > >> header (it's own plus A's in sorted order) > >> > >> So in e.g. debugging - if I want to correlate the INVITE with the > >> response I am comparing a one UUID header with a two UUID header? > >> > >> I don't think that is a huge deal - although it seems a bit more > >> awkward than just having the initiators UUID used throughout. It > >> would be good to make the benefits of 2 UUIDs in a header very clear. > >> > >> Regards, > >> > >> Peter Musgrave > >> > >> On 2011-01-30, at 5:07 PM, Paul E. Jones wrote: > >> > >>> Folks, > >>> > >>> I just wanted to draw your attention to the revised Session ID draft > >>> we just submitted. Following the discussion we had on this topic > >>> previously, we introduced one important change: rather than using > >>> the Contact header, we introduce a new header to convey the UUID > >>> used by each endpoint that comprises the Session-ID. > >>> > >>> The revised draft is here: > >>> http://tools.ietf.org/html/draft-jones-ipmc-session-id > >>> > >>> We welcome any additional comments and input on a way to move this > >> forward. > >>> > >>> Paul > >>> > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Leon.Portman@nice.com Mon Feb 7 03:05:44 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A3D3A6D87 for ; Mon, 7 Feb 2011 03:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5VYOjSSPRqW for ; Mon, 7 Feb 2011 03:05:43 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 265BE3A6D85 for ; Mon, 7 Feb 2011 03:05:42 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 7 Feb 2011 13:05:45 +0200 From: Leon Portman To: "Shekh-Yusef, Rifaat (Rifaat)" , "dispatch@ietf.org" Date: Mon, 7 Feb 2011 13:05:45 +0200 Thread-Topic: [dispatch] SIP Action Referral charter proposal Thread-Index: Acu5B9e/tmH4PhHNQFurOMphWSklGANrvM6Q Message-ID: <07465C1D981ABC41A344374066AE1A2C38A354DC4B@TLVMBX01.nice.com> References: <6369CB70BFD88942B9705AC1E639A3382208FBB2B3@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A3382208FBB2B3@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP Action Referral charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 11:05:44 -0000 I see additional use cases where mechanism like this can be used in Contact= Center environment where agent's phone is controlled by CRM application in= order to answer, transfer or conference other agents and experts. Regards Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Shekh-Yusef, Rifaat (Rifaat) Sent: Friday, January 21, 2011 3:09 AM To: dispatch@ietf.org Subject: [dispatch] SIP Action Referral charter proposal Hi, The following is a charter proposal for the SIP Action Referral WG. While the SPLICES WG seems like a possible place for this work, the SIP Act= ion Referral has a wider scope than the Loosely Coupled UAs use case. We would appreciate any thoughts and comments on the charter proposal and o= n the SPLICES idea as a WG for this work. We would also appreciate any ideas for a name for the WG. Regards, Rifaat ----------------------------- Charter Proposal (version 1) Possible WG Names: Open for ideas=20 Hard phones often work in conjunction with software on other device, such a= s a soft phone on a PC. For example, a soft phone on the PC might want to a= nswer a phone call but use the user's speakerphone on their desk for the ca= ll instead of the soft phone. To do this, it would need to signal to the sp= eakerphone to answer the call. This working group will define a SIP extension that allows a SIP User Agent= to instruct another SIP User Agent to perform an action. An action is an e= vent or a series of events that modify the state of a UA at different level= s, e.g. SIP state, UI, etc. An action can be triggered either in the contex= t of an existing dialog or outside the context of any existing dialog. An a= ction is not necessarily tied to a SIP request. The following is a list example actions: Answer a call, mute or unmute a ca= ll, put the call on hold or take off, add or remove the call to conference = bridge.=20 The Working group will be a very short lived working group that will use fr= equent phone calls and IETF meetings to quickly progress a single specifica= tion. This working group will closely coordinate with the SPLICES working g= roup as this work seems to be applicable to their work.=20 Deliverables Nov 2011=A0=A0=A0 =A0Use Cases and Requirements to IESG as Informational RF= C Feb 2012 =A0 =A0 Protocol specification to IESG as PS _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jdrosen@jdrosen.net Tue Feb 8 06:48:37 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F109E3A67AC for ; Tue, 8 Feb 2011 06:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtoyi6T2cq-U for ; Tue, 8 Feb 2011 06:48:35 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.118]) by core3.amsl.com (Postfix) with ESMTP id 458113A67AB for ; Tue, 8 Feb 2011 06:48:34 -0800 (PST) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Pmorw-0003Ua-NO for dispatch@ietf.org; Tue, 08 Feb 2011 09:48:40 -0500 Message-ID: <4D5157CE.4080300@jdrosen.net> Date: Tue, 08 Feb 2011 09:48:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: 'DISPATCH list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Subject: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:48:37 -0000 Some of my colleagues from Skype and I have put together a draft which gives our thoughts on the scope of the protocols and functionality for enabling browser RTC. I've just submitted the draft, which you can find here: http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt Some of the key points: * keep it minimal * APIs for controlling behaviors of the various media components, with defaults for those that dont care * no SIP or Jingle; leave that to proprietary over websockets/HTTP * no ICE - just STUN. ICE can be a javascript library. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From adam@nostrum.com Tue Feb 8 08:35:30 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF2F3A681C for ; Tue, 8 Feb 2011 08:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFf+rGWdip1u for ; Tue, 8 Feb 2011 08:35:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AAA463A6819 for ; Tue, 8 Feb 2011 08:35:27 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p18GZVSp049247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 10:35:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D5170D3.9090505@nostrum.com> Date: Tue, 08 Feb 2011 10:35:31 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jonathan Rosenberg References: <4D5157CE.4080300@jdrosen.net> In-Reply-To: <4D5157CE.4080300@jdrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:35:30 -0000 I agree with the general architectural principles expressed in this document. I think the STUN-based approach for voice hammer avoidance is problematic for the purpose of legacy interoperation (e.g, Figure 2 with the right-hand-side replaced with a normal SIP Proxy/Registrar and normal SIP user agent), as few (if any?) deployed SIP user agents are likely to support this exchange. I believe this specific approach may need some tweaking. /a On 2/8/11 8:48 AM, Jonathan Rosenberg wrote: > Some of my colleagues from Skype and I have put together a draft which > gives our thoughts on the scope of the protocols and functionality for > enabling browser RTC. I've just submitted the draft, which you can > find here: > > http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt > > Some of the key points: > > * keep it minimal > * APIs for controlling behaviors of the various media components, with > defaults for those that dont care > * no SIP or Jingle; leave that to proprietary over websockets/HTTP > * no ICE - just STUN. ICE can be a javascript library. > > Thanks, > Jonathan R. From matthew.kaufman@skype.net Tue Feb 8 09:15:28 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591203A67F3 for ; Tue, 8 Feb 2011 09:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65c27ikMvgA3 for ; Tue, 8 Feb 2011 09:15:27 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 3A9AC3A67FD for ; Tue, 8 Feb 2011 09:15:26 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 1E5A17FD; Tue, 8 Feb 2011 18:15:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=4fWf4b1p1AMrnQ Yl8WaMH0K3o3U=; b=FVshPDhWGzeXpvMeN046uKfW2ken8QBjbNuqvxEDH4NEq+ a7eNOSOrXFCcHecvc9F+ZSvtTZScYo8z0eKWIUk2QZp0SYr67EDVnyEulbcQ0gFo xQM9BZA9l0IkDxBhml4xGVY29cgRuWebKy0hJNW8nI9LLUelhN+sHB9Bz/qGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=jJOJh3uubzAoWz4aaHNPvv y8zjGWLOT0J3GCOz03y+ULahdTusSxWC/9HDB1r5EicylbxVWbBSzesADGUT1XUZ mbLHRAThbAt6bC9D2ebyDlgLGIIIeSlWBrrXwaymyA3/0lw7gBLQr11ZZUGZwnpd +GQKmgwhR5HSB6eW3zLCs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1CEAE7F3; Tue, 8 Feb 2011 18:15:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E73243507CAE; Tue, 8 Feb 2011 18:15:32 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfxLs0KGsg9c; Tue, 8 Feb 2011 18:15:32 +0100 (CET) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 617B93507BB7; Tue, 8 Feb 2011 18:15:31 +0100 (CET) Message-ID: <4D517A30.7070508@skype.net> Date: Tue, 08 Feb 2011 09:15:28 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Roach References: <4D5157CE.4080300@jdrosen.net> <4D5170D3.9090505@nostrum.com> In-Reply-To: <4D5170D3.9090505@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:15:28 -0000 On 2/8/2011 8:35 AM, Adam Roach wrote: > I agree with the general architectural principles expressed in this > document. > > I think the STUN-based approach for voice hammer avoidance is > problematic for the purpose of legacy interoperation (e.g, Figure 2 > with the right-hand-side replaced with a normal SIP Proxy/Registrar > and normal SIP user agent), as few (if any?) deployed SIP user agents > are likely to support this exchange. I believe this specific approach > may need some tweaking. I agree that it interferes with legacy interop, however I see no way around it that doesn't allow a browser to be used inappropriately as a UDP-based attack vector behind a firewall. Existing SIP UAs can either be upgraded or sit behind a very simple SBC-like device that affirms the willingness to receive. Matthew Kaufman From hmmr@cisco.com Tue Feb 8 09:42:19 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC473A67E7 for ; Tue, 8 Feb 2011 09:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZryxEwmUfcq for ; Tue, 8 Feb 2011 09:42:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3AF683A67E3 for ; Tue, 8 Feb 2011 09:42:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoBAHMPUU2tJV2b/2dsb2JhbACWV45cc6AwmzWFWgSEe4oj Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 17:42:23 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p18HgNkS024100; Tue, 8 Feb 2011 17:42:23 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 11:42:23 -0600 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: Tue, 8 Feb 2011 11:42:21 -0600 Message-ID: In-Reply-To: <4D5157CE.4080300@jdrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] RTCWEB I-D with thoughts on the framework Thread-Index: AcvHn0wzwRkOmxdOSIC45G6+p2Ti0QAFds/Q References: <4D5157CE.4080300@jdrosen.net> From: "Mike Hammer (hmmr)" To: "Jonathan Rosenberg" , "DISPATCH list" X-OriginalArrivalTime: 08 Feb 2011 17:42:23.0058 (UTC) FILETIME=[8ABA0320:01CBC7B7] Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:42:19 -0000 Jonathan, The diagram makes this look like a media gateway control protocol, depending on where the feature set resides. Also, how would the Web interface differ from the stimulus protocols of the past? How much of this is meta-packaging of blobs passed between browser and its server? Seems to be half-way between a completely proprietary interface, and one where every message and parameter is defined. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, February 08, 2011 9:49 AM To: 'DISPATCH list' Subject: [dispatch] RTCWEB I-D with thoughts on the framework Some of my colleagues from Skype and I have put together a draft which=20 gives our thoughts on the scope of the protocols and functionality for=20 enabling browser RTC. I've just submitted the draft, which you can find=20 here: http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt Some of the key points: * keep it minimal * APIs for controlling behaviors of the various media components, with=20 defaults for those that dont care * no SIP or Jingle; leave that to proprietary over websockets/HTTP * no ICE - just STUN. ICE can be a javascript library. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From henry.sinnreich@gmail.com Tue Feb 8 10:01:19 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6943A679F for ; Tue, 8 Feb 2011 10:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfrSlToJESf5 for ; Tue, 8 Feb 2011 10:01:18 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B6F683A672E for ; Tue, 8 Feb 2011 10:01:18 -0800 (PST) Received: by gyd12 with SMTP id 12so2679999gyd.31 for ; Tue, 08 Feb 2011 10:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=smOZrWW5hxLUno8HAJF/yiDKtmvYClu2eyucEGZL1aQ=; b=j+yTJ/UhA4UEYEEuYBjz+pMR4jimUjO/jSSwkSsWU/7NTPpgEcGerZEGFd9ZSavt3E OIrhL5cDXOSWHSFD8/k2bYhI576NQu2X7rjQge+IPzst5nX5X+PqSIqI64WE7sL8LLFl 8Bg9VfDcoTiBwDUP/oqv2EWgMzhuvbHKqytms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=i03hwFVNO5C2RX5fjfnx4Vtyc4LPse3Rn6mD+SC0aGJc7H80wz9QAI8xhXuZ9jkbZB zPkvVFkXh9/k0n+/sTtVgeikCom3l7gVhkw6SkF41Ese2C2+4D9AvRSDnL7VPEEe7jXg byYRA1XZG6DQSnNFnr7YL+JFAaaFYHpDRV+G8= Received: by 10.150.189.19 with SMTP id m19mr373046ybf.186.1297188085469; Tue, 08 Feb 2011 10:01:25 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id v8sm2176572ybe.13.2011.02.08.10.01.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 10:01:23 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 08 Feb 2011 12:01:20 -0600 From: Henry Sinnreich To: Matthew Kaufman , Adam Roach Message-ID: Thread-Topic: [dispatch] RTCWEB I-D with thoughts on the framework Thread-Index: AcvHujBl2yb2EKLy7ESmCvWGXxf9ig== In-Reply-To: <4D517A30.7070508@skype.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:01:19 -0000 +1 I fully agree with Matthew. Thanks, Henry On 2/8/11 11:15 AM, "Matthew Kaufman" wrote: > On 2/8/2011 8:35 AM, Adam Roach wrote: >> I agree with the general architectural principles expressed in this >> document. >> >> I think the STUN-based approach for voice hammer avoidance is >> problematic for the purpose of legacy interoperation (e.g, Figure 2 >> with the right-hand-side replaced with a normal SIP Proxy/Registrar >> and normal SIP user agent), as few (if any?) deployed SIP user agents >> are likely to support this exchange. I believe this specific approach >> may need some tweaking. > > I agree that it interferes with legacy interop, however I see no way > around it that doesn't allow a browser to be used inappropriately as a > UDP-based attack vector behind a firewall. > > Existing SIP UAs can either be upgraded or sit behind a very simple > SBC-like device that affirms the willingness to receive. > > Matthew Kaufman > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Tue Feb 8 10:39:04 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82D33A67E1 for ; Tue, 8 Feb 2011 10:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwyaIHPI1rlM for ; Tue, 8 Feb 2011 10:39:03 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 6A66D3A6802 for ; Tue, 8 Feb 2011 10:39:02 -0800 (PST) Received: by yie19 with SMTP id 19so2713770yie.31 for ; Tue, 08 Feb 2011 10:39:09 -0800 (PST) Received: by 10.151.13.16 with SMTP id q16mr346933ybi.264.1297190349253; Tue, 08 Feb 2011 10:39:09 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id v6sm544155ybk.8.2011.02.08.10.39.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Feb 2011 10:39:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <4D5157CE.4080300@jdrosen.net> Date: Tue, 8 Feb 2011 13:39:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2D87A9BA-C980-4E04-98A9-6A7C29516BC5@magorcorp.com> References: <4D5157CE.4080300@jdrosen.net> To: Jonathan Rosenberg X-Mailer: Apple Mail (2.1082) Cc: 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:39:04 -0000 I like the draft and think this is a useful framework. Regards,=20 Peter Musgrave On 2011-02-08, at 9:48 AM, Jonathan Rosenberg wrote: > Some of my colleagues from Skype and I have put together a draft which = gives our thoughts on the scope of the protocols and functionality for = enabling browser RTC. I've just submitted the draft, which you can find = here: >=20 > http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt >=20 > Some of the key points: >=20 > * keep it minimal > * APIs for controlling behaviors of the various media components, with = defaults for those that dont care > * no SIP or Jingle; leave that to proprietary over websockets/HTTP > * no ICE - just STUN. ICE can be a javascript library. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > Skype Chief Technology Strategist > jdrosen@skype.net http://www.skype.com > jdrosen@jdrosen.net http://www.jdrosen.net >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Tue Feb 8 10:53:23 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B503A6824 for ; Tue, 8 Feb 2011 10:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAHHAjViJJvl for ; Tue, 8 Feb 2011 10:53:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8E7E33A681C for ; Tue, 8 Feb 2011 10:53:21 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p18IrRIO061743 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 12:53:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D519127.4080705@nostrum.com> Date: Tue, 08 Feb 2011 12:53:27 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matthew Kaufman References: <4D5157CE.4080300@jdrosen.net> <4D5170D3.9090505@nostrum.com> <4D517A30.7070508@skype.net> In-Reply-To: <4D517A30.7070508@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:53:23 -0000 On 2/8/11 11:15 AM, Matthew Kaufman wrote: > On 2/8/2011 8:35 AM, Adam Roach wrote: >> I agree with the general architectural principles expressed in this >> document. >> >> I think the STUN-based approach for voice hammer avoidance is >> problematic for the purpose of legacy interoperation (e.g, Figure 2 >> with the right-hand-side replaced with a normal SIP Proxy/Registrar >> and normal SIP user agent), as few (if any?) deployed SIP user agents >> are likely to support this exchange. I believe this specific approach >> may need some tweaking. > > I agree that it interferes with legacy interop, however I see no way > around it that doesn't allow a browser to be used inappropriately as a > UDP-based attack vector behind a firewall. > > Existing SIP UAs can either be upgraded or sit behind a very simple > SBC-like device that affirms the willingness to receive. > If a device can be upgraded to support this new behavior, I agree that it solves the issue. But such upgrades are often impractical or impossible. For example, I doubt I'm ever going to see another software update for the 6-year-old SIP phone on my desk; support for it reached EOL a while ago, and it has been superseded by newer hardware. In any case, I think you can determine willingness to receive through other mechanisms. For example, receiving a media stream from a remote location is probably a pretty good indication that the remote location is willing to engage in a media exchange. There may be other mechanisms to achieve the desired security properties without sacrificing interoperability with things that just do normal, stock RTP. I think it is premature to dismiss them out of hand. /a From adam@nostrum.com Tue Feb 8 11:15:57 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DD43A683C for ; Tue, 8 Feb 2011 11:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwawFLODrnx0 for ; Tue, 8 Feb 2011 11:15:57 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 819073A6835 for ; Tue, 8 Feb 2011 11:15:56 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p18JFuLk063731 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 13:15:56 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D51966B.1040109@nostrum.com> Date: Tue, 08 Feb 2011 13:15:55 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <4D5157CE.4080300@jdrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH list Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:15:57 -0000 On 2/8/11 11:42 AM, Mike Hammer (hmmr) wrote: > Jonathan, > > The diagram makes this look like a media gateway control protocol, > depending on where the feature set resides. > > Also, how would the Web interface differ from the stimulus protocols of > the past? It could be as low-level as a stimulus protocol, or as high-level as: { "action":"call", "phone_number":"+12145550107", "my_addresses":[{"ip":"192.0.2.7","port":53872}] } Or anything in between. That's kind of the point of relegating as much behavior as possible to Javascript. It lets people do whatever suits their application. If we defined what this looked like, it would be far more constraining on the web-based applications. > How much of this is meta-packaging of blobs passed between browser and > its server? However much the application designer wants. > Seems to be half-way between a completely proprietary interface, and one > where every message and parameter is defined. I think you've missed the key behavior that this draft is attempting to promote. The browser will run javascript downloaded from the server, and use it to talk to the server. Exactly how these things communicate with each other is a private matter to be determined by the application developer. The parallel to make is the instant-messaging and presence functionality you see in certain web pages (Facebook and GMail to name a couple of examples). The protocol that the GMail chat web widget uses to talk to the GMail chat servers is something that Google invented themselves out of whole cloth. And they can change it whenever they want. And everything still works. It interoperates with other XMPP systems just fine, too, since the GMail servers have an XMPP interface that talks to the rest of the world. To put it into a diagram: +-----------+ +-----------+ | Web/ | | | | XMPP | XMPP | XMPP | | |-------------| | | Server | | Server | | | | | +-----------+ +-----------+ / \ / \ / \ XMPP / \ / Proprietary over \ / HTTP/Websockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| | | +-----------+ | XMPP | +-----------+ | Client | | | | | | | +-----------+ | Browser | | | | | +-----------+ Does that look familiar? This has been successfully deployed at scale, and it works great. I can't imagine why it wouldn't work just fine for real-time media. /a From hmmr@cisco.com Tue Feb 8 11:53:21 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5673A6835 for ; Tue, 8 Feb 2011 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBd5L-bCTzTp for ; Tue, 8 Feb 2011 11:53:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 426BD3A67C3 for ; Tue, 8 Feb 2011 11:53:19 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoBAOwtUU2tJV2d/2dsb2JhbACWW45cc6FbmzuFWgSEe4oj Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 19:53:25 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p18JrPiw022940; Tue, 8 Feb 2011 19:53:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 13:53:24 -0600 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: Tue, 8 Feb 2011 13:53:24 -0600 Message-ID: In-Reply-To: <4D51966B.1040109@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] RTCWEB I-D with thoughts on the framework Thread-Index: AcvHxKNlPEIhEdi1QQu+KKVDr45MuwABHSpQ References: <4D5157CE.4080300@jdrosen.net> <4D51966B.1040109@nostrum.com> From: "Mike Hammer (hmmr)" To: "Adam Roach" X-OriginalArrivalTime: 08 Feb 2011 19:53:24.0955 (UTC) FILETIME=[D8C84AB0:01CBC7C9] Cc: DISPATCH list Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:53:21 -0000 Adam, So, this effectively devolves to a mechanism to push an application to the browser and have it then run. This seems to argue for most of how it works to be proprietary, and just enough meta-packaging=20 to let the browser know that it is a real-time blob and how to hook into the platform hardware. Not saying I disagree, just making some observations. Just gauging the amount of standards definition here. Mike -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, February 08, 2011 2:16 PM To: Mike Hammer (hmmr) Cc: Jonathan Rosenberg; DISPATCH list Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework On 2/8/11 11:42 AM, Mike Hammer (hmmr) wrote: > Jonathan, > > The diagram makes this look like a media gateway control protocol, > depending on where the feature set resides. > > Also, how would the Web interface differ from the stimulus protocols of > the past? It could be as low-level as a stimulus protocol, or as high-level as: { "action":"call", "phone_number":"+12145550107", "my_addresses":[{"ip":"192.0.2.7","port":53872}] } Or anything in between. That's kind of the point of relegating as much=20 behavior as possible to Javascript. It lets people do whatever suits=20 their application. If we defined what this looked like, it would be far more constraining=20 on the web-based applications. > How much of this is meta-packaging of blobs passed between browser and > its server? However much the application designer wants. > Seems to be half-way between a completely proprietary interface, and one > where every message and parameter is defined. I think you've missed the key behavior that this draft is attempting to=20 promote. The browser will run javascript downloaded from the server, and use it to talk to the server. Exactly how these things communicate with=20 each other is a private matter to be determined by the application=20 developer. The parallel to make is the instant-messaging and presence functionality you see in certain web pages (Facebook and GMail to name a couple of=20 examples). The protocol that the GMail chat web widget uses to talk to=20 the GMail chat servers is something that Google invented themselves out=20 of whole cloth. And they can change it whenever they want. And=20 everything still works. It interoperates with other XMPP systems just=20 fine, too, since the GMail servers have an XMPP interface that talks to=20 the rest of the world. To put it into a diagram: +-----------+ +-----------+ | Web/ | | | | XMPP | XMPP | XMPP | | |-------------| | | Server | | Server | | | | | +-----------+ +-----------+ / \ / \ / \ XMPP / \ / Proprietary over \ / HTTP/Websockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| | | +-----------+ | XMPP | +-----------+ | Client | | | | | | | +-----------+ | Browser | | | | | +-----------+ Does that look familiar? This has been successfully deployed at scale,=20 and it works great. I can't imagine why it wouldn't work just fine for=20 real-time media. /a From adam@nostrum.com Tue Feb 8 12:02:17 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CA53A672E for ; Tue, 8 Feb 2011 12:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEoJ1FESKzZh for ; Tue, 8 Feb 2011 12:02:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8A7B33A680A for ; Tue, 8 Feb 2011 12:02:16 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p18K2L6R067722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 14:02:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D51A14D.2070404@nostrum.com> Date: Tue, 08 Feb 2011 14:02:21 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <4D5157CE.4080300@jdrosen.net> <4D51966B.1040109@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH list Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:02:17 -0000 On 2/8/11 1:53 PM, Mike Hammer (hmmr) wrote: > This seems to argue for most of how it works to be proprietary... Yes -- as proprietary as the internal function calls inside an application. > ...and just enough meta-packaging to let the browser know that it is a real-time blob and how to hook into > the platform hardware. There are a few more tasks than that -- you've got to be able to send & receive UDP (or at least RTP over UDP); you need to be able to collect candidate IP addresses and ports; and you need to access more from the platform than just hardware (e.g., audio and/or video codecs, encryption support, etc). But, yes, defined this way, it's a relatively small amount of work, with potentially huge payoffs. /a From xavier.marjou@gmail.com Wed Feb 9 01:06:34 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B0F3A695A for ; Wed, 9 Feb 2011 01:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHoAZtb+AVdU for ; Wed, 9 Feb 2011 01:06:33 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 38E813A6959 for ; Wed, 9 Feb 2011 01:06:33 -0800 (PST) Received: by vws7 with SMTP id 7so3652332vws.31 for ; Wed, 09 Feb 2011 01:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=Vp1cUDCFIkFTyAkQzWzl4wRuCds/jq3tUyWB/THsOYs=; b=POBOMgDAN4GNMeKnoqQyDo7tWv6sxwoIQKVaIMO7pHeHBREFZq6z1Ta99z/9RWc1lm p5m8XsJSy28s/wJH0qk2euQhgIXOrl0e2whuF0orkEaXDV5q3xQEUg2czh6uKCwXTqsN 5K9RCpsJM2kUdWp33WBnPHffPvQvVCG+9zeaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=gQ2IB9tiIfS/aslURxLBrY/JsGBFw/1MSTxicmdqrGmwPOmnGnP44qAgCI0C9FWn36 1b2HAVbWzWEtoeMYijkTIHeBo21YoAW7MyUWhlWzO4ZksMj9rq017dnDXz79T2FXq2MM XgwMSyafmzXx0ex7UITGu8hVD/3TAil0ph7BM= MIME-Version: 1.0 Received: by 10.220.194.71 with SMTP id dx7mr5057230vcb.144.1297242395409; Wed, 09 Feb 2011 01:06:35 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.220.184.11 with HTTP; Wed, 9 Feb 2011 01:06:35 -0800 (PST) Date: Wed, 9 Feb 2011 10:06:35 +0100 X-Google-Sender-Auth: Pmy2TX4FyRKPq1R_ywa3i8aembo Message-ID: From: Xavier Marjou To: DISPATCH list Content-Type: multipart/alternative; boundary=90e6ba4fc6fe2a7df7049bd5c8f9 Cc: rtc-web@alvestrand.no Subject: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 09:06:34 -0000 --90e6ba4fc6fe2a7df7049bd5c8f9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-in= terwk-reqs-00.txt Cheers, Xavier and Jean-Fran=E7ois --90e6ba4fc6fe2a7df7049bd5c8f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

We have posted a draft about interworking requiremen= ts between RTC-Web and SIP-RTP.

Cheers,
Xavier and Jean-Fran=E7ois --90e6ba4fc6fe2a7df7049bd5c8f9-- From henry.sinnreich@gmail.com Wed Feb 9 09:36:42 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3431D3A67FA for ; Wed, 9 Feb 2011 09:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me8JkfH9A4pC for ; Wed, 9 Feb 2011 09:36:41 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 150EB3A67A5 for ; Wed, 9 Feb 2011 09:36:41 -0800 (PST) Received: by gyd12 with SMTP id 12so204412gyd.31 for ; Wed, 09 Feb 2011 09:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type; bh=KJQjiD60WF0eGlOUELPCs8jZZDC9ZlsXqi5dc6kPwx8=; b=bhKTYGmrIc6SS41/2sO0MmU9jYKFQ+CzjHSZdCp6kjziUiG/SitAtFjWp0f19Aeepf imfEC5++J1NvfyaKfmsk7T/tVq7famYFqLqT6cHV1J/mVBGqaH4P+jXz6K/VAB9Rxvbt ePO8v1BKMlOBapSBaGM1b7VMiOJP+ie+rB+7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=QVi+A7viOCmML+9mI//0HyJNNaYU5ny8FL5JYh/SIuJTMSVgJjHE/sjH6iLZpZTvqn YIDAW9UssUIbj6k2Gqy5vehCZs3tN7B/H93HBQPnvbRRtoLe9fiqy0y5Bs62tN9KluB9 U6VM8R9JpVchrJaUIYrmrY151ZQMTCuMR37Ss= Received: by 10.101.17.11 with SMTP id u11mr9588506ani.186.1297273009251; Wed, 09 Feb 2011 09:36:49 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id 35sm617806ano.31.2011.02.09.09.36.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 09:36:47 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 11:36:45 -0600 From: Henry Sinnreich To: Xavier Marjou , DISPATCH list Message-ID: Thread-Topic: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvIf+uku7oJWRU4xkuVguAnCsVjDQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3380096207_4708939" Cc: rtc-web@alvestrand.no Subject: Re: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:36:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3380096207_4708939 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way it allows interworking with SIP-RTP applications both at the signalling and media level. Please help me understand how this and the other requirements do not crippl= e the whole concept of the RTC-Web (innovation based on simplicity and flexibility) by making it just another extension of legacy telecom design? Or did the authors mean requirements for gateways only? Thanks, Henry On 2/9/11 3:06 AM, "Xavier Marjou" wrote= : > Hi, >=20 > We have posted a draft about interworking requirements between RTC-Web an= d > SIP-RTP. > http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-= inter > wk-reqs-00.txt >=20 > Cheers, > Xavier and Jean-Fran=E7ois >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --B_3380096207_4708939 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [dispatch] RTC-Web I-D about interworking between RTC-Web and SI= P-RTP   GENERIC-REQ-1  The [RTC-Web] solution MUST be designe= d in a such way
            &nb= sp;     it allows interworking with SIP-RTP applica= tions both
            &nb= sp;     at the signalling and media level.

Please help me understand how this and the other requirements do not crippl= e the whole concept of the RTC-Web (innovation based on simplicity and flexi= bility) by making it just another extension of legacy telecom design?

Or did the authors mean requirements for gateways only?

Thanks, Henry

On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou@orange-ftgroup.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Hi,

We have posted a draft about interworking requirements between RTC-Web and = SIP-RTP.
http://www.ietf.org/internet-drafts/draft-marjou= -dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt

Cheers,
Xavier and Jean-François

__________________________= _____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
--B_3380096207_4708939-- From mary.ietf.barnes@gmail.com Wed Feb 9 09:49:39 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7773A6846 for ; Wed, 9 Feb 2011 09:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgvhkofqXRoY for ; Wed, 9 Feb 2011 09:49:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C2C1A3A67A5 for ; Wed, 9 Feb 2011 09:49:37 -0800 (PST) Received: by ywk9 with SMTP id 9so213803ywk.31 for ; Wed, 09 Feb 2011 09:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=fw6UYA2Tx9DP42mykU3ana7tuKOMpSl2pAy4dPxq8Uo=; b=M3oS0PjBqlUcmtYBJfuHz8q7ayYqkeJaiNqGd51Wvzec08UYh2DGZ/QiFpan7fFCs9 e5FsT7fyhErE82MmQ1LVrGxFVsxddd1JJNqOuR1MKOppPP6pxbTWEVjoICXi4KZn1+x3 wo7RYVOdQOyNPxJU0MMrN2HvZm0IG0ifKu8HU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=PpaIQS7nrrO+I09KeK0I5au/e6MsDqh1J2awPKfshrEPEMvcsKeRtOChHOx+ZFcCWs 8TROp1pON2TIdfvbyO4FCkG06kx4bhQSZtP37ZVkx8Da2ayGU2bw63ZdI+AXy9LNXpxz GNCvfZBl4BsMONdnwsIqt96E70qvJ/yDC0MYk= MIME-Version: 1.0 Received: by 10.236.103.180 with SMTP id f40mr5459506yhg.0.1297273787292; Wed, 09 Feb 2011 09:49:47 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 9 Feb 2011 09:49:47 -0800 (PST) Date: Wed, 9 Feb 2011 11:49:47 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=0023543a2748449d76049bdd1724 Cc: rai-ads@tools.ietf.org Subject: [dispatch] Summary: Topics for IETF-80 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:49:39 -0000 --0023543a2748449d76049bdd1724 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, The following two topics will be allocated agenda time during the f2f session in Prague: 1) Q4S: (Updated) Charter: http://www.ietf.org/mail-archive/web/dispatch/current/msg03376.html Related document: http://datatracker.ietf.org/doc/draft-aranda-dispatch-q4s/ 2) Reason header in responses: http://www.ietf.org/mail-archive/web/dispatch/current/msg03296.html Most recent document (UPDATES RFC 3326): http://datatracker.ietf.org/doc/draft-jesske-dispatch-update3326-reason-responses/ In addition, the following topics have been dispatched (i.e., the work for these items to move forward has been completed in the DISPATCH WG): 1) RTCWEB: http://www.ietf.org/mail-archive/web/dispatch/current/msg03171.html An official Bof has been approved for this topic: http://trac.tools.ietf.org/bof/trac/#RAI 2) VIPR: http://www.ietf.org/mail-archive/web/dispatch/current/msg03300.html Consensus for the chartering of this work. The most recent charter has been forwarded to ADs to progress. An adhoc DISPATCH session is planned (since the WG will not be chartered prior to IETF-80). 3) SIP Action Referral: http://www.ietf.org/mail-archive/web/dispatch/current/msg03211.html Work item moved to SPLICES WG. * * * * 4) SIP Interconnect guidelines (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html The only responses were from folks that felt this would be appropriate for an organization such SIP Forum as long as it remains a profile - i.e., if the work item requires protocol changes then it is not appropriate for a forum to take this on. The following topics require more discussion and WG feedback in order to determine the best way forward: 1) 3892bis (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03162.html There's been very little discussion. However, if there is interest this work item likely needs to go through SIPCORE. 2) Restful API for ACH (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03212.html There were two responses as to the interest in this work item, in particular whether folks would implement this: one indicated it was too late and there is one individual interested in this work item. Thus, at this point, there does not appear to be enough interest in moving this forward. 3) End-to-End Session Identification (*): http://www.ietf.org/mail-archive/web/dispatch/current/msg03321.html Based on ML discussion, there is still Interest in a "Session ID" solution. Group needs to decide exactly what problem they want to solve (i.e., need a clear problem statement) and define the scope of the solution (e.g., general, specific deployment scenarios, etc.). 4) Media server overload: http://www.ietf.org/mail-archive/web/dispatch/current/msg03242.html Needs additional WG discussion and clarification of problem to be solved and scope thereof. Note, that there are additional threads of discussion on the SIPREC and MEDIACTRL WG mailing lists: http://www.ietf.org/mail-archive/web/siprec/current/msg01411.html http://www.ietf.org/mail-archive/web/mediactrl/current/msg01691.html Regards, Mary DISPATCH WG co-chair --0023543a2748449d76049bdd1724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

The following two topics will be allocate= d agenda time during the f2f session in Prague:

1) Q4S:=A0


In addition, the following topics = have been dispatched (i.e., the work for these items to move forward has be= en completed in the DISPATCH WG):

An official Bof has been approved for this topic:

Consensus for the chartering of this work. =A0The most=A0recent charte= r has been forwarded to ADs to progress. An adhoc DISPATCH session is plann= ed (since the WG will not be chartered prior to IETF-80). =A0=A0

Work item moved to SPLICES WG.=A0=A0




There's been very little discussion. =A0However, if there is inter= est this work item likely needs to go through SIPCORE.=A0

There were two responses as to the interest in this work item, in part= icular whether folks would implement this: one indicated it was too late an= d there is one individual interested in this work item. =A0Thus, at this po= int, there does not appear to be enough interest in moving this forward.=A0=

3) End-to-End Session Identification (*= ):=A0=A0http://www.ietf.org/mail-archive/web/dispatc= h/current/msg03321.html
Based on ML discussion, t= here is still Interest in a "Session ID" solution. =A0Group needs= to decide exactly what problem they want to solve (i.e., need a clear prob= lem statement) and define the scope of the solution (e.g., general, specifi= c deployment scenarios, etc.). =A0

Needs additional WG discussion and clarification of problem to be solv= ed and scope thereof. Note, that there are additional threads of discussion= on the SIPREC and MEDIACTRL WG mailing lists:


Regards,
Mary
DISPATCH WG co-chair

=












=A0


=A0





--0023543a2748449d76049bdd1724-- From singer@apple.com Wed Feb 9 10:00:37 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DE53A67BD for ; Wed, 9 Feb 2011 10:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98ItaQWolztu for ; Wed, 9 Feb 2011 10:00:36 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C91F73A67A5 for ; Wed, 9 Feb 2011 10:00:36 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id EB804D105684; Wed, 9 Feb 2011 10:00:46 -0800 (PST) X-AuditID: 11807130-b7b3cae00000405d-db-4d52d64e3866 Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay11.apple.com (Apple SCV relay) with SMTP id 69.8A.16477.E46D25D4; Wed, 9 Feb 2011 10:00:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-172--1007816749 From: David Singer In-Reply-To: Date: Wed, 9 Feb 2011 10:00:46 -0800 Message-Id: References: To: Henry Sinnreich X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: rtc-web@alvestrand.no, DISPATCH list , Xavier Marjou Subject: Re: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:00:37 -0000 --Apple-Mail-172--1007816749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 well, reading it on its face, as long as we have an architecture which = one *can* instantiate a component for the signalling that does SIP and a = component for media-transfer that does RTP, and so on, this requirement = is met. And I would have thought that yes, we would agree the = architecture should make that possible. whether we choose those components as a baseline set to implement is = much more a debate, I'd say. On Feb 9, 2011, at 9:36 , Henry Sinnreich wrote: > GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way > it allows interworking with SIP-RTP applications = both > at the signalling and media level. >=20 > Please help me understand how this and the other requirements do not = cripple the whole concept of the RTC-Web (innovation based on simplicity = and flexibility) by making it just another extension of legacy telecom = design? >=20 > Or did the authors mean requirements for gateways only? >=20 > Thanks, Henry >=20 > On 2/9/11 3:06 AM, "Xavier Marjou" = wrote: >=20 >> Hi, >>=20 >> We have posted a draft about interworking requirements between = RTC-Web and SIP-RTP. >> = http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-i= nterwk-reqs-00.txt >>=20 >> Cheers, >> Xavier and Jean-Fran=E7ois >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch David Singer Multimedia and Software Standards, Apple Inc. --Apple-Mail-172--1007816749 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 well, = reading it on its face, as long as we have an architecture which one = *can* instantiate a component for the signalling that does SIP and a = component for media-transfer that does RTP, and so on, this requirement = is met.  And I would have thought that yes, we would agree the = architecture should make that possible.

whether we = choose those components as a baseline set to implement is much more a = debate, I'd say.

On Feb 9, 2011, at 9:36 , Henry = Sinnreich wrote:

  GENERIC-REQ-1  The [RTC-Web] = solution MUST be designed in a such way
=             &n= bsp;     it allows interworking with SIP-RTP = applications both
=             &n= bsp;     at the signalling and media level.

Please help me understand how this and the other requirements do not = cripple the whole concept of the RTC-Web (innovation based on simplicity = and flexibility) by making it just another extension of legacy telecom = design?

Or did the authors mean requirements for gateways only?

Thanks, Henry

On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou@orang= e-ftgroup.com> wrote:

Hi,

We have posted a draft about interworking requirements between RTC-Web = and SIP-RTP.
http://www.ietf.org/internet-drafts/draft-marj= ou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt

Cheers,
Xavier and Jean-Fran=E7ois

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.iet= f.org/mailman/listinfo/dispatch

David Singer
Multimedia and = Software Standards, Apple = Inc.

= --Apple-Mail-172--1007816749-- From xavier.marjou@gmail.com Wed Feb 9 11:26:21 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAE03A6833 for ; Wed, 9 Feb 2011 11:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU2dVwKBb4Pl for ; Wed, 9 Feb 2011 11:26:19 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 694413A67F0 for ; Wed, 9 Feb 2011 11:26:19 -0800 (PST) Received: by vxi40 with SMTP id 40so266164vxi.31 for ; Wed, 09 Feb 2011 11:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FM52OsLVoowAcYZQcUaDB25DukeQhuBh9JWTQePDwac=; b=LrutR+c/8unnxW3h4/t2qOZeMZt3ARPwac4cXHevLP9nUJ3yisnJHr7ppXylQ8vD3A gMwLxwVGcznDa3u7tCO+lv+SA/wdN20y5OkCsEyrxfHIoBFuuW9p+zhrjrTgNusvg0De 5DQoEwKConWgdQCXbwsPWX4k3ntwC9BN0VLeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rXHtNkre1+rWHmfsPQSart6ywkh435XBubt7cwsyZ2V4VD26WUbt0kEYKrHEjYCb3J HYzta2viHrHZ/Eau3Qm9OXNsiLZMwegH4JZpRNjs1KVxRcycBfR/IdbZIplWYxotYZEA rwkZINGTwQq3pBCNQDtrDWN9G1oRdGYZ6mCPg= MIME-Version: 1.0 Received: by 10.220.194.1 with SMTP id dw1mr5255823vcb.179.1297279588951; Wed, 09 Feb 2011 11:26:28 -0800 (PST) Received: by 10.220.184.11 with HTTP; Wed, 9 Feb 2011 11:26:28 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Feb 2011 20:26:28 +0100 Message-ID: From: Xavier Marjou To: Henry Sinnreich Content-Type: multipart/alternative; boundary=90e6ba4fc11212e93d049bde71c3 Cc: rtc-web@alvestrand.no, DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:26:21 -0000 --90e6ba4fc11212e93d049bde71c3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Hi Henry, These requirements certainly do not want to cripple innovation (RTC-Web). They rather want to catch attention so that RTC-Web is designed in a way it can also work with existing SIP-RTP devices. Cheers, Xavier On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich wrote: > GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way > it allows interworking with SIP-RTP applications both > at the signalling and media level. > > Please help me understand how this and the other requirements do not > cripple the whole concept of the RTC-Web (innovation based on simplicity = and > flexibility) by making it just another extension of legacy telecom design= ? > > Or did the authors mean requirements for gateways only? > > Thanks, Henry > > > On 2/9/11 3:06 AM, "Xavier Marjou" > wrote: > > Hi, > > We have posted a draft about interworking requirements between RTC-Web an= d > SIP-RTP. > > http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-= interwk-reqs-00.txt > > Cheers, > Xavier and Jean-Fran=E7ois > > ------------------------------ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > > --90e6ba4fc11212e93d049bde71c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Hi Henry,

These requirement= s certainly do not want to cripple innovation (RTC-Web).=A0
They = rather want to catch attention so that RTC-Web is designed in a way it can = also work with existing SIP-RTP devices.

Cheers,
Xavier

On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich <henry.sinnreich@gmail.co= m> wrote:
=A0=A0GENERIC-REQ-1 =A0The [RTC-Web] solution MUST be designed = in a such way
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0it allows interworkin= g with SIP-RTP applications both
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0at the signalling and= media level.

Please help me understand how this and the other requirements do not crippl= e the whole concept of the RTC-Web (innovation based on simplicity and flex= ibility) by making it just another extension of legacy telecom design?

Or did the authors mean requirements for gateways only?

Thanks, Henry


On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou@orange-ftgroup.co= m> wrote:

Hi,

We have posted a draft about interworking requirements between RTC-Web and = SIP-RTP.
http://www.ietf.org/interne= t-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt

Cheers,
Xavier and Jean-Fran=E7ois

_= ______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web


--90e6ba4fc11212e93d049bde71c3-- From Borilin@spiritdsp.com Wed Feb 9 11:46:02 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EF93A69CE for ; Wed, 9 Feb 2011 11:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CCi6v+NY9fI for ; Wed, 9 Feb 2011 11:46:01 -0800 (PST) Received: from mail3.spiritdsp.com (mail3.spiritdsp.com [85.13.214.194]) by core3.amsl.com (Postfix) with ESMTP id C68EB3A69C2 for ; Wed, 9 Feb 2011 11:46:00 -0800 (PST) Received: from mailsrv.spiritcorp.com (mailsrv.spiritcorp.com [192.168.125.13]) by mail3.spiritdsp.com (8.14.3/8.14.3) with ESMTP id p19Jk7ga090311; Wed, 9 Feb 2011 22:46:07 +0300 (MSK) (envelope-from Borilin@spiritdsp.com) Received: from mailsrv.spiritcorp.com ([192.168.125.13]) by mailsrv.spiritcorp.com ([192.168.125.13]) with mapi; Wed, 9 Feb 2011 22:46:02 +0300 From: Slava Borilin To: "xavier.marjou@gmail.com" , "henry.sinnreich@gmail.com" Date: Wed, 9 Feb 2011 22:46:01 +0300 Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvIj0WX1odwWFpUQ2mNnhssiWQQNgAArVrF Message-ID: Accept-Language: ru-RU Content-Language: ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ru-RU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 192.168.125.15 Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" Subject: [dispatch] =?utf-8?b?0J3QkDogIFtSVFddIFJUQy1XZWIgSS1EIGFib3V0IGlu?= =?utf-8?q?terworking_between_RTC-Web_and_SIP-RTP?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:46:02 -0000 QWxzbyB3b3JrIG9yIGp1c3Qgd29yaz8NCg0K0KHQu9Cw0LLQsA0KDQotLS0tLSBSZXBseSBtZXNz YWdlIC0tLS0tDQrQntGCOiAiWGF2aWVyIE1hcmpvdSIgPHhhdmllci5tYXJqb3VAZ21haWwuY29t Pg0K0JTQsNGC0LA6INGB0YAsINGE0LXQsiA5LCAyMDExIDIyOjI2DQrQotC10LzQsDogW2Rpc3Bh dGNoXSBbUlRXXSBSVEMtV2ViIEktRCBhYm91dCBpbnRlcndvcmtpbmcgYmV0d2VlbiBSVEMtV2Vi IGFuZCBTSVAtUlRQDQrQmtC+0LzRgzogIkhlbnJ5IFNpbm5yZWljaCIgPGhlbnJ5LnNpbm5yZWlj aEBnbWFpbC5jb20+DQrQmtC+0L/QuNGPOiAicnRjLXdlYkBhbHZlc3RyYW5kLm5vIiA8cnRjLXdl YkBhbHZlc3RyYW5kLm5vPiwgIkRJU1BBVENIIGxpc3QiIDxkaXNwYXRjaEBpZXRmLm9yZz4NCg0K SGksDQoNCkhpIEhlbnJ5LA0KDQpUaGVzZSByZXF1aXJlbWVudHMgY2VydGFpbmx5IGRvIG5vdCB3 YW50IHRvIGNyaXBwbGUgaW5ub3ZhdGlvbiAoUlRDLVdlYikuDQpUaGV5IHJhdGhlciB3YW50IHRv IGNhdGNoIGF0dGVudGlvbiBzbyB0aGF0IFJUQy1XZWIgaXMgZGVzaWduZWQgaW4gYSB3YXkgaXQg Y2FuIGFsc28gd29yayB3aXRoIGV4aXN0aW5nIFNJUC1SVFAgZGV2aWNlcy4NCg0KQ2hlZXJzLA0K WGF2aWVyDQoNCk9uIFdlZCwgRmViIDksIDIwMTEgYXQgNjozNiBQTSwgSGVucnkgU2lubnJlaWNo IDxoZW5yeS5zaW5ucmVpY2hAZ21haWwuY29tPG1haWx0bzpoZW5yeS5zaW5ucmVpY2hAZ21haWwu Y29tPj4gd3JvdGU6DQogIEdFTkVSSUMtUkVRLTEgIFRoZSBbUlRDLVdlYl0gc29sdXRpb24gTVVT VCBiZSBkZXNpZ25lZCBpbiBhIHN1Y2ggd2F5DQogICAgICAgICAgICAgICAgICBpdCBhbGxvd3Mg aW50ZXJ3b3JraW5nIHdpdGggU0lQLVJUUCBhcHBsaWNhdGlvbnMgYm90aA0KICAgICAgICAgICAg ICAgICAgYXQgdGhlIHNpZ25hbGxpbmcgYW5kIG1lZGlhIGxldmVsLg0KDQpQbGVhc2UgaGVscCBt ZSB1bmRlcnN0YW5kIGhvdyB0aGlzIGFuZCB0aGUgb3RoZXIgcmVxdWlyZW1lbnRzIGRvIG5vdCBj cmlwcGxlIHRoZSB3aG9sZSBjb25jZXB0IG9mIHRoZSBSVEMtV2ViIChpbm5vdmF0aW9uIGJhc2Vk IG9uIHNpbXBsaWNpdHkgYW5kIGZsZXhpYmlsaXR5KSBieSBtYWtpbmcgaXQganVzdCBhbm90aGVy IGV4dGVuc2lvbiBvZiBsZWdhY3kgdGVsZWNvbSBkZXNpZ24/DQoNCk9yIGRpZCB0aGUgYXV0aG9y cyBtZWFuIHJlcXVpcmVtZW50cyBmb3IgZ2F0ZXdheXMgb25seT8NCg0KVGhhbmtzLCBIZW5yeQ0K DQoNCk9uIDIvOS8xMSAzOjA2IEFNLCAiWGF2aWVyIE1hcmpvdSIgPHhhdmllci5tYXJqb3VAb3Jh bmdlLWZ0Z3JvdXAuY29tPGh0dHA6Ly94YXZpZXIubWFyam91QG9yYW5nZS1mdGdyb3VwLmNvbT4+ IHdyb3RlOg0KDQpIaSwNCg0KV2UgaGF2ZSBwb3N0ZWQgYSBkcmFmdCBhYm91dCBpbnRlcndvcmtp bmcgcmVxdWlyZW1lbnRzIGJldHdlZW4gUlRDLVdlYiBhbmQgU0lQLVJUUC4NCmh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hcmpvdS1kaXNwYXRjaC1ydGN3ZWItc2lw LXJ0cC1pbnRlcndrLXJlcXMtMDAudHh0DQoNCkNoZWVycywNClhhdmllciBhbmQgSmVhbi1GcmFu w6dvaXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QN CmRpc3BhdGNoQGlldGYub3JnPGh0dHA6Ly9kaXNwYXRjaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJUQy1XZWIgbWFpbGluZyBsaXN0DQpSVEMt V2ViQGFsdmVzdHJhbmQubm88bWFpbHRvOlJUQy1XZWJAYWx2ZXN0cmFuZC5ubz4NCmh0dHA6Ly93 d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL3J0Yy13ZWINCg0KDQo= From Markus.Isomaki@nokia.com Wed Feb 9 11:52:37 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53ECB3A69BC for ; Wed, 9 Feb 2011 11:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiAiuH6WUMjW for ; Wed, 9 Feb 2011 11:52:36 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id CF1E43A6901 for ; Wed, 9 Feb 2011 11:52:35 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p19JqghR002820; Wed, 9 Feb 2011 21:52:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 21:52:31 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 20:52:30 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Wed, 9 Feb 2011 20:52:30 +0100 From: To: , Thread-Topic: [dispatch] RTCWEB I-D with thoughts on the framework Thread-Index: AQHLx59UeS6RSYyQq0yl53bwLn9H+pP5jHbQ Date: Wed, 9 Feb 2011 19:52:28 +0000 Message-ID: References: <4D5157CE.4080300@jdrosen.net> In-Reply-To: <4D5157CE.4080300@jdrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2011 19:52:31.0420 (UTC) FILETIME=[E3493FC0:01CBC892] X-Nokia-AV: Clean Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:52:37 -0000 Hi, I mostly agree with the model described in this draft >* no ICE - just STUN. ICE can be a javascript library. One point about this: I suppose here you mean that the browser just impleme= nt the STUN connectivity check between candidate address pairs for media au= thorization. But how about gathering the candidate addresses? I think that,= i.e. STUN and TURN, should also be implemented by the browser. And also pr= eferably a HTTP tunneled candidate. How those candidate addresses are used/= passed (the "ICE logic") within the session setup would in itself be an app= lication specific matter. Markus >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of ext Jonathan Rosenberg >Sent: 08 February, 2011 16:49 >To: 'DISPATCH list' >Subject: [dispatch] RTCWEB I-D with thoughts on the framework > >Some of my colleagues from Skype and I have put together a draft which >gives our thoughts on the scope of the protocols and functionality for >enabling browser RTC. I've just submitted the draft, which you can find >here: > >http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt > >Some of the key points: > >* keep it minimal >* APIs for controlling behaviors of the various media components, with >defaults for those that dont care >* no SIP or Jingle; leave that to proprietary over websockets/HTTP >* no ICE - just STUN. ICE can be a javascript library. > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen >Skype Chief Technology Strategist >jdrosen@skype.net http://www.skype.com >jdrosen@jdrosen.net http://www.jdrosen.net > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From Markus.Isomaki@nokia.com Wed Feb 9 11:52:49 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFBA3A69F8 for ; Wed, 9 Feb 2011 11:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LJ7Y01siUsV for ; Wed, 9 Feb 2011 11:52:43 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 5CE133A69BC for ; Wed, 9 Feb 2011 11:52:43 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p19JqmA4032441; Wed, 9 Feb 2011 21:52:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 21:52:43 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 20:52:42 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Wed, 9 Feb 2011 20:52:30 +0100 From: To: , Thread-Topic: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AQHLyDi3fSFcjLZo5U6I6RVFcB3ksJP5gzqQ Date: Wed, 9 Feb 2011 19:52:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DD8B10B86502AB488CB2D3DB4C546E38E6D160008AM1MPN1004mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2011 19:52:43.0646 (UTC) FILETIME=[EA92C9E0:01CBC892] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:52:49 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E38E6D160008AM1MPN1004mgdn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xavier and Jean-Francois, Thanks for putting this together. Based on the recent list discussion, I would say that quite many people are= leaning towards the architecture you depict in Section 5.2, Figure 2: The = session setup protocol is an application specific Javascript implementation= transported over HTTP or WebSocket, while media is running on standard RTP= supported by the browser. In that model we can't put many requirements on the session setup protocol = or its interworking with SIP. If the service provider needs SIP interoperab= ility (to connect to PSTN, to other service providers or SIP phones), it is= indeed THEIR burden to make sure they use something that has a clean mappi= ng to SIP - for instance, that they can do things like call hold. On the ot= her hand if the service provider is not interested in SIP interoperability,= they do not have to worry about that. In the IETF there are probably two = ways to address this interworking: a) do nothing and leave it completely to= the implementers and service providers, or b) define some kind of a SIP/BO= SH/HTTP or SIP/WebSocket mapping in the same way that the XMPP folks have d= one. The XMPP/BOSH spec does have implementations both on the client/Javasc= ript side as well as on the server side, so I think that spec has had some = value. (At least in a way that the Javascript library and the BOSH servers = can be implemented somewhat independently.) The RTP/media stack on the other hand is definitely in the scope of the IET= F effort. I think we should standardize the RTP use in the browsers and tha= t would be one step towards interop with SIP phones. The critical thing see= ms to be the STUN connectivity check or media authorization part. If we man= date browsers to get that exchange done before they are allowed to generate= any RTP packets on behalf of the application, this will ruin the possibili= ty of interop with 99% of existing SIP clients (without some kind of an SBC= ). DTMF transport capability may also be relevant interop requirement. I think these are the key issues we should consider wrt. SIP phone interop. Markus From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] = On Behalf Of ext Xavier Marjou Sent: 09 February, 2011 11:07 To: DISPATCH list Cc: rtc-web@alvestrand.no; Jean-Fran=E7ois Jestin Subject: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web an= d SIP-RTP Hi, We have posted a draft about interworking requirements between RTC-Web and = SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-in= terwk-reqs-00.txt Cheers, Xavier and Jean-Fran=E7ois --_000_DD8B10B86502AB488CB2D3DB4C546E38E6D160008AM1MPN1004mgdn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Xavier and Jean-Francois,

 

Thanks for putting this together.

 

Based on the recent list discussion, I would say that quite = many people are leaning towards the architecture you depict in Section 5.2, Figu= re 2: The session setup protocol is an application specific Javascript implementation transported over HTTP or WebSocket, while media is running o= n standard RTP supported by the browser.

 

In that model we can’t put many requirements on the session setup protocol or its interworking with SIP. If the service provide= r needs SIP interoperability (to connect to PSTN, to other service providers = or SIP phones), it is indeed THEIR burden to make sure they use something that= has a clean mapping to SIP – for instance, that they can do things like c= all hold. On the other hand if the service provider is not interested in SIP in= teroperability, they do not have to worry about that. =A0In the IETF there are probably two= ways to address this interworking: a) do nothing and leave it completely to the = implementers and service providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSocket mapping in the same way that the XMPP folks have done. The XM= PP/BOSH spec does have implementations both on the client/Javascript side as well a= s on the server side, so I think that spec has had some value. (At least in a wa= y that the Javascript library and the BOSH servers can be implemented somewha= t independently.)

 

The RTP/media stack on the other hand is definitely in the s= cope of the IETF effort. I think we should standardize the RTP use in the browse= rs and that would be one step towards interop with SIP phones. The critical th= ing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to gener= ate any RTP packets on behalf of the application, this will ruin the possibilit= y of interop with 99% of existing SIP clients (without some kind of an SBC). DTM= F transport capability may also be relevant interop requirement.

 

I think these are the key issues we should consider wrt. SIP phone interop.

 

Markus

 

 

From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Xavier Marjou
Sent: 09 February, 2011 11:07
To: DISPATCH list
Cc: rtc-web@alvestrand.no; Jean-Fran=E7ois Jestin
Subject: [RTW] [dispatch] RTC-Web I-D about interworking between RTC= -Web and SIP-RTP

 

Hi,

 

We have posted a draft about interworking requirements between RTC-Web and SIP-RTP.

 

Cheers,

Xavier and Jean-Fran=E7ois

--_000_DD8B10B86502AB488CB2D3DB4C546E38E6D160008AM1MPN1004mgdn_-- From adam@nostrum.com Wed Feb 9 12:07:05 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2573A6826 for ; Wed, 9 Feb 2011 12:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxhWdjwWcNr3 for ; Wed, 9 Feb 2011 12:07:05 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 475803A67F4 for ; Wed, 9 Feb 2011 12:07:03 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p19K77DS093609 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 14:07:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D52F3EB.3010209@nostrum.com> Date: Wed, 09 Feb 2011 14:07:07 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030700040702010709070704" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtc-web@alvestrand.no, dispatch@ietf.org, xavier.marjou@orange-ftgroup.com Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:07:06 -0000 This is a multi-part message in MIME format. --------------030700040702010709070704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/9/11 13:52, Feb 9, Markus.Isomaki@nokia.com wrote: > The RTP/media stack on the other hand is definitely in the scope of > the IETF effort. I think we should standardize the RTP use in the > browsers and that would be one step towards interop with SIP phones. > The critical thing seems to be the STUN connectivity check or media > authorization part. If we mandate browsers to get that exchange done > before they are allowed to generate any RTP packets on behalf of the > application, this will ruin the possibility of interop with 99% of > existing SIP clients (without some kind of an SBC). DTMF transport > capability may also be relevant interop requirement. +1. Also, it would be incorrect to characterize RTP as being solely for the benefit of SIP. Several other protocol -- both published and proprietary -- make use of RTP; Jingle comes to mind, as do the proprietary protocols used by various IP PBX vendors. If we decide to go down an "RTP but with special sauce" or "not quite RTP" path, we lose a lot of potential functionality. /a --------------030700040702010709070704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/9/11 13:52, Feb 9, Markus.Isomaki@nokia.com wrote:
The RTP/media stack on the other hand is definitely in the scope of the IETF effort. I think we should standardize the RTP use in the browsers and that would be one step towards interop with SIP phones. The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC). DTMF transport capability may also be relevant interop requirement.

+1.

Also, it would be incorrect to characterize RTP as being solely for the benefit of SIP. Several other protocol -- both published and proprietary -- make use of RTP; Jingle comes to mind, as do the proprietary protocols used by various IP PBX vendors.

If we decide to go down an "RTP but with special sauce" or "not quite RTP" path, we lose a lot of potential functionality.

/a
--------------030700040702010709070704-- From Borilin@spiritdsp.com Wed Feb 9 12:17:08 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7064A3A683F for ; Wed, 9 Feb 2011 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6licRtfp3fB for ; Wed, 9 Feb 2011 12:17:07 -0800 (PST) Received: from mail3.spiritdsp.com (mail3.spiritdsp.com [85.13.214.194]) by core3.amsl.com (Postfix) with ESMTP id 364343A67F4 for ; Wed, 9 Feb 2011 12:17:07 -0800 (PST) Received: from mailsrv.spiritcorp.com (mailsrv.spiritcorp.com [192.168.125.13]) by mail3.spiritdsp.com (8.14.3/8.14.3) with ESMTP id p19KHDHq090743; Wed, 9 Feb 2011 23:17:13 +0300 (MSK) (envelope-from Borilin@spiritdsp.com) Received: from mailsrv.spiritcorp.com ([192.168.125.13]) by mailsrv.spiritcorp.com ([192.168.125.13]) with mapi; Wed, 9 Feb 2011 23:17:08 +0300 From: Slava Borilin To: "markus.isomaki@nokia.com" , "xavier.marjou@orange-ftgroup.com" , "dispatch@ietf.org" Date: Wed, 9 Feb 2011 23:17:07 +0300 Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AQHLyDi3fSFcjLZo5U6I6RVFcB3ksJP5gzqQgAAY+x0= Message-ID: Accept-Language: ru-RU Content-Language: ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ru-RU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 192.168.125.15 Cc: "rtc-web@alvestrand.no" Subject: [dispatch] =?utf-8?b?0J3QkDogIFtSVFddIFJUQy1XZWIgSS1EIGFib3V0IGlu?= =?utf-8?q?terworking_between_RTC-Web_and=09SIP-RTP?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:17:08 -0000 RGVhciBhbGwsDQoNCkxldCBtZSB0aHJvdyBpbiBhbm90aGVyIHF1ZXN0aW9uLSB3aGVuIGFsbCBv ZiB1cyBhcmUgdGFsa2luZyBtZWRpYSwgd2UgdGhpbmsgaXRzIGF1ZGlvLXZpZGVvIG9ubHkuDQoN CkJ1dCBpbiBwcmFjdGljZSwgcmVhbC10aW1lIGRhdGEgc3VjaCBhcyB2bmMsIGlzIGFsc28gbm93 IHBhcnQgb2YgcmVhbC10aW1lIG1lZGlhIHNlc3Npb24sIGFuZCBpdCBtdXN0IGZvbGxvdyB0aGUg c2FtZSBOYXQtdHJhdmVyc2FsIHNjZW5hcmlvLCBhcyBhdWRpbyAmIHZpZGVvLCBidXQgbm90IG5l Y2Vzc2FyaWx5IHRoZSBydHAgcHJvdG9jb2wgKGJ1dCBUQ1ApLiBJIHRoaW5rIGlmIHdlIHB1dCBz dHVuIGluIGJyb3dzZXIsIGl0IHNob3VsZCBiZSBhdmFpbGFibGUgbm90IG9ubHkgZm9yIHJ0cCBz ZXNzaW9ucy4NCg0KQmFzZWQgb24gdmlkZW9jb25mZXJlbmNpbmcgZXhwZXJpZW5jZS4NCg0KDQrQ odC70LDQstCwDQoNCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0NCtCe0YI6ICJNYXJrdXMuSXNv bWFraUBub2tpYS5jb20iIDxNYXJrdXMuSXNvbWFraUBub2tpYS5jb20+DQrQlNCw0YLQsDog0YHR gCwg0YTQtdCyIDksIDIwMTEgMjI6NTMNCtCi0LXQvNCwOiBbZGlzcGF0Y2hdIFtSVFddIFJUQy1X ZWIgSS1EIGFib3V0IGludGVyd29ya2luZyBiZXR3ZWVuIFJUQy1XZWIgYW5kIFNJUC1SVFANCtCa 0L7QvNGDOiAieGF2aWVyLm1hcmpvdUBvcmFuZ2UtZnRncm91cC5jb20iIDx4YXZpZXIubWFyam91 QG9yYW5nZS1mdGdyb3VwLmNvbT4sICJkaXNwYXRjaEBpZXRmLm9yZyIgPGRpc3BhdGNoQGlldGYu b3JnPg0K0JrQvtC/0LjRjzogInJ0Yy13ZWJAYWx2ZXN0cmFuZC5ubyIgPHJ0Yy13ZWJAYWx2ZXN0 cmFuZC5ubz4NCg0KSGkgWGF2aWVyIGFuZCBKZWFuLUZyYW5jb2lzLA0KDQpUaGFua3MgZm9yIHB1 dHRpbmcgdGhpcyB0b2dldGhlci4NCg0KQmFzZWQgb24gdGhlIHJlY2VudCBsaXN0IGRpc2N1c3Np b24sIEkgd291bGQgc2F5IHRoYXQgcXVpdGUgbWFueSBwZW9wbGUgYXJlIGxlYW5pbmcgdG93YXJk cyB0aGUgYXJjaGl0ZWN0dXJlIHlvdSBkZXBpY3QgaW4gU2VjdGlvbiA1LjIsIEZpZ3VyZSAyOiBU aGUgc2Vzc2lvbiBzZXR1cCBwcm90b2NvbCBpcyBhbiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBKYXZh c2NyaXB0IGltcGxlbWVudGF0aW9uIHRyYW5zcG9ydGVkIG92ZXIgSFRUUCBvciBXZWJTb2NrZXQs IHdoaWxlIG1lZGlhIGlzIHJ1bm5pbmcgb24gc3RhbmRhcmQgUlRQIHN1cHBvcnRlZCBieSB0aGUg YnJvd3Nlci4NCg0KSW4gdGhhdCBtb2RlbCB3ZSBjYW7igJl0IHB1dCBtYW55IHJlcXVpcmVtZW50 cyBvbiB0aGUgc2Vzc2lvbiBzZXR1cCBwcm90b2NvbCBvciBpdHMgaW50ZXJ3b3JraW5nIHdpdGgg U0lQLiBJZiB0aGUgc2VydmljZSBwcm92aWRlciBuZWVkcyBTSVAgaW50ZXJvcGVyYWJpbGl0eSAo dG8gY29ubmVjdCB0byBQU1ROLCB0byBvdGhlciBzZXJ2aWNlIHByb3ZpZGVycyBvciBTSVAgcGhv bmVzKSwgaXQgaXMgaW5kZWVkIFRIRUlSIGJ1cmRlbiB0byBtYWtlIHN1cmUgdGhleSB1c2Ugc29t ZXRoaW5nIHRoYXQgaGFzIGEgY2xlYW4gbWFwcGluZyB0byBTSVAg4oCTIGZvciBpbnN0YW5jZSwg dGhhdCB0aGV5IGNhbiBkbyB0aGluZ3MgbGlrZSBjYWxsIGhvbGQuIE9uIHRoZSBvdGhlciBoYW5k IGlmIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGlzIG5vdCBpbnRlcmVzdGVkIGluIFNJUCBpbnRlcm9w ZXJhYmlsaXR5LCB0aGV5IGRvIG5vdCBoYXZlIHRvIHdvcnJ5IGFib3V0IHRoYXQuICBJbiB0aGUg SUVURiB0aGVyZSBhcmUgcHJvYmFibHkgdHdvIHdheXMgdG8gYWRkcmVzcyB0aGlzIGludGVyd29y a2luZzogYSkgZG8gbm90aGluZyBhbmQgbGVhdmUgaXQgY29tcGxldGVseSB0byB0aGUgaW1wbGVt ZW50ZXJzIGFuZCBzZXJ2aWNlIHByb3ZpZGVycywgb3IgYikgZGVmaW5lIHNvbWUga2luZCBvZiBh IFNJUC9CT1NIL0hUVFAgb3IgU0lQL1dlYlNvY2tldCBtYXBwaW5nIGluIHRoZSBzYW1lIHdheSB0 aGF0IHRoZSBYTVBQIGZvbGtzIGhhdmUgZG9uZS4gVGhlIFhNUFAvQk9TSCBzcGVjIGRvZXMgaGF2 ZSBpbXBsZW1lbnRhdGlvbnMgYm90aCBvbiB0aGUgY2xpZW50L0phdmFzY3JpcHQgc2lkZSBhcyB3 ZWxsIGFzIG9uIHRoZSBzZXJ2ZXIgc2lkZSwgc28gSSB0aGluayB0aGF0IHNwZWMgaGFzIGhhZCBz b21lIHZhbHVlLiAoQXQgbGVhc3QgaW4gYSB3YXkgdGhhdCB0aGUgSmF2YXNjcmlwdCBsaWJyYXJ5 IGFuZCB0aGUgQk9TSCBzZXJ2ZXJzIGNhbiBiZSBpbXBsZW1lbnRlZCBzb21ld2hhdCBpbmRlcGVu ZGVudGx5LikNCg0KVGhlIFJUUC9tZWRpYSBzdGFjayBvbiB0aGUgb3RoZXIgaGFuZCBpcyBkZWZp bml0ZWx5IGluIHRoZSBzY29wZSBvZiB0aGUgSUVURiBlZmZvcnQuIEkgdGhpbmsgd2Ugc2hvdWxk IHN0YW5kYXJkaXplIHRoZSBSVFAgdXNlIGluIHRoZSBicm93c2VycyBhbmQgdGhhdCB3b3VsZCBi ZSBvbmUgc3RlcCB0b3dhcmRzIGludGVyb3Agd2l0aCBTSVAgcGhvbmVzLiBUaGUgY3JpdGljYWwg dGhpbmcgc2VlbXMgdG8gYmUgdGhlIFNUVU4gY29ubmVjdGl2aXR5IGNoZWNrIG9yIG1lZGlhIGF1 dGhvcml6YXRpb24gcGFydC4gSWYgd2UgbWFuZGF0ZSBicm93c2VycyB0byBnZXQgdGhhdCBleGNo YW5nZSBkb25lIGJlZm9yZSB0aGV5IGFyZSBhbGxvd2VkIHRvIGdlbmVyYXRlIGFueSBSVFAgcGFj a2V0cyBvbiBiZWhhbGYgb2YgdGhlIGFwcGxpY2F0aW9uLCB0aGlzIHdpbGwgcnVpbiB0aGUgcG9z c2liaWxpdHkgb2YgaW50ZXJvcCB3aXRoIDk5JSBvZiBleGlzdGluZyBTSVAgY2xpZW50cyAod2l0 aG91dCBzb21lIGtpbmQgb2YgYW4gU0JDKS4gRFRNRiB0cmFuc3BvcnQgY2FwYWJpbGl0eSBtYXkg YWxzbyBiZSByZWxldmFudCBpbnRlcm9wIHJlcXVpcmVtZW50Lg0KDQpJIHRoaW5rIHRoZXNlIGFy ZSB0aGUga2V5IGlzc3VlcyB3ZSBzaG91bGQgY29uc2lkZXIgd3J0LiBTSVAgcGhvbmUgaW50ZXJv cC4NCg0KTWFya3VzDQoNCg0KRnJvbTogcnRjLXdlYi1ib3VuY2VzQGFsdmVzdHJhbmQubm8gW21h aWx0bzpydGMtd2ViLWJvdW5jZXNAYWx2ZXN0cmFuZC5ub10gT24gQmVoYWxmIE9mIGV4dCBYYXZp ZXIgTWFyam91DQpTZW50OiAwOSBGZWJydWFyeSwgMjAxMSAxMTowNw0KVG86IERJU1BBVENIIGxp c3QNCkNjOiBydGMtd2ViQGFsdmVzdHJhbmQubm87IEplYW4tRnJhbsOnb2lzIEplc3Rpbg0KU3Vi amVjdDogW1JUV10gW2Rpc3BhdGNoXSBSVEMtV2ViIEktRCBhYm91dCBpbnRlcndvcmtpbmcgYmV0 d2VlbiBSVEMtV2ViIGFuZCBTSVAtUlRQDQoNCkhpLA0KDQpXZSBoYXZlIHBvc3RlZCBhIGRyYWZ0 IGFib3V0IGludGVyd29ya2luZyByZXF1aXJlbWVudHMgYmV0d2VlbiBSVEMtV2ViIGFuZCBTSVAt UlRQLg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFyam91LWRp c3BhdGNoLXJ0Y3dlYi1zaXAtcnRwLWludGVyd2stcmVxcy0wMC50eHQNCg0KQ2hlZXJzLA0KWGF2 aWVyIGFuZCBKZWFuLUZyYW7Dp29pcw0K From peter.musgrave@magorcorp.com Wed Feb 9 12:54:48 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340D13A68D7 for ; Wed, 9 Feb 2011 12:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olY8U2NjEcYA for ; Wed, 9 Feb 2011 12:54:47 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 68DC43A6811 for ; Wed, 9 Feb 2011 12:54:43 -0800 (PST) Received: by gwb20 with SMTP id 20so296504gwb.31 for ; Wed, 09 Feb 2011 12:54:53 -0800 (PST) Received: by 10.236.110.39 with SMTP id t27mr3195768yhg.31.1297282544350; Wed, 09 Feb 2011 12:15:44 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id i18sm416516yhd.22.2011.02.09.12.15.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 12:15:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-8--999720519 From: Peter Musgrave In-Reply-To: <4D52F3EB.3010209@nostrum.com> Date: Wed, 9 Feb 2011 15:15:42 -0500 Message-Id: References: <4D52F3EB.3010209@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1082) Cc: rtc-web@alvestrand.no, dispatch@ietf.org, xavier.marjou@orange-ftgroup.com, Markus.Isomaki@nokia.com Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:54:48 -0000 --Apple-Mail-8--999720519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I also agree with the "make RTP just work" - signal where and how you = want..=20 Sorry if I am being dense here - do we not need ICE connectivity checks = to finish before RTP can be sent? Or is the point that this will take = too long to get into browser code and that ICE in Javascript with STUN = in the browser gets rolled out faster? Peter Musgrave On 2011-02-09, at 3:07 PM, Adam Roach wrote: >> The critical thing seems to be the STUN connectivity check or media = authorization part. If we mandate browsers to get that exchange done = before they are allowed to generate any RTP packets on behalf of the = application, this will ruin the possibility of interop with 99% of = existing SIP clients (without some kind of an SBC) --Apple-Mail-8--999720519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = also agree with the "make RTP just work" - signal where and how you = want.. 

Sorry if I am being dense here - do we = not need ICE connectivity checks to finish before RTP can be sent? Or is = the point that this will take too long to get into browser code and that = ICE in Javascript with STUN in the browser gets rolled out = faster?

Peter = Musgrave

On 2011-02-09, at 3:07 PM, Adam Roach = wrote:

The critical thing seems to be the STUN connectivity = check or media authorization part. If we mandate browsers to get that = exchange done before they are allowed to generate any RTP packets on = behalf of the application, this will ruin the possibility of interop = with 99% of existing SIP clients (without some kind of an = SBC)

<= /html>= --Apple-Mail-8--999720519-- From Markus.Isomaki@nokia.com Wed Feb 9 13:06:35 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2613A67F0 for ; Wed, 9 Feb 2011 13:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6NK-xMoDLDe for ; Wed, 9 Feb 2011 13:06:33 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 99E963A67B7 for ; Wed, 9 Feb 2011 13:06:32 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p19L6bhw002093; Wed, 9 Feb 2011 23:06:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 23:06:34 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 22:06:33 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Wed, 9 Feb 2011 22:06:21 +0100 From: To: , Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AQHLyJT21L741ozG2U2an2RArq4XcJP5ilIAgAAc+uA= Date: Wed, 9 Feb 2011 21:05:58 +0000 Message-ID: References: <4D52F3EB.3010209@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DD8B10B86502AB488CB2D3DB4C546E38E6D6BD008AM1MPN1004mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2011 21:06:34.0031 (UTC) FILETIME=[3B49E3F0:01CBC89D] X-Nokia-AV: Clean Cc: rtc-web@alvestrand.no, dispatch@ietf.org, xavier.marjou@orange-ftgroup.com Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:06:35 -0000 --_000_DD8B10B86502AB488CB2D3DB4C546E38E6D6BD008AM1MPN1004mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, I hope I'm answering the right question: I think something like the STUN connectivity check or authorization is requ= ired to be implemented in the browser to prevent the Javascript application= from sending RTP or some other UDP data to any arbitrary IP addresses and = port. If the browser only allows the sending after a successful connectivit= y check it can ensure (to some extent) that the other peer also actually wa= nts to receive this traffic. That code needs to reside in the browser so th= at the browser can act as the gatekeeper. Markus From: ext Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: 09 February, 2011 22:16 To: Adam Roach Cc: Isomaki Markus (Nokia-CIC/Espoo); rtc-web@alvestrand.no; dispatch@ietf.= org; xavier.marjou@orange-ftgroup.com Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-We= b and SIP-RTP I also agree with the "make RTP just work" - signal where and how you want.= . Sorry if I am being dense here - do we not need ICE connectivity checks to = finish before RTP can be sent? Or is the point that this will take too long= to get into browser code and that ICE in Javascript with STUN in the brows= er gets rolled out faster? Peter Musgrave On 2011-02-09, at 3:07 PM, Adam Roach wrote: The critical thing seems to be the STUN connectivity check or media authori= zation part. If we mandate browsers to get that exchange done before they a= re allowed to generate any RTP packets on behalf of the application, this w= ill ruin the possibility of interop with 99% of existing SIP clients (witho= ut some kind of an SBC) --_000_DD8B10B86502AB488CB2D3DB4C546E38E6D6BD008AM1MPN1004mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

I hope I’m answering the right question:

 

I think something like the STUN connectivity check or authorization is required to be implemented in the browser to prevent the J= avascript application from sending RTP or some other UDP data to any arbitrary IP addresses and port. If the browser only allows the sending after a successf= ul connectivity check it can ensure (to some extent) that the other peer also actually want= s to receive this traffic. That code needs to reside in the browser so that the browser can act as the gatekeeper.

 

Markus

 

From: ext Peter Mus= grave [mailto:peter.musgrave@magorcorp.com]
Sent: 09 February, 2011 22:16
To: Adam Roach
Cc: Isomaki Markus (Nokia-CIC/Espoo); rtc-web@alvestrand.no; dispatch@ietf.org; xavier.marjou@orange-ftgroup.com
Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

 

I also agree with the "make RTP just work" - signal where and how you want.. 

 

Sorry if I am being dense here - do we not need ICE connectivity checks to finish before RTP can be sent? Or is the point that = this will take too long to get into browser code and that ICE in Javascript with STUN in the browser gets rolled out faster?

 

Peter Musgrave

 

On 2011-02-09, at 3:07 PM, Adam Roach wrote:



The critical thing seems to be the STUN connectivity check o= r media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing= SIP clients (without some kind of an SBC)

 

--_000_DD8B10B86502AB488CB2D3DB4C546E38E6D6BD008AM1MPN1004mgdn_-- From henry.sinnreich@gmail.com Wed Feb 9 14:04:07 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAD73A67F6 for ; Wed, 9 Feb 2011 14:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-1.332, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_WIN1251=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGQRz9EZY5zw for ; Wed, 9 Feb 2011 14:04:06 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 066443A69E6 for ; Wed, 9 Feb 2011 14:04:02 -0800 (PST) Received: by yie19 with SMTP id 19so330172yie.31 for ; Wed, 09 Feb 2011 14:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=hujEFUFyJloh0U6YeSUNABQ5H1/wKCfCgrwmGXkf9AE=; b=FDE9M0WI/6nDLpe3wewPeVu1yvA84CocVPoreSwuxGaHJQN7nK2H6WHmTsT0jqOrb9 8ZDJaOphEyB+Vf5gGUcATrsqMbmkQm6yXEvwtdsSTLwi4qlwkokrfmyjPF4co8APanH9 VlngA8MsaZD+2ZOu4jWps8j5l3SK7AJyG3RrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=EjEVJ3gVQ0vdqnLND0d45Nvq11pPUQdVrCY8IfcFspnY2LtqNK50N3e/ku0FSvRHkR IDL30AaLslcC9I5Z9RPVreICjVybvJK2P1Jvn+g7ZGAQCnMhhLffHtLY8ehW4cNKPGP4 QnhFFDzRV+9wvUboF0u3/Btj1VkCD6v5pBtl8= Received: by 10.150.11.16 with SMTP id 16mr1581623ybk.444.1297289053193; Wed, 09 Feb 2011 14:04:13 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id r24sm1193817yba.18.2011.02.09.14.04.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Feb 2011 14:04:12 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 16:04:08 -0600 From: Henry Sinnreich To: Slava Borilin , "markus.isomaki@nokia.com" , "xavier.marjou@orange-ftgroup.com" , "dispatch@ietf.org" Message-ID: Thread-Topic: [dispatch] =?windows-1251?B?zcA=?=: [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AQHLyDi3fSFcjLZo5U6I6RVFcB3ksJP5gzqQgAAY+x2AAB3lHg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Cc: "rtc-web@alvestrand.no" Subject: Re: [dispatch] =?windows-1251?b?zcAgOiAgW1JUV10gUlRDLVdlYiBJLUQgYWJv?= =?windows-1251?q?ut_interworking_between_RTC-Web_and_SIP-RTP?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:04:07 -0000 +1 > But in practice, real-time data such as vnc, is also now part of real-tim= e > media session, and it must follow the same Nat-traversal scenario, as aud= io & > video, but not necessarily the rtp protocol Indeed, many people spend far more time with VNC than making phone/video calls. And as argued here before, the data content in RTP can be transporte= d over HTTP as well, along with all other metadata. A possible guideline here is: >as long as we have an architecture which one *can* instantiate a component= for >the signalling that does SIP and a component for media-transfer that does = RTP, >and so on, this requirement is met. And I would have thought that yes, we >would agree the architecture should make that possible. >whether we choose those components as a baseline set to implement is much = more >a debate, I'd say. This last sentence is the key IMO. Thanks, Henry On 2/9/11 2:17 PM, "Slava Borilin" wrote: > Dear all, >=20 > Let me throw in another question- when all of us are talking media, we th= ink > its audio-video only. >=20 > But in practice, real-time data such as vnc, is also now part of real-tim= e > media session, and it must follow the same Nat-traversal scenario, as aud= io & > video, but not necessarily the rtp protocol (but TCP). I think if we put = stun > in browser, it should be available not only for rtp sessions. >=20 > Based on videoconferencing experience. >=20 >=20 > =D0=A1=D0=BB=D0=B0=D0=B2=D0=B0 >=20 > ----- Reply message ----- > =D0=9E=D1=82: "Markus.Isomaki@nokia.com" > =D0=94=D0=B0=D1=82=D0=B0: =D1=81=D1=80, =D1=84=D0=B5=D0=B2 9, 2011 22:53 > =D0=A2=D0=B5=D0=BC=D0=B0: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web= and > SIP-RTP > =D0=9A=D0=BE=D0=BC=D1=83: "xavier.marjou@orange-ftgroup.com" , > "dispatch@ietf.org" > =D0=9A=D0=BE=D0=BF=D0=B8=D1=8F: "rtc-web@alvestrand.no" >=20 > Hi Xavier and Jean-Francois, >=20 > Thanks for putting this together. >=20 > Based on the recent list discussion, I would say that quite many people a= re > leaning towards the architecture you depict in Section 5.2, Figure 2: The > session setup protocol is an application specific Javascript implementati= on > transported over HTTP or WebSocket, while media is running on standard RT= P > supported by the browser. >=20 > In that model we can=E2=80=99t put many requirements on the session setup proto= col or > its interworking with SIP. If the service provider needs SIP interoperabi= lity > (to connect to PSTN, to other service providers or SIP phones), it is ind= eed > THEIR burden to make sure they use something that has a clean mapping to = SIP =E2=80=93 > for instance, that they can do things like call hold. On the other hand i= f the > service provider is not interested in SIP interoperability, they do not h= ave > to worry about that. In the IETF there are probably two ways to address = this > interworking: a) do nothing and leave it completely to the implementers a= nd > service providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSo= cket > mapping in the same way that the XMPP folks have done. The XMPP/BOSH spec= does > have implementations both on the client/Javascript side as well as on the > server side, so I think that spec has had some value. (At least in a way = that > the Javascript library and the BOSH servers can be implemented somewhat > independently.) >=20 > The RTP/media stack on the other hand is definitely in the scope of the I= ETF > effort. I think we should standardize the RTP use in the browsers and tha= t > would be one step towards interop with SIP phones. The critical thing see= ms to > be the STUN connectivity check or media authorization part. If we mandate > browsers to get that exchange done before they are allowed to generate an= y RTP > packets on behalf of the application, this will ruin the possibility of > interop with 99% of existing SIP clients (without some kind of an SBC). D= TMF > transport capability may also be relevant interop requirement. >=20 > I think these are the key issues we should consider wrt. SIP phone intero= p. >=20 > Markus >=20 >=20 > From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no= ] On > Behalf Of ext Xavier Marjou > Sent: 09 February, 2011 11:07 > To: DISPATCH list > Cc: rtc-web@alvestrand.no; Jean-Fran=C3=A7ois Jestin > Subject: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web = and > SIP-RTP >=20 > Hi, >=20 > We have posted a draft about interworking requirements between RTC-Web an= d > SIP-RTP. > http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-= inter > wk-reqs-00.txt >=20 > Cheers, > Xavier and Jean-Fran=C3=A7ois > _______________________________________________ dispatch mailing > list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jdrosen@jdrosen.net Wed Feb 9 14:09:20 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF4B3A683D for ; Wed, 9 Feb 2011 14:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to0z5DM4N8mg for ; Wed, 9 Feb 2011 14:09:17 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (unknown [70.39.232.210]) by core3.amsl.com (Postfix) with ESMTP id D2FBE3A67CF for ; Wed, 9 Feb 2011 14:09:16 -0800 (PST) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PnIDx-00026n-Io; Wed, 09 Feb 2011 17:09:21 -0500 Message-ID: <4D53108F.6000909@jdrosen.net> Date: Wed, 09 Feb 2011 17:09:19 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: rtc-web@alvestrand.no, dispatch@ietf.org, xavier.marjou@orange-ftgroup.com Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:09:20 -0000 I don't think the picture in 5.2 is quite right either: Architecture with HTTP in the browser: ----------------- ----------------- | RTC-Web | | SIP-RTP | | application | | application | |-----------------| | | |rtcweb rtcweb | | | | sig media | | | | APIs APIs | | | | | XXX | | | | |---|---------|---| XXX | | | --|-- | | over -------- | ----- | ||HTTP | | |<-HTTP->|HTTP|SIP|<-SIP-->|| SIP | | ||stack| | | | GW | ||stack| | | ----- | | -------- | ----- | | --|-- | | ----- | | | RTP ||<----------RTP----------->| | RTP || | |stack|| | |stack|| | ----- | | ----- | ----------------- ----------------- Figure 2 It explicitly calls out "rtcweb sig APIs" as something that exists in the browser as an API distinct from traditional AJAX techniques for communicating with the server (e.g., XMLHttpRequest). I dont think there is anything called an "rtcweb sig API" in the browser; the API is at the discretion of the application and does not need anything new. Thanks, Jonathan R. On 2/9/2011 2:52 PM, Markus.Isomaki@nokia.com wrote: > Hi Xavier and Jean-Francois, > > Thanks for putting this together. > > Based on the recent list discussion, I would say that quite many people > are leaning towards the architecture you depict in Section 5.2, Figure > 2: The session setup protocol is an application specific Javascript > implementation transported over HTTP or WebSocket, while media is > running on standard RTP supported by the browser. > > In that model we can’t put many requirements on the session setup > protocol or its interworking with SIP. If the service provider needs SIP > interoperability (to connect to PSTN, to other service providers or SIP > phones), it is indeed THEIR burden to make sure they use something that > has a clean mapping to SIP – for instance, that they can do things like > call hold. On the other hand if the service provider is not interested > in SIP interoperability, they do not have to worry about that. In the > IETF there are probably two ways to address this interworking: a) do > nothing and leave it completely to the implementers and service > providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSocket > mapping in the same way that the XMPP folks have done. The XMPP/BOSH > spec does have implementations both on the client/Javascript side as > well as on the server side, so I think that spec has had some value. (At > least in a way that the Javascript library and the BOSH servers can be > implemented somewhat independently.) > > The RTP/media stack on the other hand is definitely in the scope of the > IETF effort. I think we should standardize the RTP use in the browsers > and that would be one step towards interop with SIP phones. The critical > thing seems to be the STUN connectivity check or media authorization > part. If we mandate browsers to get that exchange done before they are > allowed to generate any RTP packets on behalf of the application, this > will ruin the possibility of interop with 99% of existing SIP clients > (without some kind of an SBC). DTMF transport capability may also be > relevant interop requirement. > > I think these are the key issues we should consider wrt. SIP phone interop. > > Markus > > *From:*rtc-web-bounces@alvestrand.no > [mailto:rtc-web-bounces@alvestrand.no] *On Behalf Of *ext Xavier Marjou > *Sent:* 09 February, 2011 11:07 > *To:* DISPATCH list > *Cc:* rtc-web@alvestrand.no; Jean-François Jestin > *Subject:* [RTW] [dispatch] RTC-Web I-D about interworking between > RTC-Web and SIP-RTP > > Hi, > > We have posted a draft about interworking requirements between RTC-Web > and SIP-RTP. > > http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt > > Cheers, > > Xavier and Jean-François > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From jdrosen@jdrosen.net Wed Feb 9 14:20:33 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CFD3A67F6 for ; Wed, 9 Feb 2011 14:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.021 X-Spam-Level: X-Spam-Status: No, score=-101.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5P7X+khpMNE for ; Wed, 9 Feb 2011 14:20:32 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (unknown [70.39.232.210]) by core3.amsl.com (Postfix) with ESMTP id 2F18E3A682D for ; Wed, 9 Feb 2011 14:20:32 -0800 (PST) Received: from pool-98-109-139-97.nwrknj.fios.verizon.net ([98.109.139.97] helo=[192.168.1.9]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PnIOw-0005xM-Bl; Wed, 09 Feb 2011 17:20:42 -0500 Message-ID: <4D53133A.1090703@jdrosen.net> Date: Wed, 09 Feb 2011 17:20:42 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <4D5157CE.4080300@jdrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: dispatch@ietf.org Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:20:33 -0000 inline: On 2/9/2011 2:52 PM, Markus.Isomaki@nokia.com wrote: > Hi, > > I mostly agree with the model described in this draft > >> * no ICE - just STUN. ICE can be a javascript library. > > One point about this: I suppose here you mean that the browser just > implement the STUN connectivity check between candidate address pairs > for media authorization. Yes. > But how about gathering the candidate > addresses? This would be orchestrated by the Javascript (and server as needed) by telling the browser how to use STUN. I had in mind an API that might look like: {IPaddr:port} = STUNCheck(destinationIP, destinationPort, username, password, AttributeValues); To gather a server reflexive, the Javascript uses this API against a server IP/port which the application provider knows is a STUN server of its choosing. To gather a relayed candidate, the Javascript once again uses this API against a server IP/port, but this STUN server acts like a TURN server of sorts. The STUN check is merely used to create the NAT binding to allow for relayed traffic to reach the client. The actual relayed candidate and other semantics of the relay operation can be handled by the server entirely. This is kind of like the old slushy proposal if anyone remembers that... There are clearly some benefits to using TURN directly - primarily it would allow more easy reuse of existing servers. However, if we focus on a minimum browser capability, a basic STUN probe which returns a reflexive candidate is actually sufficient; TURN is not needed even for the purposes of gathering relayed candidates for interoperable ICE. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From lconroy@insensate.co.uk Wed Feb 9 14:41:54 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF24C3A6846 for ; Wed, 9 Feb 2011 14:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9YLEV-S7pG8 for ; Wed, 9 Feb 2011 14:41:54 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id C39463A6819 for ; Wed, 9 Feb 2011 14:41:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B2AF212F633; Wed, 9 Feb 2011 22:42:02 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+U0enLAcpPk; Wed, 9 Feb 2011 22:42:01 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id D7EDA12F628; Wed, 9 Feb 2011 22:42:01 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Wed, 9 Feb 2011 22:42:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <16C3E0C6-1EF0-405C-B160-CD2FEE6A1402@insensate.co.uk> References: To: Xavier Marjou X-Mailer: Apple Mail (2.1082) Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:41:55 -0000 Hi Xavier, folks, Forgive the dense question, but ... why? If one wants to gateway, fine. However, this seems to imply that *all* implementations will interwork = with SIP, RTP, ... Was that intended? all the best, Lawrence [who has been here before :] On 9 Feb 2011, at 19:26, Xavier Marjou wrote: > Hi Henry, >=20 > These requirements certainly do not want to cripple innovation = (RTC-Web). > They rather want to catch attention so that RTC-Web is designed in a = way it > can also work with existing SIP-RTP devices. >=20 > Cheers, > Xavier >=20 > On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich > wrote: >=20 >> GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such = way >> it allows interworking with SIP-RTP applications = both >> at the signalling and media level. >>=20 >> Please help me understand how this and the other requirements do not >> cripple the whole concept of the RTC-Web (innovation based on = simplicity and >> flexibility) by making it just another extension of legacy telecom = design? >>=20 >> Or did the authors mean requirements for gateways only? >>=20 >> Thanks, Henry From adam@nostrum.com Wed Feb 9 15:13:33 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1A73A67AC for ; Wed, 9 Feb 2011 15:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdUs3+xVc1HL for ; Wed, 9 Feb 2011 15:13:32 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6CD1B3A672E for ; Wed, 9 Feb 2011 15:13:31 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p19NDbZ8009243 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 17:13:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D531FA0.8090203@nostrum.com> Date: Wed, 09 Feb 2011 17:13:36 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lawrence Conroy References: <16C3E0C6-1EF0-405C-B160-CD2FEE6A1402@insensate.co.uk> In-Reply-To: <16C3E0C6-1EF0-405C-B160-CD2FEE6A1402@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:13:33 -0000 I think the intention here is that we don't make decisions that *preclude* reasonable interoperation with legacy SIP systems. No specific implementation will need to interoperate with anything it doesn't need to, of course. Unfortunately, it's almost a non-requirement, because everything can be forced to interoperate with everything else at some level (in a worst case, by laying a microphone for one system next to a speaker for the other, pointing a camera at the screen, etc.). I believe we're trying to convey a principle of "least impedance mismatch" between the parts we standardize in the IETF and the already-established mechanisms for SIP. For example: Specifying the use of stock RTP over UDP would be a perfect match. Using RTP with a hard requirement for STUN would be less of a match, since it would preclude direct media streams with most deployed terminals. Sending media over HTTP would be a complete mismatch, since it would be unable to send media directly to any existing deployed terminals. So this principle would point towards using stock RTP. I think the problem we're running into here is that it's tricky to convey principles in requirements language. Perhaps we need to add a "guiding principles" section to the document that sums up these kind of difficult-to-quantify qualitative goals. /a On 2/9/11 16:42, Feb 9, Lawrence Conroy wrote: > Hi Xavier, folks, > Forgive the dense question, but ... why? > If one wants to gateway, fine. > However, this seems to imply that *all* implementations will interwork with SIP, RTP, ... > Was that intended? > > all the best, > Lawrence > [who has been here before :] > > On 9 Feb 2011, at 19:26, Xavier Marjou wrote: >> Hi Henry, >> >> These requirements certainly do not want to cripple innovation (RTC-Web). >> They rather want to catch attention so that RTC-Web is designed in a way it >> can also work with existing SIP-RTP devices. >> >> Cheers, >> Xavier >> >> On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich >> wrote: >> >>> GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way >>> it allows interworking with SIP-RTP applications both >>> at the signalling and media level. >>> >>> Please help me understand how this and the other requirements do not >>> cripple the whole concept of the RTC-Web (innovation based on simplicity and >>> flexibility) by making it just another extension of legacy telecom design? >>> >>> Or did the authors mean requirements for gateways only? >>> >>> Thanks, Henry > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From goran.ap.eriksson@ericsson.com Wed Feb 9 15:33:30 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4093A67FA for ; Wed, 9 Feb 2011 15:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb40sUtZq3oB for ; Wed, 9 Feb 2011 15:33:29 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3C1AA3A65A6 for ; Wed, 9 Feb 2011 15:33:27 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-5a-4d5324517885 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.F2.13987.154235D4; Thu, 10 Feb 2011 00:33:37 +0100 (CET) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.190]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 10 Feb 2011 00:33:37 +0100 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Adam Roach , Lawrence Conroy Date: Thu, 10 Feb 2011 00:33:35 +0100 Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvIrwDdSI/01s+YS0WBlbI5n90vFAAArWxg Message-ID: References: <16C3E0C6-1EF0-405C-B160-CD2FEE6A1402@insensate.co.uk> <4D531FA0.8090203@nostrum.com> In-Reply-To: <4D531FA0.8090203@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:33:30 -0000 +1=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Adam Roach Sent: den 10 februari 2011 00:14 To: Lawrence Conroy Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-We= b and SIP-RTP I think the intention here is that we don't make decisions that *preclude* reasonable interoperation with legacy SIP systems. No specific i= mplementation will need to interoperate with anything it doesn't need to, o= f course. Unfortunately, it's almost a non-requirement, because everything can be for= ced to interoperate with everything else at some level (in a worst case, by= laying a microphone for one system next to a speaker for the other, pointi= ng a camera at the screen, etc.). I believe we're trying to convey a princi= ple of "least impedance mismatch" between the parts we standardize in the I= ETF and the already-established mechanisms for SIP. For example: Specifying the use of stock RTP over UDP would be a perfect ma= tch. Using RTP with a hard requirement for STUN would be less of a match, s= ince it would preclude direct media streams with most deployed terminals. S= ending media over HTTP would be a complete mismatch, since it would be unab= le to send media directly to any existing deployed terminals. So this princ= iple would point towards using stock RTP. I think the problem we're running into here is that it's tricky to convey p= rinciples in requirements language. Perhaps we need to add a "guiding princ= iples" section to the document that sums up these kind of difficult-to-quan= tify qualitative goals. /a On 2/9/11 16:42, Feb 9, Lawrence Conroy wrote: > Hi Xavier, folks, > Forgive the dense question, but ... why? > If one wants to gateway, fine. > However, this seems to imply that *all* implementations will interwork wi= th SIP, RTP, ... > Was that intended? > > all the best, > Lawrence > [who has been here before :] > > On 9 Feb 2011, at 19:26, Xavier Marjou wrote: >> Hi Henry, >> >> These requirements certainly do not want to cripple innovation (RTC-Web)= . >> They rather want to catch attention so that RTC-Web is designed in a way= it >> can also work with existing SIP-RTP devices. >> >> Cheers, >> Xavier >> >> On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich >> wrote: >> >>> GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way >>> it allows interworking with SIP-RTP applications both >>> at the signalling and media level. >>> >>> Please help me understand how this and the other requirements do not >>> cripple the whole concept of the RTC-Web (innovation based on simplicit= y and >>> flexibility) by making it just another extension of legacy telecom desi= gn? >>> >>> Or did the authors mean requirements for gateways only? >>> >>> Thanks, Henry > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From henry.sinnreich@gmail.com Wed Feb 9 17:48:23 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9243A682D for ; Wed, 9 Feb 2011 17:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GszIf7gLuHdV for ; Wed, 9 Feb 2011 17:48:22 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C8F3B3A682C for ; Wed, 9 Feb 2011 17:48:21 -0800 (PST) Received: by yxt33 with SMTP id 33so407014yxt.31 for ; Wed, 09 Feb 2011 17:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=OHZf946ZylotMjmGClVcmz2/nmoPdGLLRu1ST5QVqzA=; b=PA8WVJJ6mGhEQ6Hk8tw2REsHSCXue+LA8FYJa/syGaM6U9lqsW6onueZ0CuFLunm98 whODz+Hnt2Z1TwcE1oxEIqZSRMhFbdtzCrzVbH7WZvt5Xu8XD3nBm0V08VvBaYcLA9lT o1noMEnwqh9gpSqM3H851FDRPujmSSw+N3fTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=g9/LTwppWlakW+k9PLn2iQZOUEKFfag+1ZbO/Ok5pi8HhWAmfGYgvjYVHShgA9TyUt l6VC6TtHx7SJe/obM3DkMxBm/pq5upZ7W9OWqIO7E/C6qDQZokMRSX2R0f83L4ko7GUF j2586CweRwp0ppmKwgCVP9nd/dKGL1P1UWadc= Received: by 10.150.91.17 with SMTP id o17mr2736469ybb.41.1297302512380; Wed, 09 Feb 2011 17:48:32 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id u31sm616752yba.9.2011.02.09.17.48.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 17:48:31 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 19:48:28 -0600 From: Henry Sinnreich To: Adam Roach , Lawrence Conroy Message-ID: Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvIxJzMuS4UIjdRhEu9mv8I2OHtTA== In-Reply-To: <4D531FA0.8090203@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 01:48:23 -0000 Hi Adam, > Sending media over HTTP would be a complete mismatch, since > it would be unable to send media directly to any existing deployed > terminals. So this principle would point towards using stock RTP. Your comment adds clarity to the fundamental difference of opinions here: http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00 says: The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application". It turns out that as long as the browser platform has the necessary interfaces, it is possible to deliver almost any kind of service on it. So the objective is either A. To enable the browser as the key communication platform, or B. Existing deployed terminals, I suppose you mean SIP phones and SIP UAs The protocol design decisions are naturally very different or even quite opposite. Since it is hard to imagine a SIP phone or SIP UA having a similar infinite rich application potential as the browser has, the choice seems obvious. We will probably not agree on (A) making the browser the protocol design focus and not the (B) existing SIP UA, but is this the core of the disagreement? Thanks, Henry On 2/9/11 5:13 PM, "Adam Roach" wrote: > I think the intention here is that we don't make decisions that > *preclude* reasonable interoperation with legacy SIP systems. No > specific implementation will need to interoperate with anything it > doesn't need to, of course. > > Unfortunately, it's almost a non-requirement, because everything can be > forced to interoperate with everything else at some level (in a worst > case, by laying a microphone for one system next to a speaker for the > other, pointing a camera at the screen, etc.). I believe we're trying to > convey a principle of "least impedance mismatch" between the parts we > standardize in the IETF and the already-established mechanisms for SIP. > > For example: Specifying the use of stock RTP over UDP would be a perfect > match. Using RTP with a hard requirement for STUN would be less of a > match, since it would preclude direct media streams with most deployed > terminals. Sending media over HTTP would be a complete mismatch, since > it would be unable to send media directly to any existing deployed > terminals. So this principle would point towards using stock RTP. > > I think the problem we're running into here is that it's tricky to > convey principles in requirements language. Perhaps we need to add a > "guiding principles" section to the document that sums up these kind of > difficult-to-quantify qualitative goals. > > /a > > > On 2/9/11 16:42, Feb 9, Lawrence Conroy wrote: >> Hi Xavier, folks, >> Forgive the dense question, but ... why? >> If one wants to gateway, fine. >> However, this seems to imply that *all* implementations will interwork with >> SIP, RTP, ... >> Was that intended? >> >> all the best, >> Lawrence >> [who has been here before :] >> >> On 9 Feb 2011, at 19:26, Xavier Marjou wrote: >>> Hi Henry, >>> >>> These requirements certainly do not want to cripple innovation (RTC-Web). >>> They rather want to catch attention so that RTC-Web is designed in a way it >>> can also work with existing SIP-RTP devices. >>> >>> Cheers, >>> Xavier >>> >>> On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich >>> wrote: >>> >>>> GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way >>>> it allows interworking with SIP-RTP applications both >>>> at the signalling and media level. >>>> >>>> Please help me understand how this and the other requirements do not >>>> cripple the whole concept of the RTC-Web (innovation based on simplicity >>>> and >>>> flexibility) by making it just another extension of legacy telecom design? >>>> >>>> Or did the authors mean requirements for gateways only? >>>> >>>> Thanks, Henry >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Thu Feb 10 00:27:35 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428933A69FB for ; Thu, 10 Feb 2011 00:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx-vE3le5Swa for ; Thu, 10 Feb 2011 00:27:34 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DD2E33A69F9 for ; Thu, 10 Feb 2011 00:27:33 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3345354; Thu, 10 Feb 2011 09:27:44 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 479F823F0278; Thu, 10 Feb 2011 09:27:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 10 Feb 2011 09:27:44 +0100 From: "Elwell, John" To: Adam Roach , Lawrence Conroy Date: Thu, 10 Feb 2011 09:27:42 +0100 Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvIrwI20mkxCPVuSxquMRqIVbq5+AAS5IBA Message-ID: References: <16C3E0C6-1EF0-405C-B160-CD2FEE6A1402@insensate.co.uk> <4D531FA0.8090203@nostrum.com> In-Reply-To: <4D531FA0.8090203@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:27:35 -0000 I agree with what Adam says here. We need a way of enabling browser-based R= TC applications while at the same time making it reasonable for those brows= er-based applications that so choose to interoperate with conventional SIP/= RTP entities. By reasonable, I mean without undue complexity, cost or perfo= rmance hit. SIP does not seem to be an issue, because that can be left as a= choice for those applications wanting to work with the outside world. I ge= t the feeling RTP is not such an issue, because a lot of people seem happy = that the browser support conventional RTP. The big issues seem to be STUN a= nd codec support. STUN is not implemented on the vast majority of SIP endpoints, so we need t= o look at solutions to this: using an SBC to mediate between the STUN and S= BC worlds, or using the return RTP stream as evidence when working with con= ventional endpoints, have already been suggested. Concerning codecs, although transcoding can be used, this is highly undesir= able for reasons others have already stated. For audio codecs, it is probab= ly not a big issue to put G.711 in the browser. Video codecs are more of a = challenge. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 09 February 2011 23:14 > To: Lawrence Conroy > Cc: DISPATCH list > Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking=20 > between RTC-Web and SIP-RTP >=20 > I think the intention here is that we don't make decisions that=20 > *preclude* reasonable interoperation with legacy SIP systems. No=20 > specific implementation will need to interoperate with anything it=20 > doesn't need to, of course. >=20 > Unfortunately, it's almost a non-requirement, because=20 > everything can be=20 > forced to interoperate with everything else at some level (in a worst=20 > case, by laying a microphone for one system next to a speaker for the=20 > other, pointing a camera at the screen, etc.). I believe=20 > we're trying to=20 > convey a principle of "least impedance mismatch" between the parts we=20 > standardize in the IETF and the already-established=20 > mechanisms for SIP. >=20 > For example: Specifying the use of stock RTP over UDP would=20 > be a perfect=20 > match. Using RTP with a hard requirement for STUN would be less of a=20 > match, since it would preclude direct media streams with most=20 > deployed=20 > terminals. Sending media over HTTP would be a complete=20 > mismatch, since=20 > it would be unable to send media directly to any existing deployed=20 > terminals. So this principle would point towards using stock RTP. >=20 > I think the problem we're running into here is that it's tricky to=20 > convey principles in requirements language. Perhaps we need to add a=20 > "guiding principles" section to the document that sums up=20 > these kind of=20 > difficult-to-quantify qualitative goals. >=20 > /a >=20 >=20 > On 2/9/11 16:42, Feb 9, Lawrence Conroy wrote: > > Hi Xavier, folks, > > Forgive the dense question, but ... why? > > If one wants to gateway, fine. > > However, this seems to imply that *all* implementations=20 > will interwork with SIP, RTP, ... > > Was that intended? > > > > all the best, > > Lawrence > > [who has been here before :] > > > > On 9 Feb 2011, at 19:26, Xavier Marjou wrote: > >> Hi Henry, > >> > >> These requirements certainly do not want to cripple=20 > innovation (RTC-Web). > >> They rather want to catch attention so that RTC-Web is=20 > designed in a way it > >> can also work with existing SIP-RTP devices. > >> > >> Cheers, > >> Xavier > >> > >> On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich > >> wrote: > >> > >>> GENERIC-REQ-1 The [RTC-Web] solution MUST be designed=20 > in a such way > >>> it allows interworking with SIP-RTP=20 > applications both > >>> at the signalling and media level. > >>> > >>> Please help me understand how this and the other=20 > requirements do not > >>> cripple the whole concept of the RTC-Web (innovation=20 > based on simplicity and > >>> flexibility) by making it just another extension of=20 > legacy telecom design? > >>> > >>> Or did the authors mean requirements for gateways only? > >>> > >>> Thanks, Henry > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From hmmr@cisco.com Thu Feb 10 06:12:02 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0CF3A69A6 for ; Thu, 10 Feb 2011 06:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QasiE0wgqT6l for ; Thu, 10 Feb 2011 06:12:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C1A583A69A4 for ; Thu, 10 Feb 2011 06:12:00 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAEmBU02tJXHB/2dsb2JhbACXDY5cc55nmzeFXASFAYowgwY X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="213842333" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2011 14:12:02 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p1AEC1O7015430; Thu, 10 Feb 2011 14:12:01 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 08:12:01 -0600 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: Thu, 10 Feb 2011 08:12:00 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvIxJzMuS4UIjdRhEu9mv8I2OHtTAAZ6Lnw References: <4D531FA0.8090203@nostrum.com> From: "Mike Hammer (hmmr)" To: "Henry Sinnreich" , "Adam Roach" , "Lawrence Conroy" X-OriginalArrivalTime: 10 Feb 2011 14:12:01.0813 (UTC) FILETIME=[7CB45C50:01CBC92C] Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 14:12:02 -0000 If you include both a media gateway as well as a signaling gateway, then there should be no barrier. The question here devolves to whether you want any universality at one level or another,=20 or just bunches of proprietary islands connected by full gateways. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Wednesday, February 09, 2011 8:48 PM To: Adam Roach; Lawrence Conroy Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Hi Adam, > Sending media over HTTP would be a complete mismatch, since > it would be unable to send media directly to any existing deployed > terminals. So this principle would point towards using stock RTP. Your comment adds clarity to the fundamental difference of opinions here: http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00 says: The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application". It turns out that as long as the browser platform has the necessary interfaces, it is possible to deliver almost any kind of service on it. So the objective is either A. To enable the browser as the key communication platform, or B. Existing deployed terminals, I suppose you mean SIP phones and SIP UAs The protocol design decisions are naturally very different or even quite opposite.=20 Since it is hard to imagine a SIP phone or SIP UA having a similar infinite rich application potential as the browser has, the choice seems obvious. We will probably not agree on (A) making the browser the protocol design focus and not the (B) existing SIP UA, but is this the core of the disagreement? Thanks, Henry On 2/9/11 5:13 PM, "Adam Roach" wrote: > I think the intention here is that we don't make decisions that > *preclude* reasonable interoperation with legacy SIP systems. No > specific implementation will need to interoperate with anything it > doesn't need to, of course. >=20 > Unfortunately, it's almost a non-requirement, because everything can be > forced to interoperate with everything else at some level (in a worst > case, by laying a microphone for one system next to a speaker for the > other, pointing a camera at the screen, etc.). I believe we're trying to > convey a principle of "least impedance mismatch" between the parts we > standardize in the IETF and the already-established mechanisms for SIP. >=20 > For example: Specifying the use of stock RTP over UDP would be a perfect > match. Using RTP with a hard requirement for STUN would be less of a > match, since it would preclude direct media streams with most deployed > terminals. Sending media over HTTP would be a complete mismatch, since > it would be unable to send media directly to any existing deployed > terminals. So this principle would point towards using stock RTP. >=20 > I think the problem we're running into here is that it's tricky to > convey principles in requirements language. Perhaps we need to add a > "guiding principles" section to the document that sums up these kind of > difficult-to-quantify qualitative goals. >=20 > /a >=20 >=20 > On 2/9/11 16:42, Feb 9, Lawrence Conroy wrote: >> Hi Xavier, folks, >> Forgive the dense question, but ... why? >> If one wants to gateway, fine. >> However, this seems to imply that *all* implementations will interwork with >> SIP, RTP, ... >> Was that intended? >>=20 >> all the best, >> Lawrence >> [who has been here before :] >>=20 >> On 9 Feb 2011, at 19:26, Xavier Marjou wrote: >>> Hi Henry, >>>=20 >>> These requirements certainly do not want to cripple innovation (RTC-Web). >>> They rather want to catch attention so that RTC-Web is designed in a way it >>> can also work with existing SIP-RTP devices. >>>=20 >>> Cheers, >>> Xavier >>>=20 >>> On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich >>> wrote: >>>=20 >>>> GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way >>>> it allows interworking with SIP-RTP applications both >>>> at the signalling and media level. >>>>=20 >>>> Please help me understand how this and the other requirements do not >>>> cripple the whole concept of the RTC-Web (innovation based on simplicity >>>> and >>>> flexibility) by making it just another extension of legacy telecom design? >>>>=20 >>>> Or did the authors mean requirements for gateways only? >>>>=20 >>>> Thanks, Henry >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Thu Feb 10 07:39:59 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546003A67EC for ; Thu, 10 Feb 2011 07:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6gqlqo44KTx for ; Thu, 10 Feb 2011 07:39:58 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0271C3A6886 for ; Thu, 10 Feb 2011 07:39:57 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1AFe6PK094302 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 09:40:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D5406D5.90903@nostrum.com> Date: Thu, 10 Feb 2011 09:40:05 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:39:59 -0000 On 2/9/11 19:48, Feb 9, Henry Sinnreich wrote: > Hi Adam, > >> Sending media over HTTP would be a complete mismatch, since >> it would be unable to send media directly to any existing deployed >> terminals. So this principle would point towards using stock RTP. > Your comment adds clarity to the fundamental difference of opinions here: > > http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00 > says: > > The last few years have also seen a new platform rise for deployment > of services: The browser-embedded application, or "Web application". > It turns out that as long as the browser platform has the necessary > interfaces, it is possible to deliver almost any kind of service on > it. If you think what I said and what Harald says in that passage are at odds, then you're misunderstanding one of us. I agree with the general principle that this effort is best served by designing an infrastructure to support browser-embedded applications. That doesn't mean that we need to throw away all the work that's been done in the AVT working group over the past couple of decades. Are you really advocating that we say real-time-multimedia over HTTP/TCP with a same-origin policy is good enough, and that we don't need to specify anything better tailored for realtime media? /a From Markus.Isomaki@nokia.com Thu Feb 10 12:04:13 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7512D3A6A6C for ; Thu, 10 Feb 2011 12:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGkv5lQLpYvl for ; Thu, 10 Feb 2011 12:04:12 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 4A9BF3A6A5C for ; Thu, 10 Feb 2011 12:04:10 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1AK4Lrt005292; Thu, 10 Feb 2011 22:04:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Feb 2011 22:04:16 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Feb 2011 21:04:15 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Thu, 10 Feb 2011 21:04:15 +0100 From: To: Thread-Topic: [dispatch] RTCWEB I-D with thoughts on the framework Thread-Index: AQHLx59UeS6RSYyQq0yl53bwLn9H+pP5jHbQgAAitACAAXh/wA== Date: Thu, 10 Feb 2011 20:04:14 +0000 Message-ID: References: <4D5157CE.4080300@jdrosen.net> <4D53133A.1090703@jdrosen.net> In-Reply-To: <4D53133A.1090703@jdrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2011 20:04:16.0161 (UTC) FILETIME=[B1C1F110:01CBC95D] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:04:13 -0000 Hi, Jonathan Rosenberg wrote: > >> But how about gathering the candidate >> addresses? > >This would be orchestrated by the Javascript (and server as needed) by >telling the browser how to use STUN. I had in mind an API that might >look like: > >{IPaddr:port} =3D STUNCheck(destinationIP, > destinationPort, > username, > password, > AttributeValues); > >To gather a server reflexive, the Javascript uses this API against a >server IP/port which the application provider knows is a STUN server of >its choosing. > Looks good to me. >To gather a relayed candidate, the Javascript once again uses this API >against a server IP/port, but this STUN server acts like a TURN server >of sorts. The STUN check is merely used to create the NAT binding to >allow for relayed traffic to reach the client. The actual relayed >candidate and other semantics of the relay operation can be handled by >the server entirely. This is kind of like the old slushy proposal if >anyone remembers that... > OK, I can see that this would be the bare minimum needed to support UDP rel= aying. >There are clearly some benefits to using TURN directly - primarily it >would allow more easy reuse of existing servers. However, if we focus on >a minimum browser capability, a basic STUN probe which returns a >reflexive candidate is actually sufficient; TURN is not needed even for >the purposes of gathering relayed candidates for interoperable ICE. > I think this is an issue that deserves more discussion. I don't have a stro= ng opinion about it yet. I would say that if a lot of service providers alr= eady use or intend to use TURN servers, it should be included in the browse= r. Those providers who don't use it could still use something else and just= utilize the STUN probe from the browser.=20 Markus From henry.sinnreich@gmail.com Thu Feb 10 13:06:31 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746FC3A69E5 for ; Thu, 10 Feb 2011 13:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8-acBXOw2PI for ; Thu, 10 Feb 2011 13:06:30 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 36E553A67B8 for ; Thu, 10 Feb 2011 13:06:30 -0800 (PST) Received: by gxk27 with SMTP id 27so873099gxk.31 for ; Thu, 10 Feb 2011 13:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=e5pPGJHuM9YnOByodfaLPSEx2HBMNpKcDqJyuStkSvI=; b=o+hT9F9DFYvg0T+4H5ehoZBmgYLmgCapMJZ0O9CgCBzdshD/wrIVruOl3JgeMMLDw1 QjrFbw0lo3QyosUqVNY5FCO+Ognl38OCyuXhsh+sPAA/T+HM4nK/rSU7/6jr/Vkc/57T luB1oi/BXcDdMOzcuz8d8TuSdZTddyFGUrAxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=PplvzCctOKVJJ0ekAcqTF1zlk0/olgAaqdwO9bHfcdlCDvJmYo58KjqzbGJpN02Hug WNCqXDezMG5tP0MygTm3HGqBHottUMC0hcaSxqiEnZ4pjmVwWSpKFTFcXXI+Jo1pukI9 1lj+9U3zNxJgaafK3xcjnDn+RzsE0Uv3jtgkQ= Received: by 10.151.141.8 with SMTP id t8mr3986950ybn.235.1297372001215; Thu, 10 Feb 2011 13:06:41 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id v6sm298671ybk.20.2011.02.10.13.06.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Feb 2011 13:06:40 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 10 Feb 2011 15:06:38 -0600 From: Henry Sinnreich To: Adam Roach Message-ID: Thread-Topic: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Thread-Index: AcvJZmgROTnul48b4UylbiVtTduUFA== In-Reply-To: <4D5406D5.90903@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 21:06:31 -0000 Hi Adam, folks, >If you think what I said and what Harald says in that passage are at >odds, then you're misunderstanding one of us. Thanks for clarifying and I am happy it is only my mistake. >I agree with the general principle that this effort is best served by >designing an infrastructure to support browser-embedded applications. Do you mean a Web application infrastructure and not another VoIP-like network infrastructure? If so, this is another good agreed point to check off. >That doesn't mean that we need to throw away all the work that's been >done in the AVT working group over the past couple of decades. Correct. The AVT work has generated world wide accepted standards that are a reason of legitimate pride. However, other technologies have emerged since that matter just as much: * Skype for p2p and especially relevant here for using UDP without any RTP or SDP. Fully effective NAT traversal. Superior codecs, security, etc. Yes, Skype is proprietary (though reasonably well understood), but we can learn from what Skype DID NOT DO. * Streaming HTTP instead of RTP, such as in http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 While RTC require lower delay, say 150ms, the technique can be adjusted to work for nearby media servers, say inside ISP domains, as CDN do. For remote media servers, existing CDN/HTTP technologies are relevant. Both the above require TCP as you mention and for this, the 3rd ingredient may be an even better solution: * HIP for NAT traversal, secure UDP inside VPN-like tunnels, IPv6 transition, mobility and multihoming. http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09 * Allow/encourage the deployment of proprietary endpoints as Jonathan Rosenberg mentions (did I understand right?), such as Flash and Silverlight; virtual machines (VM) that justifiably benefit from the e2e principle and from the RIA/Web architecture. Such proprietary VM and other apps will naturally always be ahead of standards and may not be standardized ever, though many parts are often offered as OS SW. >Are you really advocating that we say real-time-multimedia over HTTP/TCP >with a same-origin policy is good enough, and that we don't need to >specify anything better tailored for realtime media? HTTP/TCP is certainly not good enough, but a combination of the above will definitely meet all possible requirements we know about at present. Even more important, such a solution fully meets the criteria of freedom to innovate and to have flexibility. Last but not least, hastily word processed standards have been shown to come to a just a as speedy end. Consensus and process is no substitute for engineering and experimenting. Putting this together in a meaningful way requires experimenting first and writing standards second. That's where the IRG comes in, jointly with vendor labs interested to advance this work. My two cents. Thanks for the excellent focus, Henry On 2/10/11 9:40 AM, "Adam Roach" wrote: > On 2/9/11 19:48, Feb 9, Henry Sinnreich wrote: >> Hi Adam, >> >>> Sending media over HTTP would be a complete mismatch, since >>> it would be unable to send media directly to any existing deployed >>> terminals. So this principle would point towards using stock RTP. >> Your comment adds clarity to the fundamental difference of opinions here: >> >> http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00 >> says: >> >> The last few years have also seen a new platform rise for deployment >> of services: The browser-embedded application, or "Web application". >> It turns out that as long as the browser platform has the necessary >> interfaces, it is possible to deliver almost any kind of service on >> it. > > If you think what I said and what Harald says in that passage are at > odds, then you're misunderstanding one of us. > > I agree with the general principle that this effort is best served by > designing an infrastructure to support browser-embedded applications. > > That doesn't mean that we need to throw away all the work that's been > done in the AVT working group over the past couple of decades. > > Are you really advocating that we say real-time-multimedia over HTTP/TCP > with a same-origin policy is good enough, and that we don't need to > specify anything better tailored for realtime media? > > /a From stefan.lk.hakansson@ericsson.com Fri Feb 11 06:25:23 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED593A69A5 for ; Fri, 11 Feb 2011 06:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3Y6KgDPcUvX for ; Fri, 11 Feb 2011 06:25:22 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C85DA3A685A for ; Fri, 11 Feb 2011 06:25:21 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-57-4d5546df8282 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AA.84.23694.FD6455D4; Fri, 11 Feb 2011 15:25:35 +0100 (CET) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.190]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 11 Feb 2011 15:25:35 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Jonathan Rosenberg Date: Fri, 11 Feb 2011 15:25:35 +0100 Thread-Topic: [dispatch] RTCWEB I-D with thoughts on the framework Thread-Index: AcvHn0qLh/q2oAqPQsOGAihvzD0z9ACV/9Ug Message-ID: References: <4D5157CE.4080300@jdrosen.net> In-Reply-To: <4D5157CE.4080300@jdrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtc-web@alvestrand.no" , 'DISPATCH list' Subject: Re: [dispatch] RTCWEB I-D with thoughts on the framework X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 14:25:23 -0000 I agree to large parts of the document, and I think that the section on int= eroperability with existing VoIP gear brings up important aspects. However, I am not completely comfortable with a couple of things: * The application would be responsible for rate adaptation, but what is the= incentive for the application developer to do something that is fair to ot= her applications or users? I would prefer that this is part of the browser = (and with the auto update feature most browsers use the update cycles could= be short anyway) * Are you suggesting that the