From R.Jesske@telekom.de Thu Jul 2 05:41:55 2009 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 E69653A6DA5 for ; Thu, 2 Jul 2009 05:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0GfjpT84HT3N for ; Thu, 2 Jul 2009 05:41:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 3EBF73A6DA8 for ; Thu, 2 Jul 2009 05:40:39 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 02 Jul 2009 14:38:47 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 14:38:47 +0200 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_01C9FB12.0B2FCFC4" Date: Thu, 2 Jul 2009 14:38:45 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404943A57@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acn7EgmFHY5NLHSnTdacRdukHKWXGA== From: To: X-OriginalArrivalTime: 02 Jul 2009 12:38:47.0398 (UTC) FILETIME=[0B476060:01C9FB12] Subject: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 02 Jul 2009 12:41:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FB12.0B2FCFC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, At the moment I'm preparing a new version of = draft-jesske-sipping-etsi-ngn-reason-04 ( = http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-reason-04 ) to = be submitted. There were some comments which were stating that this is the wrong group = for the draft. I would like to know what the feeling of the group is to which group = (BLISS, DISPATCH or SIPCORE) this draft should belong. Thank you and Best Regards Roland Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Roland Jesske=20 Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=20 Postfach, 64307 Darmstadt (Postanschrift)=20 +496151 628 2766 (Tel) +491718618445 (Mobile)=20 E-Mail: r.jesske@telekom.de=20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 ------_=_NextPart_001_01C9FB12.0B2FCFC4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-jesske-sipping-etsi-ngn-reason-04

Dear all,
At the moment I'm preparing a new = version of draft-jesske-sipping-etsi-ngn-reason-04 ( http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-r= eason-04 ) to be = submitted.

There were some comments which were = stating that this is the wrong group for the draft.
I would like to know what the feeling = of the group is to which group (BLISS, DISPATCH or SIPCORE) this draft = should belong.

Thank you and Best Regards

Roland

Deutsche Telekom = Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Gateways, Protokolle, Konvergenz, = TE32-1
Heinrich-Hertz-Str. 3-7, 64295 = Darmstadt,
Postfach, 64307 Darmstadt = (Postanschrift)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de=20



Registerrechtliche = Unternehmensangaben:=20
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262


------_=_NextPart_001_01C9FB12.0B2FCFC4-- From alan@sipstation.com Thu Jul 2 14:06:18 2009 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 E118A3A68CD for ; Thu, 2 Jul 2009 14:06:18 -0700 (PDT) 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=[AWL=0.000, 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 8q0eZ5RXTwZz for ; Thu, 2 Jul 2009 14:06:18 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 135213A6807 for ; Thu, 2 Jul 2009 14:06:18 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MMTUO-000ANW-7H for dispatch@ietf.org; Thu, 02 Jul 2009 21:06:40 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19M+j8zfkl3qLE+MQe3d9NErGHjXe3KO28= Message-ID: <4A4D215E.8020608@sipstation.com> Date: Thu, 02 Jul 2009 16:06:38 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: New Version Notification for draft-johnston-dispatch-sip-cc-uui-00 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, 02 Jul 2009 21:06:19 -0000 This draft contains the requirements analysis, scenarios, and call flows from draft-johnston-sipping-cc-uui-07, as it was Last Called in the SIPPING WG. I will be submitting proposed charter text for a mechanism to meet this requirements to the DISPATCH list after July 13 for discussion prior to IETF-75. Discussion is most welcome. Thanks, Alan -------- Original Message -------- Subject: New Version Notification for draft-johnston-dispatch-sip-cc-uui-00 Date: Thu, 2 Jul 2009 13:55:28 -0700 (PDT) From: IETF I-D Submission Tool To: alan@sipstation.com CC: joanne@avaya.com A new version of I-D, draft-johnston-dispatch-sip-cc-uui-00.txt has been successfuly submitted by Alan Johnston and posted to the IETF repository. Filename: draft-johnston-dispatch-sip-cc-uui Revision: 00 Title: Requirements for Transporting User to User Call Control Information in SIP for ISDN Interworking Creation_date: 2009-07-02 WG ID: Independent Submission Number_of_pages: 11 Abstract: Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document discusses requirements and approaches. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is an Automatic Call Distributor (ACD) in a contact center. The IETF Secretariat. From alan@sipstation.com Thu Jul 2 14:09:53 2009 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 C0C663A68A2 for ; Thu, 2 Jul 2009 14:09:53 -0700 (PDT) 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=[AWL=0.000, 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 4ivXhTSN4CJf for ; Thu, 2 Jul 2009 14:09:53 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 00DFF3A68DA for ; Thu, 2 Jul 2009 14:09:52 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MMTXr-000C6L-4G for dispatch@ietf.org; Thu, 02 Jul 2009 21:10:15 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18bMmyVz3AIBwJYafLHL+FfPlfeoh9f0E4= Message-ID: <4A4D2235.50205@sipstation.com> Date: Thu, 02 Jul 2009 16:10:13 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: New Version Notification for draft-johnston-sipping-cc-uui-08 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, 02 Jul 2009 21:09:53 -0000 This revision of the document references the requirements, use cases, and call flows in draft-johnston-dispatch-sip-cc-uui and proposes a new SIP header field User-to-User. New to this mechanism are the "purpose" and "content" header field parameters which help tag and identify the UUI information carried in the header field. Discussion of this mechanism, which the authors feel best meets these requirements, is most welcome. Thanks, Alan -------- Original Message -------- Subject: New Version Notification for draft-johnston-sipping-cc-uui-08 Date: Thu, 2 Jul 2009 14:00:35 -0700 (PDT) From: IETF I-D Submission Tool To: alan@sipstation.com CC: joanne@avaya.com A new version of I-D, draft-johnston-sipping-cc-uui-08.txt has been successfuly submitted by Alan Johnston and posted to the IETF repository. Filename: draft-johnston-sipping-cc-uui Revision: 08 Title: Transporting User to User Call Control Information in SIP for ISDN Interworking Creation_date: 2009-07-02 WG ID: Independent Submission Number_of_pages: 12 Abstract: Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document discusses three mechanisms to meet the requirements defined in the Requirements for SIP Call Control UUI document. A new SIP header field which bests meets these requirements is proposed. The IETF Secretariat. From pkyzivat@cisco.com Thu Jul 2 16:11:35 2009 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 9C62C3A69BF for ; Thu, 2 Jul 2009 16:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Dm6ep4kuu4K7 for ; Thu, 2 Jul 2009 16:11:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4483328C10B for ; Thu, 2 Jul 2009 16:09:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,337,1243814400"; d="scan'208";a="208986660" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2009 23:10:15 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n62NAF0s018736; Thu, 2 Jul 2009 16:10:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n62NAEBJ028046; Thu, 2 Jul 2009 23:10:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 19:10:14 -0400 Received: from [161.44.182.248] ([161.44.182.248]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 19:10:14 -0400 Message-ID: <4A4D3E55.80307@cisco.com> Date: Thu, 02 Jul 2009 19:10:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alan Johnston References: <20090702211501.52B5B3A6B6C@core3.amsl.com> In-Reply-To: <20090702211501.52B5B3A6B6C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 23:10:14.0588 (UTC) FILETIME=[41CDC7C0:01C9FB6A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5546; t=1246576215; x=1247440215; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20I-D=20Action=3Adraft-johnston-sipping-c c-uui-08.txt |Sender:=20; bh=PY7ULA8BrxqAPe17Tk0WfJ65cmKpoF4Y5ZXeF/Vjxfw=; b=hobrxf6KXjvYWTLoXQh0+QJjywHxQ+rKdTe9YgZbq/2OycJUFSVuXwpaUy vRd5t+rbcmTodYAw8/lx/AQKRzr+FY1CrqSrR0sM6Ruw4IsI3SaJEovSlaIP mQfg2S5rJN; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 02 Jul 2009 23:11:35 -0000 Hi Alan, I took a quick look at this doc and the requirements doc as well. I have a few thoughts: From section 1: > In the future, where both endpoints are intelligent SIP user agents, > it may be possible for them to understand and interpret the UUI data. > There may be some cases where the UUI information is relevant to SIP. > In this case, it might be worthwhile attempting to map UUI data to an > appropriate SIP header field or to standardize a new header field. > However, the requirements and use cases for this are different enough > from those described in this document that these two situations > should be examined separately. This document looks only at the > requirements and mechanisms for replicating the existing, widely used > and deployed ISDN UUI service. This *still* troubles me! Is the assumption here that *both* the UAC and UAS are gateways, so that this mechanism is solely for the tunneling of Q.931 and Q.763 UUI message over SIP? I get the impression that an important use case is where at least *one* end (probably the UAS) is a SIP device. In that case it will already be *necessary* for it to understand and interpret UUI data. And where there is redundancy between SIP data and the UUI data, it will need to resolve the discrepancy. Shouldn't that all be in scope here? > 3.1. Why INFO is Not Used ... > control user-to-user information, INFO can not be used. As the call > flows in the previous section show, the information is related to an There are no call flows in the previous section. (They are now in another document.) > 3.2. MIME body Approach > > One method of transport is to transport the UUI information as a MIME > body. This is in keeping with the SIP-T architecture [RFC3372] in > which MIME bodies are used to transport ISUP information. Since the > INVITE will normally have an SDP message body, the resulting INVITE > with SDP and UUI will be multipart MIME. This is not ideal as many > SIP UAs do not support multipart MIME INVITEs. I don't understand this argument, since *no* SIP UAs currently support the UUI approach being proposed. The only entities that need to understand this are the UAC and the UAS. Both of them will have to support this UUI stuff for it to be used. If it were to be transported via Mime then that is what they would implement. But the above is just nit picking, since I do agree with the problem of using mime bodies with REFER. I don't have any real problem with using a new header for this. > 5. Syntax for UUI Header Field ... > UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param) > uui-data = token > uui-param = enc-param | cont-param | purp-param | generic-param > enc-param = "encoding=" ("hex" | token) > cont-param = "content=" ("isdn-uui" | token) > purp-param = "purpose=" ("isdn-interwork" | token) At the very least, I would request that this be expanded a little bit for future flexibility, by permitting the uui-data to be either a token or a string. While the encoding you have chosen works as a token, other encodings may need the additional flexibility of a string. uui-data = token | quoted-string > 6.3. Registration of SIP Option Tag This section registers the new option tag. But I find almost nothing that defines the semantics of the option. (Section 5 does include the following: > A UA that supports this feature and the "uui" option tag MUST support > the call flows in [johnston-dispatch-sip-cc-uui]... but that is pretty thin from a normative perspective. Of particular note, does support for the option tag mean support for the particular encoding, content, and purpose included in this document? Or does it only mean support for the header and params in the abstract? (That wouldn't be very useful.) I don't see how it can mean support for some other yet to be defined values for those. Yet if it only means support for the current ones, then how will one indicate support for future ones? The only way out of this that I can see is to have separate options, either for particular values of each parameter, or for particular combinations of values of all the parameters. So you might have options uui-purpose-isdn-interwork, uui-content-isdn, and uui-encoding-hex. Or you might just have option uui-isdn-interwork that means the combination. I also am not finding much explanation of the semantics of the content and purpose parameters. I can only extrapolate from a single example of each, which I'm having trouble doing. I'm guessing that 'content' must refer to the precise syntax of the contained data, after decoding. So presumably it must map onto some particular spec. For isdn-uui, would that be [Q931] or [Q763]? If so, shouldn't it refer to something specific in that document? 'purpose' is even less clear to me. Does it refer to why it is being included? Or what is to be done with it? If received by a UA that is not an ISDN gateway, how can it decide if this is something it should be trying to process? Is it still ISDN interworking if neither the UAC nor UAS is connected to an ISDN network? Suppose I was developing a sophisticated UA that potentially might be usable by a call center operator. How should purpose=isdn-interwork affect the operation of this device? Thanks, Paul From victor.pascual.avila@gmail.com Fri Jul 3 06:40:23 2009 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 5D3FC3A68C0; Fri, 3 Jul 2009 06:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 8P+-gYxL1+gC; Fri, 3 Jul 2009 06:40:22 -0700 (PDT) Received: from mail-bw0-f207.google.com (mail-bw0-f207.google.com [209.85.218.207]) by core3.amsl.com (Postfix) with ESMTP id 579F73A6E0C; Fri, 3 Jul 2009 06:40:10 -0700 (PDT) Received: by bwz3 with SMTP id 3so361319bwz.37 for ; Fri, 03 Jul 2009 06:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wXnrvZnoJThKLY7YESLSRVQbzLG7OPnksegz8jNUiUA=; b=KfkRtjb+UZ7h7UkjhYIxNhfFpp56zYNhm9u4amxes5CH3pKXSYF8+16MMXpueY/nSa AZLX+rkV1PhHZHfRWviVHjGLeuBgdjbfKV/GZaYHwTLAhnlLTerGKzy6V3weurRBPNEa 5p01riTt6nuDT7PSOCjPxKWQfWPvfbRXdUoM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=H1oEQq0LDE2IgtD9/0NPZfV12/bQbcH/qdnEE0Ug4L3VpjLrzv2zzbwK0kpwrIk+Jk Xkd35HGm8aOIE1qCZB6Q8w97IKChE1dEut4ywsgG2lAbGML+QLEfp9QK32AHFSmOVq8g Tu6P0rT4zV4AeHoy8fXphukDUPvewPi3IKzto= MIME-Version: 1.0 Received: by 10.204.79.20 with SMTP id n20mr1281720bkk.78.1246628430637; Fri, 03 Jul 2009 06:40:30 -0700 (PDT) Date: Fri, 3 Jul 2009 15:40:30 +0200 Message-ID: <618e24240907030640k2898f908s450626af73dad5f8@mail.gmail.com> From: Victor Pascual Avila To: sip-ops@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: [dispatch] I-D Action:draft-kuthan-dispatch-diagrevived-00.txt 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, 03 Jul 2009 13:40:23 -0000 Hi Folks, We have just submitted a draft which proposes a new header field called Debug. The purpose of this header field is to convey extra debugging information that can be used to locate errors in SIP entities involved in the processing of a SIP transaction. Abstract: A major responsibility of Session Initiation Protocol (SIP) servers is to provide application-layer routing. SIP routing can be quite complex and lead to similarly complicated paths that SIP requests traverse on the way to their actual destinations. It is therefore important to be in position to troubleshoot errors that occur along a SIP path, inside and outside troubleshooters' administrative domains. Particularly important for the troubleshooters is knowledge of where an error occurred in a SIP path. This document introduces a new header field called Debug. The purpose of the header field is to convey extra debugging information that can be used to locate errors in SIP implementations involved in processing of a SIP transaction. A temporal URL for this Internet-Draft is: http://www.ietf.org/proceedings/staging/draft-kuthan-dispatch-diagrevived-0= 0.txt Comments are welcome! Regards, --=20 Victor Pascual =C3=81vila From xavier.marjou@gmail.com Fri Jul 3 08:05:51 2009 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 F0E8528C1D7 for ; Fri, 3 Jul 2009 08:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qS4qRNFDuu47 for ; Fri, 3 Jul 2009 08:05:51 -0700 (PDT) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id F2A4428C28E for ; Fri, 3 Jul 2009 08:05:50 -0700 (PDT) Received: by ewy11 with SMTP id 11so1137035ewy.37 for ; Fri, 03 Jul 2009 08:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=snOp5C3fDf8WyyBBeTwsvN2fw+rATj9CEdZr4Mv0d+c=; b=TWWNBEaSO9UEf0Elt7XohqOjOzloLODhw0XUREg1TbgeKT0A9zWTrvEN7s0Mp8a6WO p43onBi3Al7xzye4xkMgeCgh7xYM6n8kNkXLq5oA80U5eEvMFxTHkSIWyTgs9sMoc75z h2bgnGWWmTI+NOncD/qkcoUqTB09oCeoMCs0E= 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:content-type:content-transfer-encoding; b=R9ysoLtJOXFJ0kiK9pbLQITCA2oG61OwTCSdqoft1I1buO2+Hh64L37Dbm71yHYqQ6 l/VTcMQM2DqJ5ubVwVxpopy++gkHmkmDmYQ2KiNJADle1W07ZhB4mT6P7ZP3ke/esBQC qo1vAPuMXqGnr4sDxzQ9l5tGnvM/IECtIWV3I= MIME-Version: 1.0 Sender: xavier.marjou@gmail.com Received: by 10.216.0.206 with SMTP id 56mr374863web.102.1246633565607; Fri, 03 Jul 2009 08:06:05 -0700 (PDT) Date: Fri, 3 Jul 2009 17:06:05 +0200 X-Google-Sender-Auth: ff1eee635422a6d3 Message-ID: <458913680907030806u64369fb3jd2c8ce37cdf7e3cc@mail.gmail.com> From: Xavier Marjou To: dispatch@ietf.org, Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dispatch] draft-shen-interaction-ind 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, 03 Jul 2009 15:05:52 -0000 Hi, As it seems there will be time for additional topics, I have a suggestion:=A0I would be interested by a presentation of the following draft:=A0http://tools.ietf.org/html/draft-shen-interaction-ind-05 Cheers, Xavier On Fri, Jun 26, 2009 at 12:51 AM, Mary Barnes wrot= e: > > Hi folks, > > We have uploaded a revised (tentative) agenda for IETF-75 for the > DISPATCH WG session: > http://www.ietf.org/proceedings/09jul/agenda/dispatch.html > > Due to popular demand, we have added a slot for Session Recording. Note, > that the current agenda has us meeting on Thursday afternoon, but Cullen > has asked for that to be changed to Monday. As always, the agenda is > subject to change up until the meeting. > > As a reminder any new documents related to the agenda topics must be > submitted by July 6th and any updates to current docs by July 13th. And, > most importantly we really should be seeing traffic on the list on these > topics before the meeting so we can have focused discussions with > conclusions and a well defined way forward. > > Please send any comments on the proposed agenda to the list and/or > Gonzalo and myself. > > Regards, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From alan@sipstation.com Fri Jul 3 09:14:14 2009 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 001403A679F for ; Fri, 3 Jul 2009 09:14:13 -0700 (PDT) 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=[AWL=0.000, 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 PsdWBP0Ys9iP for ; Fri, 3 Jul 2009 09:14:12 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 4BA283A67EB for ; Fri, 3 Jul 2009 09:13:53 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MMlO4-000HaD-IE; Fri, 03 Jul 2009 16:13:21 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19sroYLJbyuiCnd0HRYj7S0sVw7Uqpm/oM= Message-ID: <4A4E2E1E.1050509@sipstation.com> Date: Fri, 03 Jul 2009 11:13:18 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com> In-Reply-To: <4A4D3E55.80307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 03 Jul 2009 16:14:14 -0000 Paul, Thanks for your comments. See mine below. Thanks, Alan Paul Kyzivat wrote: > Hi Alan, > > I took a quick look at this doc and the requirements doc as well. I > have a few thoughts: > > From section 1: > >> In the future, where both endpoints are intelligent SIP user agents, >> it may be possible for them to understand and interpret the UUI data. >> There may be some cases where the UUI information is relevant to SIP. >> In this case, it might be worthwhile attempting to map UUI data to an >> appropriate SIP header field or to standardize a new header field. >> However, the requirements and use cases for this are different enough >> from those described in this document that these two situations >> should be examined separately. This document looks only at the >> requirements and mechanisms for replicating the existing, widely used >> and deployed ISDN UUI service. > > This *still* troubles me! > Is the assumption here that *both* the UAC and UAS are gateways, so > that this mechanism is solely for the tunneling of Q.931 and Q.763 UUI > message over SIP? > > I get the impression that an important use case is where at least > *one* end (probably the UAS) is a SIP device. In that case it will > already be *necessary* for it to understand and interpret UUI data. > And where there is redundancy between SIP data and the UUI data, it > will need to resolve the discrepancy. Not quite. We are not making the assumption that both are gateways, although that is possible. Most likely, one element is SIP enabled. However, it is not a fully intelligent SIP endpoint - the basic software and application (probably many years old) is unchanged but a SIP interface (SIP trunk) has been added. As such, the SIP stack does not know anything about the UUI as it is implementing exactly the ISDN UUI service - the information is just pushed up the stack to another application, and this application knows nothing about SIP. It still thinks it is using an ISDN trunk. So this mechanism allows us to easily and quickly get SIP into these applications without having to rewrite the entire application to make it SIP aware. Does that make any sense? Honestly don't know how I can explain it more clearly than this. And this is not some corner case or exception - this is a *huge* opportunity for SIP if we can get this mechanism standardized. > > Shouldn't that all be in scope here? For the case I described above, where only SIP trunking is being used, the best you can do is indicate the purpose (the application using the UUI) is the ISDN UUE, and the content is how the ISDN spec defines it - an opaque blob of information. The ISDN does not know if the UUI contains an account number, a name, etc - but the application making use of the SIP trunking does. > >> 3.1. Why INFO is Not Used > ... >> control user-to-user information, INFO can not be used. As the call >> flows in the previous section show, the information is related to an > > There are no call flows in the previous section. (They are now in > another document.) Yes, I missed this in splitting the documents. I need to edit the text a little as well so they go together better but I ran out of time as I'll be out of the office all next week. > >> 3.2. MIME body Approach >> >> One method of transport is to transport the UUI information as a MIME >> body. This is in keeping with the SIP-T architecture [RFC3372] in >> which MIME bodies are used to transport ISUP information. Since the >> INVITE will normally have an SDP message body, the resulting INVITE >> with SDP and UUI will be multipart MIME. This is not ideal as many >> SIP UAs do not support multipart MIME INVITEs. > > I don't understand this argument, since *no* SIP UAs currently support > the UUI approach being proposed. No, Avaya and at least one other vendor have implemented and deployed the User-to-User header field in customer networks. As I said, there is a big demand for this, and the marketplace will not wait much longer for us to get this finalized. But in our, and others, experience, adding support for a single new header field is easy. Adding complete support for Multipart MIME is much harder and impacts many more things. > The only entities that need to understand this are the UAC and the > UAS. Both of them will have to support this UUI stuff for it to be > used. If it were to be transported via Mime then that is what they > would implement. > > But the above is just nit picking, since I do agree with the problem > of using mime bodies with REFER. I don't have any real problem with > using a new header for this. Excellent - I am very glad to hear this. > >> 5. Syntax for UUI Header Field > ... >> UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param) >> uui-data = token >> uui-param = enc-param | cont-param | purp-param | generic-param >> enc-param = "encoding=" ("hex" | token) >> cont-param = "content=" ("isdn-uui" | token) >> purp-param = "purpose=" ("isdn-interwork" | token) > > At the very least, I would request that this be expanded a little bit > for future flexibility, by permitting the uui-data to be either a > token or a string. While the encoding you have chosen works as a > token, other encodings may need the additional flexibility of a string. > > uui-data = token | quoted-string > OK, I guess I'm OK with that. For the isdn-interwork purpose, we'll require the token, but other applications could utilize the quoted string. >> 6.3. Registration of SIP Option Tag > > This section registers the new option tag. But I find almost nothing > that defines the semantics of the option. (Section 5 does include the > following: > >> A UA that supports this feature and the "uui" option tag MUST support >> the call flows in [johnston-dispatch-sip-cc-uui]... > > but that is pretty thin from a normative perspective. > > Of particular note, does support for the option tag mean support for > the particular encoding, content, and purpose included in this > document? Or does it only mean support for the header and params in > the abstract? (That wouldn't be very useful.) Yes, this needs clarification. I'd suggest we define the option tag to be uui-isdn which means it understands the header field and the isdn-interwork purpose, and the call flows, including escaping into redirection and Refer-To URIs. > > I don't see how it can mean support for some other yet to be defined > values for those. Yet if it only means support for the current ones, > then how will one indicate support for future ones? > > The only way out of this that I can see is to have separate options, > either for particular values of each parameter, or for particular > combinations of values of all the parameters. New applications using this header field would have the option of defining a new SIP option tag which would mean support for the header field and their new purpose. > > So you might have options uui-purpose-isdn-interwork, > uui-content-isdn, and uui-encoding-hex. Or you might just have option > uui-isdn-interwork that means the combination. I think the latter. I see it as a hierarchy - the application or purpose is the top one. Each purpose has a number of contents that it supports. Each content has a number of encoding schemes it supports. > > I also am not finding much explanation of the semantics of the content > and purpose parameters. I can only extrapolate from a single example > of each, which I'm having trouble doing. > > I'm guessing that 'content' must refer to the precise syntax of the > contained data, after decoding. So presumably it must map onto some > particular spec. For isdn-uui, would that be [Q931] or [Q763]? If so, > shouldn't it refer to something specific in that document? Not really. In this case, isdn-uui effectively means "opaque data" which is how ISDN defines the UUI - it is completely undefined, necessarily so by the strict layering used in the ISDN application. > > 'purpose' is even less clear to me. Does it refer to why it is being > included? Or what is to be done with it? If received by a UA that is > not an ISDN gateway, how can it decide if this is something it should > be trying to process? Is it still ISDN interworking if neither the UAC > nor UAS is connected to an ISDN network? The purpose is the application using the UUI. Others have expressed an interest in carrying other data in the header field, in which case a new purpose would be defined. I'll see if I can think of an example one. Basically, if two UAs both support the header but have different applications generating and consuming the UUI, it will not work. This is not a SIP failure, and there is nothing SIP can do about it. But this purpose header field allows the UAs to detect this condition. > > Suppose I was developing a sophisticated UA that potentially might be > usable by a call center operator. How should purpose=isdn-interwork > affect the operation of this device? To make it work in today's contact center applications, supporting isdn-interwork would likely make it work in an application, provided the appropriate call center application also ran on it. Some contact centers do not use ISDN UUI, instead they use all kinds of really, really ugly CTI protocols running in parallel. This is a way of moving those to the ISDN model, and from there to a more intelligent endpoint SIP model. > > Thanks, > Paul > > > > From pkyzivat@cisco.com Fri Jul 3 16:40:44 2009 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 33A153A6987 for ; Fri, 3 Jul 2009 16:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 YAe3lqNTRQmJ for ; Fri, 3 Jul 2009 16:40:42 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6ADC83A6C3B for ; Fri, 3 Jul 2009 16:39:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,345,1243814400"; d="scan'208";a="49317702" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2009 23:39:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n63NdV1v013733; Fri, 3 Jul 2009 19:39:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n63NdVCI008825; Fri, 3 Jul 2009 23:39:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 19:39:31 -0400 Received: from [10.86.252.110] ([10.86.252.110]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 19:39:30 -0400 Message-ID: <4A4E96B1.1080005@cisco.com> Date: Fri, 03 Jul 2009 19:39:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alan Johnston References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com> <4A4E2E1E.1050509@sipstation.com> In-Reply-To: <4A4E2E1E.1050509@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2009 23:39:30.0892 (UTC) FILETIME=[830E40C0:01C9FC37] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8987; t=1246664371; x=1247528371; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20I-D=20Action=3Adraft-johnston-sipping-c c-uui-08.txt |Sender:=20 |To:=20Alan=20Johnston=20; bh=gAWtKNF0qP7Q11BorZP8xbjRG2cIbx3QvOU51lSqzaM=; b=aZcB2B57TlCGSGp49PwvNWfOYIgOqrN82TXMoitozelN73ti+sPiSpcQaH sZAOQaaeT8F+yqEHPl17+twJ9H0o3L/L/Q4UZ27SV6ofUF1S4bYd2TT1iTjq wJ724HlTjU; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 03 Jul 2009 23:40:44 -0000 Hi Alan, responses inline. I've trimmed out the parts that don't require more discussion. Thanks, Paul Alan Johnston wrote: > Paul, > > Thanks for your comments. See mine below. > > Thanks, > Alan > > Paul Kyzivat wrote: >> Hi Alan, >> >> I took a quick look at this doc and the requirements doc as well. I >> have a few thoughts: >> >> From section 1: >> >>> In the future, where both endpoints are intelligent SIP user agents, >>> it may be possible for them to understand and interpret the UUI data. >>> There may be some cases where the UUI information is relevant to SIP. >>> In this case, it might be worthwhile attempting to map UUI data to an >>> appropriate SIP header field or to standardize a new header field. >>> However, the requirements and use cases for this are different enough >>> from those described in this document that these two situations >>> should be examined separately. This document looks only at the >>> requirements and mechanisms for replicating the existing, widely used >>> and deployed ISDN UUI service. >> >> This *still* troubles me! >> Is the assumption here that *both* the UAC and UAS are gateways, so >> that this mechanism is solely for the tunneling of Q.931 and Q.763 UUI >> message over SIP? >> >> I get the impression that an important use case is where at least >> *one* end (probably the UAS) is a SIP device. In that case it will >> already be *necessary* for it to understand and interpret UUI data. >> And where there is redundancy between SIP data and the UUI data, it >> will need to resolve the discrepancy. > > Not quite. We are not making the assumption that both are gateways, > although that is possible. Most likely, one element is SIP enabled. > However, it is not a fully intelligent SIP endpoint - the basic software > and application (probably many years old) is unchanged but a SIP > interface (SIP trunk) has been added. As such, the SIP stack does not > know anything about the UUI as it is implementing exactly the ISDN UUI > service - the information is just pushed up the stack to another > application, and this application knows nothing about SIP. It still > thinks it is using an ISDN trunk. Then in the way I meant the question, both ends *are* gateways. But then if someone wishes to build native sip gear to plug into this environment, then it will still have to understand this isdn encoding. Perhaps that is the cruel truth, unless all the equipment is replaced at once. >>> 5. Syntax for UUI Header Field >> ... >>> UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param) >>> uui-data = token >>> uui-param = enc-param | cont-param | purp-param | generic-param >>> enc-param = "encoding=" ("hex" | token) >>> cont-param = "content=" ("isdn-uui" | token) >>> purp-param = "purpose=" ("isdn-interwork" | token) >> >> At the very least, I would request that this be expanded a little bit >> for future flexibility, by permitting the uui-data to be either a >> token or a string. While the encoding you have chosen works as a >> token, other encodings may need the additional flexibility of a string. >> >> uui-data = token | quoted-string > > OK, I guess I'm OK with that. For the isdn-interwork purpose, we'll > require the token, but other applications could utilize the quoted string. I would hope that when the token encoding is sufficient, then either form would be accepted. Or it would perhaps be ok to specify for a particular encoding (hex) that the token encoding must be used. I don't see how the purpose has anything to do with it. >>> 6.3. Registration of SIP Option Tag >> >> This section registers the new option tag. But I find almost nothing >> that defines the semantics of the option. (Section 5 does include the >> following: >> >>> A UA that supports this feature and the "uui" option tag MUST support >>> the call flows in [johnston-dispatch-sip-cc-uui]... >> >> but that is pretty thin from a normative perspective. >> >> Of particular note, does support for the option tag mean support for >> the particular encoding, content, and purpose included in this >> document? Or does it only mean support for the header and params in >> the abstract? (That wouldn't be very useful.) > > Yes, this needs clarification. I'd suggest we define the option tag to > be uui-isdn which means it understands the header field and the > isdn-interwork purpose, and the call flows, including escaping into > redirection and Refer-To URIs. I'd like to hear some other opinions on whether to have tag per param for tag, or a tag for the combination of param values. I think I'm ok with what you propose. >> I don't see how it can mean support for some other yet to be defined >> values for those. Yet if it only means support for the current ones, >> then how will one indicate support for future ones? >> >> The only way out of this that I can see is to have separate options, >> either for particular values of each parameter, or for particular >> combinations of values of all the parameters. > > New applications using this header field would have the option of > defining a new SIP option tag which would mean support for the header > field and their new purpose. > >> So you might have options uui-purpose-isdn-interwork, >> uui-content-isdn, and uui-encoding-hex. Or you might just have option >> uui-isdn-interwork that means the combination. > > I think the latter. I see it as a hierarchy - the application or > purpose is the top one. Each purpose has a number of contents that it > supports. Each content has a number of encoding schemes it supports. I guess I'm ok with that, pending nailing down the definition of "purpose". >> I also am not finding much explanation of the semantics of the content >> and purpose parameters. I can only extrapolate from a single example >> of each, which I'm having trouble doing. >> >> I'm guessing that 'content' must refer to the precise syntax of the >> contained data, after decoding. So presumably it must map onto some >> particular spec. For isdn-uui, would that be [Q931] or [Q763]? If so, >> shouldn't it refer to something specific in that document? > > Not really. In this case, isdn-uui effectively means "opaque data" > which is how ISDN defines the UUI - it is completely undefined, > necessarily so by the strict layering used in the ISDN application. I don't believe you! If that is the case, then the UAC and UAS must have a private side agreement about what the isdn-uui content means. Is that really what you mean? You already state that the first byte is a protocol discriminator. There must also be something, somewhere, that specifies the mapping from a particular value for that byte to a particular protocol/format. If there is, then that should be part of the definition of this content. >> 'purpose' is even less clear to me. Does it refer to why it is being >> included? Or what is to be done with it? If received by a UA that is >> not an ISDN gateway, how can it decide if this is something it should >> be trying to process? Is it still ISDN interworking if neither the UAC >> nor UAS is connected to an ISDN network? > > The purpose is the application using the UUI. Others have expressed an > interest in carrying other data in the header field, in which case a new > purpose would be defined. I'll see if I can think of an example one. So are you saying that a particular call center application might constitute a distinct "purpose"? > Basically, if two UAs both support the header but have different > applications generating and consuming the UUI, it will not work. This > is not a SIP failure, and there is nothing SIP can do about it. But > this purpose header field allows the UAs to detect this condition. In that case, perhaps "isdn-interwork" isn't really a single purpose at all, unless any two pieces of equipment that support that purpose can then interwork without knowing any more about each other. >> Suppose I was developing a sophisticated UA that potentially might be >> usable by a call center operator. How should purpose=isdn-interwork >> affect the operation of this device? > > To make it work in today's contact center applications, supporting > isdn-interwork would likely make it work in an application, provided the > appropriate call center application also ran on it. Some contact > centers do not use ISDN UUI, instead they use all kinds of really, > really ugly CTI protocols running in parallel. Yes, I know! :-( > This is a way of moving > those to the ISDN model, and from there to a more intelligent endpoint > SIP model. > >> Thanks, >> Paul From mary.barnes@nortel.com Sat Jul 4 08:31:43 2009 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 3D8803A6950 for ; Sat, 4 Jul 2009 08:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 6Aj+HCCMx-61 for ; Sat, 4 Jul 2009 08:31:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C4BEA3A69D3 for ; Sat, 4 Jul 2009 08:31:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n64FUQq25840; Sat, 4 Jul 2009 15:30:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Jul 2009 10:34:29 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED2AB60@zrc2hxm0.corp.nortel.com> In-Reply-To: <458913680907030806u64369fb3jd2c8ce37cdf7e3cc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shen-interaction-ind thread-index: Acn778tr+dvpPvmlScuTwsnfii01KAAy3R8g References: <458913680907030806u64369fb3jd2c8ce37cdf7e3cc@mail.gmail.com> From: "Mary Barnes" To: "Xavier Marjou" , Subject: Re: [dispatch] draft-shen-interaction-ind 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, 04 Jul 2009 15:31:43 -0000 Xavier, Can you point the WG to past ML discussions (in any WG) for this = document? I don't recall nor could I find any email threads that = indicate this document had ever been on the radar for the SIPPING WG. = And, as usual, we don't allocate agenda time for documents that have = received no ML discussion and a fair amount of interest in committing to = work on the problem. Per the approach we're taking in DISPATCH, the = work item needs to have a problem description with a defined scope and = definition of a deliverable. I can see this document is defining a = P-header, but the usage of this "service indicator" is not clear to me, = perhaps because it's based on IMS functionality. The one example (alarm = call) seems to be related to emergency services, in which case I would = think the protocol work in ECRIT would be applicable (or if it's = "authority to citizen" then the proposed ATOCA work might apply). If the = author would like to provide a chart or two summarizing the problem the = document is solving, we can present those in the chair charts. =20 Regards, Mary. DISPATCH WG co-chair -----Original Message----- From: xavier.marjou@gmail.com [mailto:xavier.marjou@gmail.com] On Behalf = Of Xavier Marjou Sent: Friday, July 03, 2009 10:06 AM To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00) Subject: draft-shen-interaction-ind Hi, As it seems there will be time for additional topics, I have a suggestion:=A0I would be interested by a presentation of the following draft:=A0 http://tools.ietf.org/html/draft-shen-interaction-ind-05.txt Cheers, Xavier On Fri, Jun 26, 2009 at 12:51 AM, Mary Barnes = wrote: > > Hi folks, > > We have uploaded a revised (tentative) agenda for IETF-75 for the=20 > DISPATCH WG session: > http://www.ietf.org/proceedings/09jul/agenda/dispatch.html > > Due to popular demand, we have added a slot for Session Recording.=20 > Note, that the current agenda has us meeting on Thursday afternoon,=20 > but Cullen has asked for that to be changed to Monday. As always, the=20 > agenda is subject to change up until the meeting. > > As a reminder any new documents related to the agenda topics must be=20 > submitted by July 6th and any updates to current docs by July 13th.=20 > And, most importantly we really should be seeing traffic on the list=20 > on these topics before the meeting so we can have focused discussions=20 > with conclusions and a well defined way forward. > > Please send any comments on the proposed agenda to the list and/or=20 > Gonzalo and myself. > > Regards, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ietf.hanserik@gmail.com Mon Jul 6 04:12:41 2009 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 9CF3F3A6CBA for ; Mon, 6 Jul 2009 04:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, 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 keTz5PuCPjR4 for ; Mon, 6 Jul 2009 04:12:39 -0700 (PDT) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 3052B3A6C96 for ; Mon, 6 Jul 2009 04:12:38 -0700 (PDT) Received: by ewy7 with SMTP id 7so1731419ewy.37 for ; Mon, 06 Jul 2009 04:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=k08m/5D/E4zY6VDoNKyAaDQf3o6Ja9CdRE7pRc9MegE=; b=f/wC3LMxYX+wULO6ssv3oxz8BN3fpwJTqYOTOsnzfYWRejhGXI9jKSYDxlkmh78QV/ tDYs2okEPHKj9vzgBT1NVVj6YImrG81wVmQbaeZXdFkL5FYTtopYq+rSLI4/h719Lsfs Wjzc6z3GkKnE5eN3sfC72MRFAWzF49SFamuxU= 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 :content-type; b=Tp8qfoYJNqxBEuXd5sEkCeC0mdToaexBP0Tzc6clBIMR4sffoNMZ9qPA+gs1hgBmP3 pewdfVkBDkGe78ELfFJ+XCgj+Qs0UGkVwTJUFosqDjvWeAbOvj+HzeV/4+TDefX8X3mj zQhgfzVLMlwE1fsSsvNnokHSCBjuf0KrZxnK8= MIME-Version: 1.0 Received: by 10.210.144.3 with SMTP id r3mr1042754ebd.44.1246878600216; Mon, 06 Jul 2009 04:10:00 -0700 (PDT) In-Reply-To: <9ae56b1e0907060406p3d42b0fdled2bb34f55d6b896@mail.gmail.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001E1A290@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907021519h5093aec3g5023cc7c6a38ba32@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00218C5B3@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907030710i5e51de42icfbcc0d0064b5ddd@mail.gmail.com> <9ae56b1e0907030716w738f1167n889e26694f71087c@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00218C81B@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907060242r7c408393u5333749a88b958a8@mail.gmail.com> <9ae56b1e0907060406p3d42b0fdled2bb34f55d6b896@mail.gmail.com> Date: Mon, 6 Jul 2009 13:10:00 +0200 Message-ID: <9ae56b1e0907060410jd5389f5q81f28279984c8615@mail.gmail.com> From: Hans Erik van Elburg To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary=0015174be6d20b4185046e078c0c Subject: [dispatch] Fwd: [Sipping] Fwd: Expert review ofdraft-vanelburg-sipping-private-network-indication-03 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, 06 Jul 2009 11:12:41 -0000 --0015174be6d20b4185046e078c0c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The updates after expert review of the draft-vanelburg-sipping-private-network-indication-03 has been submitted to dispatch as: http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-00 or plain text: http://tools.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-00.txt Best Regards, /Hans Erik van Elburg ---------- Forwarded message ---------- From: Hans Erik van Elburg Date: Mon, Jul 6, 2009 at 1:06 PM Subject: Re: [Sipping] Fwd: Expert review ofdraft-vanelburg-sipping-private-network-indication-03 To: "Elwell, John" Cc: "DRAGE, Keith (Keith)" , IETF Sipping List < sipping@ietf.org> Draft has been uploaded as http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-00 Best Regards, /Hans Erik van Elburg On Mon, Jul 6, 2009 at 11:42 AM, Hans Erik van Elburg < ietf.hanserik@gmail.com> wrote: > Hi John, > > 1. Done, moved 10 up and inserted as 1.2. Added the following sentence to > 1.1: > "3GPP and ETSI TISPAN have identified a set of requirements that can be met > by defining a new SIP P-header, according to the procedures in RFC 3427 > [RFC3427]." > 2. Done > 4a. Done > 4b. Done > 4c. Done > 5. I added the following terminology description: > > "3.1. Traffic > > In the context of this document the term traffic is understood as all > communication pertaining to and/or controlled by a SIP transaction or > dialog." > > 8. Done > > Will upload this as cutoff day for 00 drafts is today. > > /Hans Erik van Elburg > > > > On Mon, Jul 6, 2009 at 8:52 AM, Elwell, John < > john.elwell@siemens-enterprise.com> wrote: > >> Hans Erik, >> >> > -----Original Message----- >> > From: sipping-bounces@ietf.org >> > [mailto:sipping-bounces@ietf.org] On Behalf Of Hans Erik van Elburg >> > Sent: 03 July 2009 15:17 >> > To: Elwell, John; DRAGE, Keith (Keith) >> > Cc: IETF Sipping List >> > Subject: [Sipping] Fwd: Expert review >> > ofdraft-vanelburg-sipping-private-network-indication-03 >> > >> > Resent and history removed as otherwise rejected by mailing list. >> > >> > Hi John, >> > >> > 1. Again the required applicability statement is in section >> > 10 of the main body. (Same pattern has been followed in >> > RFC5502, 5002 and 4457) which I took as examples. Together >> > with the additional text in the abstract that should be >> > sufficient. If the text in section 10 needs to be improved >> > then please indicate so. >> [JRE] I must have written the original comment 1 before I got down to >> section 10. Basically section 10 is far too late in the document, and I >> would have expected the statement, perhaps as section 1, or perhaps as a >> section 1.2 before the existing 1.2. >> >> >> > >> > 2. Took in your nits, the abstract now reads: >> > "This document specifies the SIP P-Private-Network-Indication >> > P-header. The use of this private network indication extension >> > is only applicable inside an administrative domain with >> > previously agreed-upon policies for generation, transport and >> > usage of such information. A private network indication >> > allows nodes in such a domain to treat private network traffic >> > according to a different set of rules then than the set >> > applicable to public network traffic. The indication also >> > distinguishes traffic from one private network from another >> > private network." >> [JRE] >> Delete the word "then". >> >> > >> > 4a. Regarding 1.2 item b). Would the following rewrite help?: >> > OLD: >> > " b) business trunking application, where the NGN hosts >> > transit capabilities between NGCN's, break-in capabilities >> > from NGN to NGCN and break-out capabilities from NGCN to NGN; and" >> > /OLD >> > >> > >> > NEW: >> > " b) business trunking application, where the NGN hosts >> > transit capabilities between NGCN's, break-in capabilities >> > where the NGN converts public network traffic to private >> > network traffic for delivery at a served NGCN and break-out >> > capabilities where the NGN converts private network traffic >> > from a served NGCN to public network traffic; and" >> > >> > /NEW >> > >> > If not please suggest an improved sentence that covers your >> > concern. Please note that in the example that you gave it is >> > not the business trunking application that does the >> > conversion, but the hosted enterprise application. >> [JRE] That would do. >> >> >> > >> > 4b. "normal rules" >> > Looking at the definition, would the following rewrite help: >> > OLD >> > " Traffic sent to or received from a public telecommunication >> > network for processing according to the normal rules." >> > /OLD >> > >> > NEW >> > " Traffic sent to or received from a public telecommunication >> > network for processing according to the rules for ordinary >> > subscribers of a public telecommunication network." >> > /NEW >> [JRE] That would do. >> >> > >> > 4c. NGN is a public telecommunication network >> > > - "To summarize a few example reasons for a public >> > telecommunication network to make the distinction between the >> > two types of traffic" Isn't it an NGN that needs to make the >> > distinction? >> > > [HE] NGN is a public telecommunication network. But we can >> > rephrase to: "To summarize a few example reasons for a public >> > NGN to make the distinction between the two types of traffic" [/HE] >> [JRE] OK >> >> > >> > [JRE] I think that is the problem I am having. I believe an >> > NGN is a network infrastructure that supports both public >> > network traffic and private network traffic, or in other >> > words it supports both a public network and a number of >> > private networks.[/JRE] >> > [HE2]Yes, but its main purpose is to serve as a public >> > network with all the regulations that apply to such networks >> > etc. This does not prohibit an NGN to be used as a private >> > network of course, but still it has been designed from the >> > perspective of having to serve the needs of public network >> > operators. That is why the "normal"/default procedures are >> > for public network traffic. As we want to introduce the >> > capability for such a public network (NGN) to also support >> > private network traffic that has to be processed to a >> > different set of rules, the Private-Network-Indication is >> > needed.[/HE2] >> > >> > >> > 5. Traffic --> SIP traffic >> > Calling traffic SIP traffic suggest that the media is not >> > part of the traffic, is that what we want?? >> [JRE] The point is, it is not HTTP traffic or FTP traffic or SMTP >> traffic or whatever. >> >> > >> > >> > 6. Example private network traffic can also exist between two >> > different enterprises >> > Where would you like to see this? Obviously section 1.2 is >> > not the right place for such an example. >> > Isn't this too obvious, if you imagine that two companies >> > have agreed to form a cooperation and communicate under this >> > agreement? >> > Would you like to see this as an additional example in section 4? >> [JRE] I was not necessarily seeking a further example. However, given >> that the private network indication identifies the particular private >> network, what form does this indication take when traffic is between two >> enterprises? Is there some interworking function where the identifier >> changes from that of the first private network to that of the second >> private network? >> >> > >> > >> > 8. calling line identification >> > Yes we agree fully on that "calling line identification is >> > not an adequate distinction". I think that is what the >> > current text tries to explain. Actually what I dont like >> > about this text is that it starts explaining what the >> > indication is not about. I propose that we completely remove >> > the 1st paragraph in section 1.3 and the 1st word "Rather" >> > from the 2nd paragraph. >> [JRE] Yes. And in the second paragraph, perhaps we could enhance: >> "This >> indication is not for the end user on the private network." >> to say: >> "This indication does not identify an end user on a private network and >> is not for delivery to an end user on the private network." >> >> >> John >> >> >> > >> > /Hans Erik van Elburg >> > >> > >> > >> > >> > > --0015174be6d20b4185046e078c0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The updates after expert review of the draft-vanelbur= g-sipping-private-network-indication-03 has been submitted to dispatch as:<= /span>

or plain text:

Best Regards,
/Hans Erik van Elburg


---------- Forwarded message ----------<= br>From: Hans Erik van Elburg <ietf.hanserik@gmail= .com>
Date: Mon, Jul 6, 2009 at 1:06 PM
Subject: Re: [Sipping] Fwd: Expert rev= iew ofdraft-vanelburg-sipping-private-network-indication-03
To: "El= well, John" <= john.elwell@siemens-enterprise.com>
Cc: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, IETF Sipping List <sipping@ietf.org>



Best Regards,
/Hans Erik van Elburg


On Mon, Jul 6, 2009 at 11:42 AM, Hans Erik v= an Elburg <ietf.hanserik@gmail.com> wrote:
Hi John,

1. Done, moved 10 up and inserted as= 1.2. Added the following sentence to 1.1:
"3GPP and ETSI TISPAN = have identified a set of=A0requirements that can be met by defining a new S= IP P-header, according to the procedures in RFC 3427 [RFC3427]."
2. Done
4a. Done
4b. Done
4c. Done
=
5. I added the following terminology description:
"3.1. Traffic

In the context of this document the term traffic = is understood as all
communication pertaining to and/or controlled by a = SIP transaction or
dialog."
8. Done

Will upload this as cutoff day for 00 drafts is today.<= /div>

/Hans Erik van Elburg



On Mon, Jul 6, 2009 at 8:52 AM, Elwell, = John <john.elwell@siemens-enterprise.com> w= rote:
Hans Erik,

> -----Original Message-----
> From: si= pping-bounces@ietf.org
> [mailto:= sipping-bounces@ietf.org] On Behalf Of Hans Erik van Elburg
> Sent: 03 July 2009 15:17
> To: Elwell, John; DRAGE, Keith (Keith)
> Cc: IETF Sipping List
> Subject: [Sipping] Fwd: Expert review
> ofdraft-vanelburg-sipping-private-network-indication-03
>
> Resent and history removed as otherwise rejected by mailing list.
>
> Hi John,
>
> 1. Again the required applicability statement is in section
> 10 of the main body. (Same pattern has been followed in
> RFC5502, 5002 and 4457) which I took as examples. Together
> with the additional text in the abstract that should be
> sufficient. If the text in section 10 needs to be improved
> then please indicate so.
[JRE] I must have written the original comment 1 before I got down to=
section 10. Basically section 10 is far too late in the document, and I
would have expected the statement, perhaps as section 1, or perhaps as a section 1.2 before the existing 1.2.


>
> 2. Took in your nits, the abstract now reads:
> =A0 =A0 =A0 "This document specifies the SIP P-Private-Network-In= dication
> P-header. The use of this private network indication extension
> is only applicable inside an administrative domain with
> previously agreed-upon policies for generation, transport and
> usage of such information. =A0A private network indication
> allows nodes in such a domain to treat private network traffic
> according to a different set of rules then than the set
> applicable to public network traffic. The indication also
> distinguishes traffic from one private network from another
> private network."
[JRE]
Delete the word "then".

>
> 4a. Regarding 1.2 item b). Would the following rewrite help?:
> OLD:
> " b) business trunking application, where the NGN hosts
> transit capabilities between NGCN's, break-in capabilities
> from NGN to NGCN and break-out capabilities from NGCN to NGN; and"= ;
> /OLD
>
>
> NEW:
> " b) business trunking application, where the NGN hosts
> transit capabilities between NGCN's, break-in capabilities
> where the NGN converts public network traffic to private
> network traffic for delivery at a served NGCN and break-out
> capabilities where the NGN converts private network traffic
> from a served NGCN to public network traffic; and"
>
> /NEW
>
> If not please suggest an improved sentence that covers your
> concern. Please note that in the example that you gave it is
> not the business trunking application that does the
> conversion, but the hosted enterprise application.
[JRE] That would do.


>
> 4b. "normal rules"
> Looking at the definition, would the following rewrite help:
> OLD
> " Traffic sent to or received from a public telecommunication
> network for processing according to the normal rules."
> /OLD
>
> NEW
> " Traffic sent to or received from a public telecommunication
> network for processing according to the rules for ordinary
> subscribers of a public telecommunication network."
> /NEW
[JRE] That would do.

>
> 4c. NGN is a public telecommunication network
> > =A0 =A0 =A0 - "To summarize a few example reasons for a publ= ic
> telecommunication network to make the distinction between the
> two types of traffic" Isn't it an NGN that needs to make the<= br> > distinction?
> > [HE] NGN is a public telecommunication network. But we can
> rephrase to: "To summarize a few example reasons for a public
> NGN to make the distinction between the two types of traffic" [/H= E]
[JRE] OK

>
> [JRE] I think that is the problem I am having. I believe an
> NGN is a network infrastructure that supports both public
> network traffic and private network traffic, or in other
> words it supports both a public network and a number of
> private networks.[/JRE]
> [HE2]Yes, but its main purpose is to serve as a public
> network with all the regulations that apply to such networks
> etc. This does not prohibit an NGN to be used as a private
> network of course, but still it has been designed from the
> perspective of having to serve the needs of public network
> operators. That is why the "normal"/default =A0procedures ar= e
> for public network traffic. As we want to introduce the
> capability for such a public network (NGN) to also support
> private network traffic that has to be processed to a
> different set of rules, the Private-Network-Indication is
> needed.[/HE2]
>
>
> 5. Traffic --> SIP traffic
> Calling traffic SIP traffic suggest that the media is not
> part of the traffic, is that what we want??
[JRE] The point is, it is not HTTP traffic or FTP traffic or SMTP
traffic or whatever.

>
>
> 6. Example private network traffic can also exist between two
> different enterprises
> Where would you like to see this? Obviously section 1.2 is
> not the right place for such an example.
> Isn't this too obvious, if you imagine that two companies
> have agreed to form a cooperation and communicate under this
> agreement?
> Would you like to see this as an additional example in section 4?
[JRE] I was not necessarily seeking a further example. However, given=
that the private network indication identifies the particular private
network, what form does this indication take when traffic is between two enterprises? Is there some interworking function where the identifier
changes from that of the first private network to that of the second
private network?

>
>
> 8. calling line identification
> Yes we agree fully on that "calling line identification is
> not an adequate distinction". I think that is what the
> current text tries to explain. Actually what I dont like
> about this text is that it starts explaining what the
> indication is not about. I propose that we completely remove
> the 1st paragraph in section 1.3 and the 1st word "Rather" > from the 2nd paragraph.
[JRE] Yes. And in the second paragraph, perhaps we could enhance:
"This
=A0 indication is not for the end user on the private network."
to say:
"This indication does not identify an end user on a private network an= d
is not for delivery to an end user on the private network."


John


>
> /Hans Erik van Elburg
>
>
>
>



--0015174be6d20b4185046e078c0c-- From R.Jesske@telekom.de Mon Jul 6 04:51:38 2009 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 1795128C27F; Mon, 6 Jul 2009 04:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_20=-0.74, HELO_EQ_DE=0.35, 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 K4NhHMfP4bh6; Mon, 6 Jul 2009 04:51:37 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 0BA133A6B8F; Mon, 6 Jul 2009 04:51:35 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 06 Jul 2009 13:50:24 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 13:50:24 +0200 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_01C9FE2F.F24C163E" Date: Mon, 6 Jul 2009 13:50:23 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acn7EgmFHY5NLHSnTdacRdukHKWXGADHHJng From: To: , X-OriginalArrivalTime: 06 Jul 2009 11:50:24.0217 (UTC) FILETIME=[F2801C90:01C9FE2F] Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 06 Jul 2009 11:51:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE2F.F24C163E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, After getting no response to my question from the dispatch. I assume = that there is no interest on this draft within dispatch. So now I would like to ask the people from SIPCORE and BILSS where do = they see the work. The below mentioned draft describes the use of the Reason Header within = Resoponses for interoperability with the existing PSTN/ISDN networks. Best Regards Roland > _____________________________________________=20 > Von: Jesske, Roland =20 > Gesendet: Donnerstag, 2. Juli 2009 14:39 > An: dispatch@ietf.org > Betreff: draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Dear all, > At the moment I'm preparing a new version of = draft-jesske-sipping-etsi-ngn-reason-04 ( = http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-reason-04 ) to = be submitted. > There were some comments which were stating that this is the wrong = group for the draft. > I would like to know what the feeling of the group is to which group = (BLISS, DISPATCH or SIPCORE) this draft should belong. >=20 > Thank you and Best Regards >=20 > Roland >=20 > Deutsche Telekom Netzproduktion GmbH=20 > Zentrum Technik Einf=FChrung=20 > Roland Jesske=20 > Gateways, Protokolle, Konvergenz, TE32-1 > Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=20 > Postfach, 64307 Darmstadt (Postanschrift)=20 > +496151 628 2766 (Tel) > +491718618445 (Mobile)=20 > E-Mail: r.jesske@telekom.de=20 > http://www.telekom.de =20 >=20 >=20 >=20 > Registerrechtliche Unternehmensangaben:=20 > Deutsche Telekom Netzproduktion GmbH=20 > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 > Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 > Handelsregister: Amtsgericht Bonn HRB 14190=20 > Sitz der Gesellschaft: Bonn=20 > USt-IdNr.: DE 814645262 >=20 >=20 ------_=_NextPart_001_01C9FE2F.F24C163E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: draft-jesske-sipping-etsi-ngn-reason-04

Dear all,
After getting no = response to my question from the dispatch. I assume that there is no = interest on this draft within dispatch.

So now I would like = to ask the people from SIPCORE and BILSS where do they see the = work.

The below mentioned = draft describes the use of the Reason Header within Resoponses for = interoperability with the existing PSTN/ISDN networks.

Best Regards

Roland

_____________________________________________
Von:    Jesske, Roland 
Gesendet:       = Donnerstag, 2. Juli 2009 14:39
An:     dispatch@ietf.org
Betreff:       = draft-jesske-sipping-etsi-ngn-reason-04

Dear all,
At the moment I'm preparing a new = version of draft-jesske-sipping-etsi-ngn-reason-04 ( http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-r= eason-04 ) to be = submitted.

There were some comments which were = stating that this is the wrong group for the draft.
I would like to know what the feeling = of the group is to which group (BLISS, DISPATCH or SIPCORE) this draft = should belong.

Thank you and Best Regards

Roland

Deutsche Telekom = Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Gateways, Protokolle, Konvergenz, = TE32-1
Heinrich-Hertz-Str. 3-7, 64295 = Darmstadt,
Postfach, 64307 Darmstadt = (Postanschrift)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de=20



Registerrechtliche = Unternehmensangaben:=20
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262


------_=_NextPart_001_01C9FE2F.F24C163E-- From gonzalo.camarillo@ericsson.com Mon Jul 6 06:57:49 2009 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 4E76F3A6AB0 for ; Mon, 6 Jul 2009 06:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 iWYnAmcFGaUR for ; Mon, 6 Jul 2009 06:57:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 18B793A67DF for ; Mon, 6 Jul 2009 06:57:47 -0700 (PDT) X-AuditID: c1b4fb3e-b7b3cae000002c88-f8-4a5202a321c1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C1.B4.11400.3A2025A4; Mon, 6 Jul 2009 15:56:51 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 15:56:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 15:56:49 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DCBA523F6 for ; Mon, 6 Jul 2009 16:56:49 +0300 (EEST) Message-ID: <4A5202A1.6090501@ericsson.com> Date: Mon, 06 Jul 2009 16:56:49 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2009 13:56:50.0082 (UTC) FILETIME=[9C074020:01C9FE41] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Preconditions and intermediaries 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, 06 Jul 2009 13:57:49 -0000 Folks, [as individual] the following draft was presented in SIPPING in the the last IETF meeting. http://tools.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt This draft was a spin off from the "rollback" discussions that led to the following draft. It was a separate issue we decided to document in a separate draft. http://www.ietf.org/internet-drafts/draft-camarillo-sipcore-reinvite-00.txt Now, I would like to ask comments on the preconditions draft. If this is something people are interested in? Cheers, Gonzalo From dworley@nortel.com Mon Jul 6 08:37:39 2009 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 E794A3A6D0F for ; Mon, 6 Jul 2009 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 UrhCScSWhvfz for ; Mon, 6 Jul 2009 08:37:37 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2FC293A6A15 for ; Mon, 6 Jul 2009 08:37:37 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n66Fare08385; Mon, 6 Jul 2009 15:36:53 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 11:36:52 -0400 From: "Dale Worley" To: R.Jesske@telekom.de In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 06 Jul 2009 11:36:52 -0400 Message-Id: <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2009 15:36:52.0995 (UTC) FILETIME=[960B1530:01C9FE4F] Cc: DISPATCH Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 06 Jul 2009 15:37:39 -0000 On Mon, 2009-07-06 at 13:50 +0200, R.Jesske@telekom.de wrote: > Dear all, > After getting no response to my question from the dispatch. I assume > that there is no interest on this draft within dispatch. > > So now I would like to ask the people from SIPCORE and BILSS where do > they see the work. > > The below mentioned draft describes the use of the Reason Header > within Resoponses for interoperability with the existing PSTN/ISDN > networks. Is the Abstract right? As far as I can tell (by reading section 2), the Abstract doesn't describe the draft at all. That might be a reason that you haven't gotten any response -- the Abstract "proposes the use of the Reason header field in SIP responses", but that is something that is already defined and allowed. Dale From salvatore.loreto@ericsson.com Mon Jul 6 09:33:33 2009 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 1E44428C389 for ; Mon, 6 Jul 2009 09:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 zxYWUnUxKGX6 for ; Mon, 6 Jul 2009 09:33:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EA64E3A6CF8 for ; Mon, 6 Jul 2009 09:33:31 -0700 (PDT) X-AuditID: c1b4fb3e-b7b3cae000002c88-81-4a5227547b97 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 13.01.11400.457225A4; Mon, 6 Jul 2009 18:33:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 18:33:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 18:33:24 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 21FE02450 for ; Mon, 6 Jul 2009 19:33:22 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D90C921A07 for ; Mon, 6 Jul 2009 19:33:21 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9298021925 for ; Mon, 6 Jul 2009 19:33:21 +0300 (EEST) Message-ID: <4A522751.9010607@ericsson.com> Date: Mon, 06 Jul 2009 19:33:21 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 06 Jul 2009 16:33:24.0172 (UTC) FILETIME=[7B57A0C0:01C9FE57] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Disaggregated Media in SIP 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, 06 Jul 2009 16:33:33 -0000 Hi there, I have just submitted a draft that talks of Disaggregated Media in the Session Initiation Protocol (SIP). http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disaggregated-media-00.txt Abstract: Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. This document lists several use cases that involve disaggregated media in SIP. Additionally, this document analyzes what types of disaggregated media can be implemented using existing protocol mechanisms, and the pros and cons of using each of those mechanisms. Finally, this document describes scenarios that are not covered by current mechanisms and proposes new IETF work to cover them. cheers Sal From AUDET@nortel.com Mon Jul 6 10:09:37 2009 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 A2FA93A6D4F for ; Mon, 6 Jul 2009 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 vD0i-e0C1YiS for ; Mon, 6 Jul 2009 10:09:36 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 902F23A6D44 for ; Mon, 6 Jul 2009 10:09:36 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n66H6Lq09946; Mon, 6 Jul 2009 17:06:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jul 2009 12:07:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED2B34C@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A522751.9010607@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn+V/URN2j1d4ydQVa7T4blAaq1dQAATnGA References: <4A522751.9010607@ericsson.com> From: "Francois Audet" To: "Salvatore Loreto" , Subject: Re: [dispatch] Disaggregated Media in SIP 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, 06 Jul 2009 17:09:37 -0000 I'm glad to see this topic coming back. I see that this draft doesn't propose a solution to problem: it list three options, and describes why they are not adequate. I agree with the conclusions. We've looked at various approaches to solve this important problem=20 several times before:=20 - Feature ref (refer to urn: indicating specific features) http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 - Remote control using REFER to requests & responses=20 http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 (Also, versions -04, -03,-02, -00) - Remore control using REFER with XML body describing function http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 - Remote control using MBUS http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 On top of that there are various proprietary mechanisms, and even some = legacy PBX-CTI protocols. > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: Monday, July 06, 2009 09:33 > To: dispatch@ietf.org > Subject: [dispatch] Disaggregated Media in SIP >=20 > Hi there, >=20 > I have just submitted a draft that talks of Disaggregated=20 > Media in the Session Initiation Protocol (SIP). > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa ggregated-media-00.txt >=20 >=20 > Abstract: > Disaggregated media refers to the ability for a user to create a=20 > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are=20 > treated by=20 > the far end of the session as a single media session. > This document lists several use cases that involve=20 > disaggregated media=20 > in SIP. > Additionally, this document analyzes what types of=20 > disaggregated media=20 > can be implemented using existing protocol > mechanisms, and the pros and cons of using each of those mechanisms. > Finally, this document describes scenarios that are not covered by=20 > current mechanisms > and proposes new IETF work to cover them. >=20 >=20 > cheers > Sal > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From nadia.bishai@ericsson.com Mon Jul 6 10:18:34 2009 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 68A323A6D35 for ; Mon, 6 Jul 2009 10:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.597 X-Spam-Level: X-Spam-Status: No, score=-8.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_FONT_SIZE_LARGE=0.001, 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 X6mNsbyORuxO for ; Mon, 6 Jul 2009 10:18:33 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 74A6F3A67DF for ; Mon, 6 Jul 2009 10:18:33 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n66HHm18025884 for ; Mon, 6 Jul 2009 12:17:49 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 12:17:38 -0500 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_01C9FE5D.A9159EA3" Date: Mon, 6 Jul 2009 13:17:37 -0400 Message-ID: <95D8C1105D54EB41864F8831E6C4EB7506DB5CCE@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-loreto-sipping-3892bis Thread-Index: Acn+XajlddoWYZPIRJ2dmRaOB+5IXw== From: "Nadia Bishai" To: X-OriginalArrivalTime: 06 Jul 2009 17:17:38.0361 (UTC) FILETIME=[A95CBA90:01C9FE5D] Subject: [dispatch] draft-loreto-sipping-3892bis 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, 06 Jul 2009 17:18:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE5D.A9159EA3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, During the presentation of draft-loreto-sipping-3892bis-01.txt at IETF = 74 in SF, we got a question from Cullen related to the importance for a receiver = to get all the identities expressions and what it does with multiple = identity expressions. The reason why multiple identity experssions are needed by the receiver = is that some receivers can only handle one format of identity expression = (e.g. TEL URI) and not other formats (e.g., SIP URI). =20 Some examples:=20 -in a Conference call, when an incoming session invitation carries the = Referred-By header, the TEL URI is needed to find the corresponding = contact information in the user's address book when the address book = only stores telephone numbers. - When a MESSAGE message is sent to a group where one recipient is an = SMS user, the MESSAGE is intercepted by an interworking function that = translates the MESSAGE into an SMS message. The SMS system can only = handle a MSISDN identifier. The interworking function will use the TEL = URI received in the Referred-By header to derive an MSISDN value to be = sent in SMS signalling. Nadia Bishai=20 E =20 E-Mail: Nadia.Bishai@ericsson.com=20 Tel: (+1) 514-345-7900 (X 42234) 8400 Decarie Boulevard=20 Cell: (+1) 514-591-6739 Montreal, Quebec, = Canada www.ericsson.com H4P-2N2=20 ECN 8105 2234=20 ------_=_NextPart_001_01C9FE5D.A9159EA3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-loreto-sipping-3892bis

Hi,

During the presentation of = draft-loreto-sipping-3892bis-01.txt at IETF 74 in SF,
we got a question from Cullen = related to the importance for a receiver to get all the identities = expressions and what it does with multiple identity = expressions.

The reason why multiple identity = experssions are needed by the receiver is that some receivers can only = handle one format of identity expression (e.g. TEL URI) and not other = formats (e.g., SIP URI). 

Some examples:
-in a Conference call, when an = incoming session invitation carries the Referred-By header, the TEL URI = is needed to find the corresponding contact information in the user's = address book when the address book only stores telephone = numbers.

- When a MESSAGE message is sent = to a group where one recipient is an SMS user, the MESSAGE is = intercepted by an interworking function that translates the MESSAGE into = an SMS message. The SMS system can only handle a MSISDN identifier. The = interworking function will use the TEL URI received in the Referred-By = header to derive an MSISDN value to be sent in SMS = signalling.


Nadia Bishai
E = =A0=A0=A0=A0=A0
E-Mail: = Nadia.Bishai@ericsson.com
Tel:=A0 (+1) 514-345-7900=A0=A0 = (X 42234)=A0=A0=A0=A0=A0=A0=A0=A0 8400 Decarie = Boulevard
Cell: (+1) = 514-591-6739=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Montreal, Quebec, Canada
=A0www.ericsson.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = H4P-2N2
ECN 8105 2234


------_=_NextPart_001_01C9FE5D.A9159EA3-- From AUDET@nortel.com Mon Jul 6 10:40:02 2009 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 B683228C191 for ; Mon, 6 Jul 2009 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 IGc2sTX9On9T for ; Mon, 6 Jul 2009 10:40:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E686F28C317 for ; Mon, 6 Jul 2009 10:39:53 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n66HZHe12738; Mon, 6 Jul 2009 17:35:17 GMT 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_01C9FE60.20324DE8" Date: Mon, 6 Jul 2009 12:35:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91040@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn+V/URN2j1d4ydQVa7T4blAaq1dQAATnGAAAGDwYsAACop8A== References: <1ECE0EB50388174790F9694F77522CCF1ED2B34C@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Henry Sinnreich" , "Salvatore Loreto" , Subject: Re: [dispatch] Disaggregated Media in SIP 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, 06 Jul 2009 17:40:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE60.20324DE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sure. =20 That would be functionaly identical to the Feature referal using REFER = to URL/URN, but using MESSAGE instead.=20 =20 Works for me. =20 =20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 06, 2009 10:29 To: Audet, Francois (SC100:3055); Salvatore Loreto; dispatch@ietf.org Cc: Henning Schulzrinne Subject: Re: [dispatch] Disaggregated Media in SIP =09 =09 >We've looked at various approaches to solve this important=20 >problem several times before =09 Actually there is one more: IM-ing a URI to some resource, mentioned by = Henning Schulzrinne (I don't recall the document or presentation). =09 My two cents is that IM-ing a URL is the most general solution, or is = it? =09 Henry =09 =09 On 7/6/09 12:07 PM, "Francois Audet" wrote: =09 =09 I'm glad to see this topic coming back. =09 I see that this draft doesn't propose a solution to problem: it list three options, and describes why they are not adequate. I agree with the conclusions. =09 We've looked at various approaches to solve this important problem several times before: =09 - Feature ref (refer to urn: indicating specific features) http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 =09 - Remote control using REFER to requests & responses http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 (Also, versions -04, -03,-02, -00) =09 - Remore control using REFER with XML body describing function http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 =09 - Remote control using MBUS http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 =09 On top of that there are various proprietary mechanisms, and even some = legacy PBX-CTI protocols. =09 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: Monday, July 06, 2009 09:33 > To: dispatch@ietf.org > Subject: [dispatch] Disaggregated Media in SIP > > Hi there, > > I have just submitted a draft that talks of Disaggregated > Media in the Session Initiation Protocol (SIP). > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa ggregated-media-00.txt > > > Abstract: > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are > treated by > the far end of the session as a single media session. > This document lists several use cases that involve > disaggregated media > in SIP. > Additionally, this document analyzes what types of > disaggregated media > can be implemented using existing protocol > mechanisms, and the pros and cons of using each of those mechanisms. > Finally, this document describes scenarios that are not covered by > current mechanisms > and proposes new IETF work to cover them. > > > cheers > Sal > _______________________________________________ > 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 =09 ------_=_NextPart_001_01C9FE60.20324DE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP
Sure.
 
That=20 would be functionaly identical to the Feature referal using REFER to = URL/URN,=20 but using MESSAGE instead.
 
Works=20 for me.
 
 

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Monday, July 06, 2009=20 10:29
To: Audet, Francois (SC100:3055); Salvatore Loreto;=20 dispatch@ietf.org
Cc: Henning Schulzrinne
Subject: = Re:=20 [dispatch] Disaggregated Media in SIP

>We've looked at various approaches to = solve this=20 important
>problem several times before

Actually there = is one=20 more: IM-ing a URI to some resource, mentioned by Henning Schulzrinne = (I don=92t=20 recall the document or presentation).

My two cents is that = IM-ing a URL=20 is the most general solution, or is it?

Henry


On = 7/6/09=20 12:07 PM, "Francois Audet" <audet@nortel.com> = wrote:
I'm glad to see this topic coming = back.

I see=20 that this draft doesn't propose a solution to problem: it = list
three=20 options, and describes why they are not adequate. I agree = with
the=20 conclusions.

We've looked at various approaches to solve this = important problem
several times before:

- Feature ref = (refer to=20 urn: indicating specific features)
  ht= tp://tools.ietf.org/html/draft-audet-sipping-feature-ref-00

- = Remote control using REFER to requests & = responses
  http://to= ols.ietf.org/html/draft-mahy-sip-remote-cc-05
  (Also,=20 versions -04, -03,-02, -00)

- Remore control using REFER with = XML=20 body describing function
  http://to= ols.ietf.org/html/draft-mahy-sip-remote-cc-01

-=20 Remote control using MBUS
  ht= tp://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01=20 &
  http://= tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01

On=20 top of that there are various proprietary mechanisms, and even some=20 legacy
PBX-CTI protocols.

> -----Original = Message-----
>=20 From: dispatch-bounces@ietf.org
> = [mailto:dispatch-bounces@ietf.or= g]=20 On Behalf Of Salvatore Loreto
> Sent: Monday, July 06, 2009=20 09:33
> To: dispatch@ietf.org
>=20 Subject: [dispatch] Disaggregated Media in SIP
>
> Hi=20 there,
>
> I have just submitted a draft that talks of=20 Disaggregated
> Media in the Session Initiation Protocol=20 (SIP).
> h= ttp://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa
ggre= gated-media-00.txt
>
>
>=20 Abstract:
> Disaggregated media refers to the ability for a = user to=20 create a
> multimedia session combining different media = streams,=20 coming from
> different devices under his or her control, so = that they=20 are
> treated by
> the far end of the session as a = single media=20 session.
> This document lists several use cases that = involve
>=20 disaggregated media
> in SIP.
> Additionally, this = document=20 analyzes what types of
> disaggregated media
> can be=20 implemented using existing protocol
> mechanisms, and the pros = and=20 cons of using each of those mechanisms.
> Finally, this = document=20 describes scenarios that are not covered by
> current=20 mechanisms
> and proposes new IETF work to cover=20 them.
>
>
> cheers
> Sal
>=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_01C9FE60.20324DE8-- From pkyzivat@cisco.com Mon Jul 6 11:24:34 2009 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 197793A6D54 for ; Mon, 6 Jul 2009 11:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.558 X-Spam-Level: X-Spam-Status: No, score=-7.558 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 B61Do9tyyyrM for ; Mon, 6 Jul 2009 11:24:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C96E83A6B46 for ; Mon, 6 Jul 2009 11:24:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,357,1243814400"; d="scan'208";a="210037107" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2009 18:23:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n66INCwF025551; Mon, 6 Jul 2009 14:23:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n66INCTB004974; Mon, 6 Jul 2009 18:23:12 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 14:23:12 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 14:23:11 -0400 Message-ID: <4A52410F.1020809@cisco.com> Date: Mon, 06 Jul 2009 14:23:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Salvatore Loreto References: <4A522751.9010607@ericsson.com> In-Reply-To: <4A522751.9010607@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2009 18:23:11.0921 (UTC) FILETIME=[D1F25A10:01C9FE66] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7632; t=1246904592; x=1247768592; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Salvatore=20Loreto=20; bh=8LeV4l8BI6DZCAqZEyR7ce+XkehtRV0msguGV9zbnnE=; b=xea4WpHjkcNYDqdDZR6mjNjrpcCAA7KGQnmZlmGnqHmnH5LpolU2ngPHQs popYiF/CSWRA3uhbP0qKgcZDXs8E3JlEx6Uvk8UVmMNVGxjW/8ylOdTqhMkk qtpkhu4qSm; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 06 Jul 2009 18:24:34 -0000 Sal, Glad to see more focus on the objectives rather than the solutions. A few comments: > 2.6. Answering a call using Two Separate Devices > > Laura has a PC with a softclient and a desk phone. Bob has an > integrated advanced multimedia phone with camera. > > Laura receives on her desk phone an incoming voice-video call from > Bob. > > Laura decides to answer the Bob's session invitation by establishing > a voice session with Bob using the desk phone and the video session > using her multimedia phone. OK > Two SIP dialogs need to be established: > one between Bob's device and Laura's desk phone and one between Bob's > device and Laura's multimedia phone. The above statement assumes the outcome that this draft is trying to make a case for. > ---- ---- > | UA |\ /| UA | > ---- \ / ---- > \ / > ---- \---- ----/ ---- > | UA |-----| UA |-------------| UA |---| UA | > ---- /---- SIP ----\ ---- > / \ > ---- / \ ---- > | UA |/ \| UA | > ---- ---- > Alice Bob > > > Figure 2: Centralized scenario > > Figure 2 shows the generic signaling flow common to all centralized > solutions, where a Central Node is able to manage all signaling > messages needed to coordinate the different user's devices and hide > from the far end of the session all the mechanisms used to distribute > the media among different devices. That is but one of many topologies. Others include: - Alice has a multimedia device that supports all the media - Alice has a device that supports *some* of the media and is also the controller for the other devices. - Either of the above for Bob - all permutations of approaches for Alice and Bob The key is that there is a single sip session between caller and callee, which negotiates potentially many media sessions. The caller and callee may then each use whatever technique(s) desired to establish connection of the individual media sessions to particular devices. That may involve other sip signaling for some or all of the media, or not. > 3.3.1. 3pcc issues These are indeed issues to some extent. But its debatable whether they are significant issues, or how hard it is to mitigate them. To be fair we will have to look at issues for alternative solutions and balance them. > 4. Scenarios Not Covered by Existing Mechanisms > > As discussed previously, all existing mechanisms implement > disaggregated media using a centralized approach. Scenarios not > covered by existing mechanisms include those where none of the nodes > can act as a controller because it does not support the necessary > functionality Well, its clear that some devices will need to support some new functionality to aggregate the disaggregated media. Actually it seems that something new will need to be implemented at each end. So we are really only discussing *which* new functionality should be implemented at each end. > or because it will not participate in the whole session > (transferring the SIP dialog from a controller to a new one using > REFER and Replaces is complex and requires support from the far end). > These scenarios are better implemented using a more distributed > approach. If it would be possible to do a transfer at all, it should be possible to do a transfer involving this disaggregated media controller. > /------------\ > | ---- ____|________________ > | | UA | | \ > | ---- | \ ------ > | ---- | | | > | | UA |-------------------------| UA | > | ---- | | | > | ---- | / ------ > | | UA |____|________________/ Bob > | ---- | > \------------/ > Alice > > Figure 5 shows the generic signaling flow in a Distributed Scenario, > where all the signaling messages go from the different user's devices > to the far end of the session. That shows some of the signaling paths. What it doesn't show is what is required to organize Alice's devices and decide which should be involved in the call, for which media. That is an important piece, unless it handled entirely by Bob. Every one of the use cases will require some special processing and control signaling among the disaggregated devices before a call topology such as shown in figure 5 can be established. Also, its far from clear what order of signaling would be required, and in which direction, to use the approach of figure 5 for each use case. Its quite possible that one call might be established from Bob to Alice and a supporting call from Alice to Bob. This would confuse responsibility for charging. Another problem with figure 5 arises if it becomes necessary to transfer the resulting call, say from Bob to Charlie. There are then three calls that need to be transferred. Getting all that to happen smoothly will be a great challenge. Its hard enough if Charlie, like Bob, can handle all the media on a single device. If Charlie needs to aggregate some devices to handle all the media coming from Alice, then the problem becomes exceedingly complex. Hence, IMO it remains far from clear that the new mechanism actually offers any benefits over the 3pcc mechanism. If you think it does (apparently you do) then I think it becomes necessary to compare the two in more detail. I think that requires nailing down in more detail how the important use cases should behave to an end user, and then how that behavior might be achieved using each technique. And then identifying gaps that need to be filled in each in order to have sufficient capability to achieve an equivalent and satisfactory result. I think this analysis must also ensure that the resulting calls can work with other common features such as transfers, conferencing, "voice"mail, etc. Thanks, Paul Salvatore Loreto wrote: > Hi there, > > I have just submitted a draft that talks of Disaggregated Media in the > Session Initiation Protocol (SIP). > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disaggregated-media-00.txt > > > > Abstract: > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are treated by > the far end of the session as a single media session. > This document lists several use cases that involve disaggregated media > in SIP. > Additionally, this document analyzes what types of disaggregated media > can be implemented using existing protocol > mechanisms, and the pros and cons of using each of those mechanisms. > Finally, this document describes scenarios that are not covered by > current mechanisms > and proposes new IETF work to cover them. > > > cheers > Sal > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From hsinnrei@adobe.com Mon Jul 6 13:32:11 2009 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 D96063A6A5D for ; Mon, 6 Jul 2009 13:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.612, 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 3EWBH3yr3RD4 for ; Mon, 6 Jul 2009 13:32:06 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id A410E3A68A2 for ; Mon, 6 Jul 2009 13:32:05 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKSlJermrAkqylQJKHlifdRcJb59OXo5CW@postini.com; Mon, 06 Jul 2009 13:32:31 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n66HOdao017377; Mon, 6 Jul 2009 10:24:40 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n66HSmit026450; Mon, 6 Jul 2009 10:28:59 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 6 Jul 2009 10:28:59 -0700 From: Henry Sinnreich To: Francois Audet , Salvatore Loreto , "dispatch@ietf.org" Date: Mon, 6 Jul 2009 10:28:57 -0700 Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: Acn+V/URN2j1d4ydQVa7T4blAaq1dQAATnGAAAGDwYs= Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1ED2B34C@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6779E89487Ehsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [dispatch] Disaggregated Media in SIP 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, 06 Jul 2009 20:32:11 -0000 --_000_C6779E89487Ehsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >We've looked at various approaches to solve this important >problem several times before Actually there is one more: IM-ing a URI to some resource, mentioned by Hen= ning Schulzrinne (I don't recall the document or presentation). My two cents is that IM-ing a URL is the most general solution, or is it? Henry On 7/6/09 12:07 PM, "Francois Audet" wrote: I'm glad to see this topic coming back. I see that this draft doesn't propose a solution to problem: it list three options, and describes why they are not adequate. I agree with the conclusions. We've looked at various approaches to solve this important problem several times before: - Feature ref (refer to urn: indicating specific features) http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 - Remote control using REFER to requests & responses http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 (Also, versions -04, -03,-02, -00) - Remore control using REFER with XML body describing function http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 - Remote control using MBUS http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 On top of that there are various proprietary mechanisms, and even some lega= cy PBX-CTI protocols. > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: Monday, July 06, 2009 09:33 > To: dispatch@ietf.org > Subject: [dispatch] Disaggregated Media in SIP > > Hi there, > > I have just submitted a draft that talks of Disaggregated > Media in the Session Initiation Protocol (SIP). > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa ggregated-media-00.txt > > > Abstract: > Disaggregated media refers to the ability for a user to create a > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are > treated by > the far end of the session as a single media session. > This document lists several use cases that involve > disaggregated media > in SIP. > Additionally, this document analyzes what types of > disaggregated media > can be implemented using existing protocol > mechanisms, and the pros and cons of using each of those mechanisms. > Finally, this document describes scenarios that are not covered by > current mechanisms > and proposes new IETF work to cover them. > > > cheers > Sal > _______________________________________________ > 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 --_000_C6779E89487Ehsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP >We've looked at various approaches to solve this important
>problem several times before

Actually there is one more: IM-ing a URI to some resource, mentioned by Hen= ning Schulzrinne (I don’t recall the document or presentation).

My two cents is that IM-ing a URL is the most general solution, or is it?
Henry


On 7/6/09 12:07 PM, "Francois Audet" <audet@nortel.com> wrote:

I'm glad to see this topic coming back.

I see that this draft doesn't propose a solution to problem: it list
three options, and describes why they are not adequate. I agree with
the conclusions.

We've looked at various approaches to solve this important problem
several times before:

- Feature ref (refer to urn: indicating specific features)
  http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00

- Remote control using REFER to requests & responses
  http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05
  (Also, versions -04, -03,-02, -00)

- Remore control using REFER with XML body describing function
  http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01

- Remote control using MBUS
  http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 &
  http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01

On top of that there are various proprietary mechanisms, and even some lega= cy
PBX-CTI protocols.

> -----Original Message-----
> From: dispatch-bounces@ietf.org<= /a>
> [mailto:dispatch-bounces@= ietf.org] On Behalf Of Salvatore Loreto
> Sent: Monday, July 06, 2009 09:33
> To: dispatch@ietf.org
> Subject: [dispatch] Disaggregated Media in SIP
>
> Hi there,
>
> I have just submitted a draft that talks of Disaggregated
> Media in the Session Initiation Protocol (SIP).
> http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa
ggregated-media-00.txt
>
>
> Abstract:
> Disaggregated media refers to the ability for a user to create a
> multimedia session combining different media streams, coming from
> different devices under his or her control, so that they are
> treated by
> the far end of the session as a single media session.
> This document lists several use cases that involve
> disaggregated media
> in SIP.
> Additionally, this document analyzes what types of
> disaggregated media
> can be implemented using existing protocol
> mechanisms, and the pros and cons of using each of those mechanisms. > Finally, this document describes scenarios that are not covered by
> current mechanisms
> and proposes new IETF work to cover them.
>
>
> cheers
> Sal
> _______________________________________________
> 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

--_000_C6779E89487Ehsinnreiadobecom_-- From pkyzivat@cisco.com Mon Jul 6 13:45:01 2009 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 C39603A68A2 for ; Mon, 6 Jul 2009 13:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 8+ZxvWJC2haT for ; Mon, 6 Jul 2009 13:45:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9E9273A67FF for ; Mon, 6 Jul 2009 13:45:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,358,1243814400"; d="scan'208";a="49507487" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2009 20:43:16 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n66KhGM3007368; Mon, 6 Jul 2009 16:43:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n66KhG5r010487; Mon, 6 Jul 2009 20:43:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 16:43:16 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 16:43:16 -0400 Message-ID: <4A5261E2.4050506@cisco.com> Date: Mon, 06 Jul 2009 16:43:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jul 2009 20:43:16.0145 (UTC) FILETIME=[63412A10:01C9FE7A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4055; t=1246912996; x=1247776996; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Henry=20Sinnreich=20; bh=9PpPVCF+aSWY5wtByYojorGzBHFlcM+9iLcn+NO+nuw=; b=qhPVGx6MIW3ZBLEJZXQShmhSp1XQX2k3xNrvBg28rJ3uN+aMF75vhI/V3w 4NuyNjGpHXutvLrnKRkkAOhkq9Lj62TehY0o12aB4I/KtyoGGa6TbhEiP0v/ 7QMgWo2z4a; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 06 Jul 2009 20:45:01 -0000 Henry Sinnreich wrote: >>We've looked at various approaches to solve this important >>problem several times before > > Actually there is one more: IM-ing a URI to some resource, mentioned by > Henning Schulzrinne (I don’t recall the document or presentation). > > My two cents is that IM-ing a URL is the most general solution, or is it? Past suggestions by various people to send control signals (intended to be acted upon by automata rather than people) via IM have generally been rejected as inappropriate. (The exception so far has been file transfer, which has some control behavior and some expected human interaction.) Now if you just want to say "Bob, please make a video call to sip:alice_camera@alice.com in order to see me" then I guess IM is ok. But IMO its not otherwise good. Its just a hack. Thanks, Paul > Henry > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > I'm glad to see this topic coming back. > > I see that this draft doesn't propose a solution to problem: it list > three options, and describes why they are not adequate. I agree with > the conclusions. > > We've looked at various approaches to solve this important problem > several times before: > > - Feature ref (refer to urn: indicating specific features) > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > - Remote control using REFER to requests & responses > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > (Also, versions -04, -03,-02, -00) > > - Remore control using REFER with XML body describing function > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > - Remote control using MBUS > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > On top of that there are various proprietary mechanisms, and even > some legacy > PBX-CTI protocols. > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > > Sent: Monday, July 06, 2009 09:33 > > To: dispatch@ietf.org > > Subject: [dispatch] Disaggregated Media in SIP > > > > Hi there, > > > > I have just submitted a draft that talks of Disaggregated > > Media in the Session Initiation Protocol (SIP). > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > ggregated-media-00.txt > > > > > > Abstract: > > Disaggregated media refers to the ability for a user to create a > > multimedia session combining different media streams, coming from > > different devices under his or her control, so that they are > > treated by > > the far end of the session as a single media session. > > This document lists several use cases that involve > > disaggregated media > > in SIP. > > Additionally, this document analyzes what types of > > disaggregated media > > can be implemented using existing protocol > > mechanisms, and the pros and cons of using each of those mechanisms. > > Finally, this document describes scenarios that are not covered by > > current mechanisms > > and proposes new IETF work to cover them. > > > > > > cheers > > Sal > > _______________________________________________ > > 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 rajnish.jain@ipc.com Mon Jul 6 15:50:16 2009 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 EC4EB3A6DA8 for ; Mon, 6 Jul 2009 15:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 Ub5qVfA+Pw7G for ; Mon, 6 Jul 2009 15:50:15 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) by core3.amsl.com (Postfix) with ESMTP id 3AD443A6DD7 for ; Mon, 6 Jul 2009 15:48:53 -0700 (PDT) Received: from unknown [65.244.37.51] (EHLO p01c11o147.mxlogic.net) by p01c11o147.mxlogic.net (mxl_mta-6.2.0-4) with ESMTP id f6f725a4.2896378768.57141.00-522.p01c11o147.mxlogic.net (envelope-from ); Mon, 06 Jul 2009 16:49:19 -0600 (MDT) Received: from unknown [65.244.37.51] by p01c11o147.mxlogic.net (mxl_mta-6.2.0-4) with SMTP id 84f725a4.3441851280.57074.00-007.p01c11o147.mxlogic.net (envelope-from ); Mon, 06 Jul 2009 16:48:46 -0600 (MDT) Received: from STSNYCMS1.corp.root.ipc.com ([169.254.1.17]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Mon, 6 Jul 2009 18:48:05 -0400 From: "Jain, Rajnish" To: Vijay Gurbani , "dispatch@ietf.org" Date: Mon, 6 Jul 2009 18:48:04 -0400 Thread-Topic: [dispatch] Session Recording in SIP Thread-Index: Acny7zk28PigrO+0SryRcGZzpsB+WwLm/JUQ Message-ID: References: <4A3F03F6.6060505@alcatel-lucent.com> In-Reply-To: <4A3F03F6.6060505@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16746.004 x-tm-as-result: No--41.332800-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009062201)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=yoqeWMBPYRgA:10 a=z+2a4RCZxltofrpCDsS06w==:17 ] X-AnalysisOut: [a=48vgC7mUAAAA:8 a=N54-gffFAAAA:8 a=C3I3ZF1iAAAA:8 a=rsTP9] X-AnalysisOut: [UUIJSRVbRPeoCcA:9 a=-6oGfaeiiR0s-i-zEQMA:7 a=awAW17Cx9lyun] X-AnalysisOut: [sKnpVLeUHN3pHAA:4 a=Y_CllLRU3qkA:10 a=AqWPOPMqohMA:10 a=R7] X-AnalysisOut: [sS3KTgku8A:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=sK9FX9] X-AnalysisOut: [8U6w4A:10 a=nAPXUAfsBmEA:10 a=D-LbgnythcAQ404O:21 a=Bl22Pw] X-AnalysisOut: [NX0q18JbHi:21] Subject: Re: [dispatch] Session Recording in SIP 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, 06 Jul 2009 22:50:17 -0000 All: The following draft on SIP session recording requirements was submitte= d today: http://www.ietf.org/internet-drafts/draft-jain-dispatch-session-recording-p= rotocol-req-00.txt Title: Requirements for Session Recording Protocol (SRP) Abstract: Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically done by sending a copy of the media to the recording devices. This document specifies requirements for a protocol that will manage delivery of media from an end-point that originates media or that has access to it to a recording device. This protocol is being referred to as Session Recording Protocol and will most likely be based on SIP. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf > Of Vijay Gurbani > Sent: Monday, June 22, 2009 12:09 AM > To: dispatch@ietf.org > Subject: [dispatch] Summary on Session Recording in SIP > > All: Here is the summary of the Session Recording thread from June 9 > to June 19, 2009. If I misrepresented anything, please let me know. > > There was a fair amount of discussion on where to conduct this > work. In the end, it was decided to continue discussions on > dispatch, further decisions what to do -- new working group or > put this work in an existing working group -- will be decided > later. Regardless of where the work is done, opinions were > expressed that the work is important that it should commence > in the IETF. > > Need to be crisp about the purpose of this work: is it that users > record sessions to hear later, or sessions need to be recorded > because of some business needs? Or both? Is SRTP covered or > only RTP? > > Solutions should cover: > Always on recording > Recording on demand > Required recording > Pause and resume recording > Playback facilities and how they interact with recording > Recording formats and protocols for controlling the stored recording. > > A lot of discussion ensued on the specific architecture or > architectures that would be possible. No decision was reached on > which specific architecture is good or bad, although various opinions > were expressed in support for each. > > There are essentially four architectures to realize recording > services: two that discuss where the media stream is forked > out to the recorder -- at the UA or in a middlebox of some > sort are outlined here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html > > The third architecture has both UAs sending media to a > recorder. See: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html > > A fourth architecture that is a superset of the third one is at: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://ect.bell-labs.com/who/vkg > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From pkyzivat@cisco.com Mon Jul 6 17:01:16 2009 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 C647B3A688D for ; Mon, 6 Jul 2009 17:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 EILOa78su2GB for ; Mon, 6 Jul 2009 17:01:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D6AEC3A6806 for ; Mon, 6 Jul 2009 17:01:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,359,1243814400"; d="scan'208";a="183337102" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2009 00:00:45 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6700jCe002685; Mon, 6 Jul 2009 20:00:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6700jLB028705; Tue, 7 Jul 2009 00:00:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 20:00:45 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 20:00:44 -0400 Message-ID: <4A52902B.2030806@cisco.com> Date: Mon, 06 Jul 2009 20:00:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5202A1.6090501@ericsson.com> In-Reply-To: <4A5202A1.6090501@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 00:00:44.0749 (UTC) FILETIME=[F992A7D0:01C9FE95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=849; t=1246924845; x=1247788845; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Preconditions=20and=20inte rmediaries |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=loQ2ZXFmA7qCmR7LpB7G/pi145Wt6mDYWvH41jMMAKQ=; b=p5RAtTiD7xBJxzPqzr2TFGwe3F7PHMDiLgHggto6AbjVmqPqgy/BiPLLPh HdOj0yNQmHrjLAGm1ffFWZ9mw50TE+lqflqXil50e16hekn/rUhWx62BJ51I 0GEWIkkgUC; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DISPATCH Subject: Re: [dispatch] Preconditions and intermediaries 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, 07 Jul 2009 00:01:16 -0000 > 2. Starting Using the Media Parameters Subject to Preconditions ... > However, the fact that the UAs can start using the new media > parameters does not mean that they need to start using them > immediately. When preconditions are used, the UAS decides when to > start using them. Why do you say that? For one thing offerer and answerer have more significance than UAC and UAS in any such decision. For another, QoS needs to be obtained by both ends before it can be used by either end. The order in which it is obtained, and signaled that it has been obtained, is indeterminate. When one end has been told that the other end has obtained it, and knows that it has obtained it, then it can start using it. But that doesn't change the point about signaling the intent to start using. Thanks, Paul From AUDET@nortel.com Mon Jul 6 17:44:11 2009 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 875A43A6919 for ; Mon, 6 Jul 2009 17:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 DtH7Wfkj-OMQ for ; Mon, 6 Jul 2009 17:44:10 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7A2F63A698D for ; Mon, 6 Jul 2009 17:43:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n670eCh17101; Tue, 7 Jul 2009 00:40:12 GMT 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_01C9FE9B.B38DFA02" Date: Mon, 6 Jul 2009 19:41:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn+em+0BaLXNsLrTai84REw9nbCHwAHsoYnAABrlGA= References: <4A5261E2.4050506@cisco.com> From: "Francois Audet" To: "Henry Sinnreich" , "Paul Kyzivat" Cc: dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 00:44:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE9B.B38DFA02 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think what Paul calls automata is the application on the IM client, so = that would undermine what this spec and all of us in the Enterprise = space have been trying to do for years. =20 I will note that the "istyping" indication is already done today with = MESSAGE. And the istyping indicator is certainly an automata. And that = is an RFC today, and is widly deployed. =20 I personally don't really care if its a MESSAGE, a REFER, or an INFO = (although we certainly can rule out MBUS). Or a new message. =20 I don't think "other protocols" is a good answer: it has to be routable = just like SIP. ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 06, 2009 17:24 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); Salvatore Loreto; dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP =09 =09 Paul Kyzivat wrote: >Past suggestions by various people to send control signals (intended = tobe acted upon=20 >by automata rather than >people) via IM have generally been >rejected as inappropriate.=20 =09 I am not sure how many people expect a usage scenario for IM with an = automata in the middle or=20 what the deployment statistics are for such automata (I have never = encountered one). =20 =09 All SIP (or other protocol ) Communicator packages have IM and the URI = works there very nicely. =09 Do you have any usage statistics that justifies the assertion automata = are the=20 key usage scenario and "plain person to person" IM does not count? =09 Henry =09 =09 On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: =09 =09 =09 =09 =09 Henry Sinnreich wrote: >>We've looked at various approaches to solve this important >>problem several times before > > Actually there is one more: IM-ing a URI to some resource, mentioned = by > Henning Schulzrinne (I don't recall the document or presentation). > > My two cents is that IM-ing a URL is the most general solution, or = is it? =09 Past suggestions by various people to send control signals (intended = to be acted upon by automata rather than people) via IM have generally = been rejected as inappropriate. (The exception so far has been file = transfer, which has some control behavior and some expected human interaction.) =09 Now if you just want to say "Bob, please make a video call to sip:alice_camera@alice.com in order to see me" then I guess IM is ok. But IMO its not otherwise good. Its just a hack. =09 Thanks, Paul =09 > Henry > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > I'm glad to see this topic coming back. > > I see that this draft doesn't propose a solution to problem: it = list > three options, and describes why they are not adequate. I agree = with > the conclusions. > > We've looked at various approaches to solve this important = problem > several times before: > > - Feature ref (refer to urn: indicating specific features) > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > - Remote control using REFER to requests & responses > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > (Also, versions -04, -03,-02, -00) > > - Remore control using REFER with XML body describing function > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > - Remote control using MBUS > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 = & > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > On top of that there are various proprietary mechanisms, and = even > some legacy > PBX-CTI protocols. > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore = Loreto > > Sent: Monday, July 06, 2009 09:33 > > To: dispatch@ietf.org > > Subject: [dispatch] Disaggregated Media in SIP > > > > Hi there, > > > > I have just submitted a draft that talks of Disaggregated > > Media in the Session Initiation Protocol (SIP). > > = http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > ggregated-media-00.txt > > > > > > Abstract: > > Disaggregated media refers to the ability for a user to = create a > > multimedia session combining different media streams, coming = from > > different devices under his or her control, so that they are > > treated by > > the far end of the session as a single media session. > > This document lists several use cases that involve > > disaggregated media > > in SIP. > > Additionally, this document analyzes what types of > > disaggregated media > > can be implemented using existing protocol > > mechanisms, and the pros and cons of using each of those = mechanisms. > > Finally, this document describes scenarios that are not = covered by > > current mechanisms > > and proposes new IETF work to cover them. > > > > > > cheers > > Sal > > _______________________________________________ > > 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 =09 =09 ------_=_NextPart_001_01C9FE9B.B38DFA02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP
I=20 think what Paul calls automata is the application on the IM client, so = that=20 would undermine what this spec and all of us in the Enterprise space = have been=20 trying to do for years.
 
I will=20 note that the "istyping" indication is already done today with MESSAGE. = And the=20 istyping indicator is certainly an automata. And that is an RFC today, = and is=20 widly deployed.
 
I=20 personally don't really care if its a MESSAGE, a REFER, or an INFO = (although we=20 certainly can rule out MBUS). Or a new message.
 
I=20 don't think "other protocols" is a good answer: it has to be routable = just like=20 SIP.

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Monday, July 06, 2009=20 17:24
To: Paul Kyzivat
Cc: Audet, Francois = (SC100:3055);=20 Salvatore Loreto; dispatch@ietf.org
Subject: Re: [dispatch]=20 Disaggregated Media in SIP

Paul Kyzivat wrote:
>Past suggestions = by various=20 people to send control signals (intended tobe acted upon
>by = automata=20 rather than >people) via IM have generally been
>rejected as=20 inappropriate.

I am not sure how many people expect a usage = scenario=20 for IM with an automata in the middle or
what the deployment = statistics=20 are for such automata (I have never encountered one). =  

All SIP=20 (or other protocol ) Communicator packages have IM and the URI works = there=20 very nicely.

Do you have any usage statistics that justifies = the=20 assertion automata are the
key usage scenario and =93plain person = to person=94=20 IM does not count?

Henry


On 7/6/09 3:43 PM, "Paul = Kyzivat"=20 <pkyzivat@cisco.com>=20 wrote:



Henry Sinnreich = wrote:
>>We've=20 looked at various approaches to solve this = important
>>problem=20 several times before
>
> Actually there is one more: = IM-ing a=20 URI to some resource, mentioned by
> Henning Schulzrinne (I = don=92t=20 recall the document or presentation).
>
> My two cents = is that=20 IM-ing a URL is the most general solution, or is it?

Past = suggestions=20 by various people to send control signals (intended to
be acted = upon by=20 automata rather than people) via IM have generally been
rejected = as=20 inappropriate. (The exception so far has been file = transfer,
which has=20 some control behavior and some expected human = interaction.)

Now if=20 you just want to say "Bob, please make a video call to
sip:alice_camera@alice.com in order = to see me"=20 then I guess IM is ok.
But IMO its not otherwise good. Its just a = = hack.

        Thanks,
&= nbsp;       Paul

>=20 Henry
>
>
> On 7/6/09 12:07 PM, "Francois Audet" = <audet@nortel.com> = wrote:
>
>=20     I'm glad to see this topic coming=20 back.
>
>     I see that this draft = doesn't=20 propose a solution to problem: it list
> =     three=20 options, and describes why they are not adequate. I agree = with
>=20     the conclusions.
>
>=20     We've looked at various approaches to solve = this=20 important problem
>     several times=20 before:
>
>     - Feature ref (refer = to urn:=20 indicating specific features)
> =       ht= tp://tools.ietf.org/html/draft-audet-sipping-feature-ref-00
>>=20     - Remote control using REFER to requests = &=20 responses
>       http://to= ols.ietf.org/html/draft-mahy-sip-remote-cc-05
>=20       (Also, versions -04, -03,-02,=20 -00)
>
>     - Remore control using = REFER=20 with XML body describing function
>=20       http://to= ols.ietf.org/html/draft-mahy-sip-remote-cc-01
>
>=20     - Remote control using MBUS
>=20       ht= tp://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01=20 &
>       http://= tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01
>
>=20     On top of that there are various proprietary = mechanisms, and even
>     some = legacy
>=20     PBX-CTI protocols.
>
>=20     >  -----Original = Message-----
>=20     >  From: dispatch-bounces@ietf.org
> =     >  [mailto:dispatch-bounces@ietf.or= g]=20 On Behalf Of Salvatore Loreto
>     >=20  Sent: Monday, July 06, 2009 09:33
> =     >=20  To: dispatch@ietf.org
>=20     >  Subject: [dispatch] Disaggregated = Media=20 in SIP
>     >
>=20     >  Hi there,
>=20     >
>     > =  I=20 have just submitted a draft that talks of Disaggregated
>=20     >  Media in the Session Initiation = Protocol=20 (SIP).
>     >  h= ttp://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa
>= =20     ggregated-media-00.txt
>=20     >
> =     >
>=20     >  Abstract:
>=20     >  Disaggregated media refers to the = ability=20 for a user to create a
>     > =  multimedia=20 session combining different media streams, coming from
>=20     >  different devices under his or = her=20 control, so that they are
>     > =  treated=20 by
>     >  the far end of the = session as=20 a single media session.
>     > =  This=20 document lists several use cases that involve
>=20     >  disaggregated media
>=20     >  in SIP.
>=20     >  Additionally, this document = analyzes what=20 types of
>     >  disaggregated=20 media
>     >  can be implemented = using=20 existing protocol
>     > =  mechanisms, and=20 the pros and cons of using each of those mechanisms.
>=20     >  Finally, this document describes=20 scenarios that are not covered by
> =     >=20  current mechanisms
>     > =  and=20 proposes new IETF work to cover them.
>=20     >
> =     >
>=20     >  cheers
>=20     >  Sal
> =     >=20  _______________________________________________
>=20     >  dispatch mailing list
>=20     >  dispatch@ietf.org
>=20     >  https://www.ietf.= org/mailman/listinfo/dispatch
>=20     >
>=20 =     _______________________________________________>=20     dispatch mailing list
>=20     dispatch@ietf.org
>=20     https://www.ietf.= org/mailman/listinfo/dispatch
>
>
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 _______________________________________________
> dispatch = mailing=20 list
> dispatch@ietf.org
> https://www.ietf.= org/mailman/listinfo/dispatch

------_=_NextPart_001_01C9FE9B.B38DFA02-- From hsinnrei@adobe.com Mon Jul 6 17:55:31 2009 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 4E65B28C35E for ; Mon, 6 Jul 2009 17:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.781 X-Spam-Level: X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 RVfhGAxgGf4d for ; Mon, 6 Jul 2009 17:55:24 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id BBA8728C2E0 for ; Mon, 6 Jul 2009 17:55:00 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSlKc43ThmCDdn7reVLHAxH1l/nnJdiRA@postini.com; Mon, 06 Jul 2009 17:55:50 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n670stWG011242; Mon, 6 Jul 2009 17:54:56 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n670sniq025212; Mon, 6 Jul 2009 17:54:49 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 6 Jul 2009 17:54:50 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Mon, 6 Jul 2009 17:54:49 -0700 From: Henry Sinnreich To: Francois Audet , Paul Kyzivat Date: Mon, 6 Jul 2009 17:54:47 -0700 Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: Acn+em+0BaLXNsLrTai84REw9nbCHwAHsoYnAABrlGAAAKd/zQ== Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C678070748F5hsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 00:55:31 -0000 --_000_C678070748F5hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francois Audet wrote: >spec and all of us in the Enterprise space have been trying to do for year= s. Now this makes sense. But still, can you share some data of its real life usage, as compared to w= hat is out today in various SIP Communicators? That would rule our the pers= on-to-person IM scenarios? >I don't think "other protocols" is a good answer: it has to be routable ju= st like SIP. This again makes sense to me. (neglecting the facts about Jabber IM [such as in the IETF], Skype, etc.) Henry On 7/6/09 7:41 PM, "Francois Audet" wrote: I think what Paul calls automata is the application on the IM client, so th= at would undermine what this spec and all of us in the Enterprise space hav= e been trying to do for years. I will note that the "istyping" indication is already done today with MESSA= GE. And the istyping indicator is certainly an automata. And that is an RFC= today, and is widly deployed. I personally don't really care if its a MESSAGE, a REFER, or an INFO (altho= ugh we certainly can rule out MBUS). Or a new message. I don't think "other protocols" is a good answer: it has to be routable jus= t like SIP. ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Monday, July 06, 2009 17:24 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); Salvatore Loreto; dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat wrote: >Past suggestions by various people to send control signals (intended tobe= acted upon >by automata rather than >people) via IM have generally been >rejected as inappropriate. I am not sure how many people expect a usage scenario for IM with an autom= ata in the middle or what the deployment statistics are for such automata (I have never encount= ered one). All SIP (or other protocol ) Communicator packages have IM and the URI wor= ks there very nicely. Do you have any usage statistics that justifies the assertion automata are= the key usage scenario and "plain person to person" IM does not count? Henry On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: Henry Sinnreich wrote: >>We've looked at various approaches to solve this important >>problem several times before > > Actually there is one more: IM-ing a URI to some resource, mentioned by > Henning Schulzrinne (I don't recall the document or presentation). > > My two cents is that IM-ing a URL is the most general solution, or is it= ? Past suggestions by various people to send control signals (intended to be acted upon by automata rather than people) via IM have generally been rejected as inappropriate. (The exception so far has been file transfer, which has some control behavior and some expected human interaction.) Now if you just want to say "Bob, please make a video call to sip:alice_camera@alice.com in order to see me" then I guess IM is ok. But IMO its not otherwise good. Its just a hack. Thanks, Paul > Henry > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > I'm glad to see this topic coming back. > > I see that this draft doesn't propose a solution to problem: it list > three options, and describes why they are not adequate. I agree with > the conclusions. > > We've looked at various approaches to solve this important problem > several times before: > > - Feature ref (refer to urn: indicating specific features) > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > - Remote control using REFER to requests & responses > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > (Also, versions -04, -03,-02, -00) > > - Remore control using REFER with XML body describing function > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > - Remote control using MBUS > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > On top of that there are various proprietary mechanisms, and even > some legacy > PBX-CTI protocols. > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > > Sent: Monday, July 06, 2009 09:33 > > To: dispatch@ietf.org > > Subject: [dispatch] Disaggregated Media in SIP > > > > Hi there, > > > > I have just submitted a draft that talks of Disaggregated > > Media in the Session Initiation Protocol (SIP). > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > ggregated-media-00.txt > > > > > > Abstract: > > Disaggregated media refers to the ability for a user to create a > > multimedia session combining different media streams, coming from > > different devices under his or her control, so that they are > > treated by > > the far end of the session as a single media session. > > This document lists several use cases that involve > > disaggregated media > > in SIP. > > Additionally, this document analyzes what types of > > disaggregated media > > can be implemented using existing protocol > > mechanisms, and the pros and cons of using each of those mechanis= ms. > > Finally, this document describes scenarios that are not covered = by > > current mechanisms > > and proposes new IETF work to cover them. > > > > > > cheers > > Sal > > _______________________________________________ > > 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 --_000_C678070748F5hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP Francois Audet wrote:
>spec and all of us in the Enterprise space have been try= ing to do for years.

Now this makes sense.
But still, can you share some data of its real life usage, as compared to w= hat is out today in various SIP Communicators? That would rule our the pers= on-to-person IM scenarios?

>I don't think "= ;other protocols" is a good answer: it has to be routable just like SI= P.
This again makes sense to me.
(neglecting the fa= cts about Jabber IM [such as in the IETF], Skype,  etc.)

Henry


On 7/6/09 7:41 PM, "Francois Audet" <audet@nortel.com> wrote:

I think what Paul calls automata is the applicat= ion on the IM client, so that would undermine what this spec and all of us = in the Enterprise space have been trying to do for years.
I will note that the &q= uot;istyping" indication is already done today with MESSAGE. And the i= styping indicator is certainly an automata. And that is an RFC today, and i= s widly deployed.
I personally don't real= ly care if its a MESSAGE, a REFER, or an INFO (although we certainly can ru= le out MBUS). Or a new message.
I don't think "oth= er protocols" is a good answer: it has to be routable just like SIP.

 
From: Henry Sinnreich  [mailto:hsinnrei@adobe.com]
Sent: Monday, July 06, 2009  17:24
To: Paul Kyzivat
Cc: Audet, Francois (SC100:3055);  Salvatore Loreto; dispatch@ietf.org
Subject: Re: [dispatch]  Disaggregated Media in SIP

 
Paul Kyzivat wrote:
>Past suggestions by various  people to send control signals (inten= ded tobe acted upon
>by automata  rather than >people) via IM have generally been >rejected as  inappropriate.

I am not sure how many people expect a usage scenario  for IM with an = automata in the middle or
what the deployment statistics  are for such automata (I have never en= countered one).  

All SIP  (or other protocol ) Communicator packages have IM and the UR= I works there  very nicely.

Do you have any usage statistics that justifies the  assertion automat= a are the
key usage scenario and “plain person to person”  IM does n= ot count?

Henry


On 7/6/09 3:43 PM, "Paul Kyzivat"  <pkyzivat@cisco.com>  wrote:

 



Henry Sinnreich wrote:
>>We've  looked at various approaches to solve this important >>problem  several times before
>
> Actually there is one more: IM-ing a  URI to some resource, menti= oned by
> Henning Schulzrinne (I don’t  recall the document or presen= tation).
>
> My two cents is that  IM-ing a URL is the most general solution, = or is it?

Past suggestions  by various people to send control signals (intended = to
be acted upon by  automata rather than people) via IM have generally b= een
rejected as  inappropriate. (The exception so far has been file transf= er,
which has  some control behavior and some expected human interaction.)=

Now if  you just want to say "Bob, please make a video call to sip:alice_camera@alice.com in order = to see me"  then I guess IM is ok.
But IMO its not otherwise good. Its just a  hack.

        Thanks,
        Paul

>  Henry
>
>
> On 7/6/09 12:07 PM, "Francois Audet" <audet@nortel.com> wrote:
>
>      I'm glad to see this topic coming  = back.
>
>     I see that this draft doesn't  propose a = solution to problem: it list
>     three  options, and describes why they ar= e not adequate. I agree with
>      the conclusions.
>
>      We've looked at various approaches to so= lve this  important problem
>     several times  before:
>
>     - Feature ref (refer to urn:  indicating = specific features)
>       http://tools.ietf.org/html/draft-au= det-sipping-feature-ref-00
>
>      - Remote control using REFER to requests= &  responses
>       http://tools.ietf.org/html/draft-mahy-sip-= remote-cc-05
>        (Also, versions -04, -03,-02= ,  -00)
>
>     - Remore control using REFER  with XML bo= dy describing function
>        http://tools.ietf.org/html/draft-mah= y-sip-remote-cc-01
>
>      - Remote control using MBUS
>        http://tools.ietf.org/html/dr= aft-mahy-mmusic-mbus-remotecc-01  &
>       http://tools.ietf.org/html/draft-mahy-mm= usic-mbus-sdp-01
>
>      On top of that there are various proprie= tary  mechanisms, and even
>     some legacy
>      PBX-CTI protocols.
>
>      >  -----Original Message----- >      >  From: dispatch-bounces@ietf.org
>      >  [mailto:dispatch-bounces@ietf.org]  On Behalf Of S= alvatore Loreto
>     >   Sent: Monday, July 06, 2009 0= 9:33
>     >   To: dispatch@ietf.org
>      >  Subject: [dispatch] Disaggreg= ated Media  in SIP
>     >
>      >  Hi there,
>      >
>     >  I  have just submitted a draft= that talks of Disaggregated
>      >  Media in the Session Initiati= on Protocol  (SIP).
>     >  http://www.ietf.org/internet-drafts= /draft-loreto-dispatch-disa
>      ggregated-media-00.txt
>      >
>     >
>      >  Abstract:
>      >  Disaggregated media refers to= the ability  for a user to create a
>     >  multimedia  session combining = different media streams, coming from
>      >  different devices under his o= r her  control, so that they are
>     >  treated  by
>     >  the far end of the session as  = ;a single media session.
>     >  This  document lists several u= se cases that involve
>      >  disaggregated media
>      >  in SIP.
>      >  Additionally, this document a= nalyzes what  types of
>     >  disaggregated  media
>     >  can be implemented using  exis= ting protocol
>     >  mechanisms, and  the pros and = cons of using each of those mechanisms.
>      >  Finally, this document descri= bes  scenarios that are not covered by
>     >   current mechanisms
>     >  and  proposes new IETF work to= cover them.
>      >
>     >
>      >  cheers
>      >  Sal
>     >   _____________________________= __________________
>      >  dispatch mailing list
>      >  dispatch@ietf.org
>      >  https://www.ietf.org/mailman/listinfo/dispatc= h
>      >
>      ________________________________________= _______
>      dispatch mailing list
>      dispatch@i= etf.org
>      https://www.ietf.org/mailman/listinfo/dispatch
>
>
>  ----------------------------------------------------------------= --------
>
>  _______________________________________________
> dispatch mailing  list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch


--_000_C678070748F5hsinnreiadobecom_-- From hsinnrei@adobe.com Mon Jul 6 18:48:54 2009 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 EBF5D3A6A17 for ; Mon, 6 Jul 2009 18:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.612, 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 fbcThvbTK7qD for ; Mon, 6 Jul 2009 18:48:49 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id CD42B28C131 for ; Mon, 6 Jul 2009 18:48:48 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKSlKpiqT2Cfxp3LOYxu/WXws0lbhKGIYf@postini.com; Mon, 06 Jul 2009 18:49:15 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n670Hhao023358; Mon, 6 Jul 2009 17:17:43 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n670O3iq007226; Mon, 6 Jul 2009 17:24:03 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 6 Jul 2009 17:24:03 -0700 From: Henry Sinnreich To: Paul Kyzivat Date: Mon, 6 Jul 2009 17:24:01 -0700 Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: Acn+em+0BaLXNsLrTai84REw9nbCHwAHsoYn Message-ID: In-Reply-To: <4A5261E2.4050506@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C677FFD148EBhsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 01:48:55 -0000 --_000_C677FFD148EBhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul Kyzivat wrote: >Past suggestions by various people to send control signals (intended tobe = acted upon >by automata rather than >people) via IM have generally been >rejected as inappropriate. I am not sure how many people expect a usage scenario for IM with an automa= ta in the middle or what the deployment statistics are for such automata (I have never encounte= red one). All SIP (or other protocol ) Communicator packages have IM and the URI work= s there very nicely. Do you have any usage statistics that justifies the assertion automata are = the key usage scenario and "plain person to person" IM does not count? Henry On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: Henry Sinnreich wrote: >>We've looked at various approaches to solve this important >>problem several times before > > Actually there is one more: IM-ing a URI to some resource, mentioned by > Henning Schulzrinne (I don't recall the document or presentation). > > My two cents is that IM-ing a URL is the most general solution, or is it? Past suggestions by various people to send control signals (intended to be acted upon by automata rather than people) via IM have generally been rejected as inappropriate. (The exception so far has been file transfer, which has some control behavior and some expected human interaction.) Now if you just want to say "Bob, please make a video call to sip:alice_camera@alice.com in order to see me" then I guess IM is ok. But IMO its not otherwise good. Its just a hack. Thanks, Paul > Henry > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > I'm glad to see this topic coming back. > > I see that this draft doesn't propose a solution to problem: it list > three options, and describes why they are not adequate. I agree with > the conclusions. > > We've looked at various approaches to solve this important problem > several times before: > > - Feature ref (refer to urn: indicating specific features) > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > - Remote control using REFER to requests & responses > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > (Also, versions -04, -03,-02, -00) > > - Remore control using REFER with XML body describing function > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > - Remote control using MBUS > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > On top of that there are various proprietary mechanisms, and even > some legacy > PBX-CTI protocols. > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > > Sent: Monday, July 06, 2009 09:33 > > To: dispatch@ietf.org > > Subject: [dispatch] Disaggregated Media in SIP > > > > Hi there, > > > > I have just submitted a draft that talks of Disaggregated > > Media in the Session Initiation Protocol (SIP). > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > ggregated-media-00.txt > > > > > > Abstract: > > Disaggregated media refers to the ability for a user to create a > > multimedia session combining different media streams, coming from > > different devices under his or her control, so that they are > > treated by > > the far end of the session as a single media session. > > This document lists several use cases that involve > > disaggregated media > > in SIP. > > Additionally, this document analyzes what types of > > disaggregated media > > can be implemented using existing protocol > > mechanisms, and the pros and cons of using each of those mechanism= s. > > Finally, this document describes scenarios that are not covered by > > current mechanisms > > and proposes new IETF work to cover them. > > > > > > cheers > > Sal > > _______________________________________________ > > 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 --_000_C677FFD148EBhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat wrote:
>Past suggestions by various people to send control signals (intended to= be acted upon
>by automata rather than >people) via IM have generally been
>rejected as inappropriate.

I am not sure how many people expect a usage scenario for IM with an automa= ta in the middle or
what the deployment statistics are for such automata (I have never encounte= red one).  

All SIP (or other protocol ) Communicator packages have IM and the URI work= s there very nicely.

Do you have any usage statistics that justifies the assertion automata are = the
key usage scenario and “plain person to person” IM does not cou= nt?

Henry


On 7/6/09 3:43 PM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:




Henry Sinnreich wrote:
>>We've looked at various approaches to solve this important
>>problem several times before
>
> Actually there is one more: IM-ing a URI to some resource, mentioned b= y
> Henning Schulzrinne (I don’t recall the document or presentation= ).
>
> My two cents is that IM-ing a URL is the most general solution, or is = it?

Past suggestions by various people to send control signals (intended to
be acted upon by automata rather than people) via IM have generally been rejected as inappropriate. (The exception so far has been file transfer, which has some control behavior and some expected human interaction.)

Now if you just want to say "Bob, please make a video call to
sip:alice_camera@alice.com in order = to see me" then I guess IM is ok.
But IMO its not otherwise good. Its just a hack.

        Thanks,
        Paul

> Henry
>
>
> On 7/6/09 12:07 PM, "Francois Audet" <audet@nortel.com> wrote:
>
>     I'm glad to see this topic coming back.
>
>     I see that this draft doesn't propose a soluti= on to problem: it list
>     three options, and describes why they are not = adequate. I agree with
>     the conclusions.
>
>     We've looked at various approaches to solve th= is important problem
>     several times before:
>
>     - Feature ref (refer to urn: indicating specif= ic features)
>       http://tools.ietf.org/html/draft-au= det-sipping-feature-ref-00
>
>     - Remote control using REFER to requests &= responses
>       http://tools.ietf.org/html/draft-mahy-sip-= remote-cc-05
>       (Also, versions -04, -03,-02, -00)=
>
>     - Remore control using REFER with XML body des= cribing function
>       http://tools.ietf.org/html/draft-mahy-sip-= remote-cc-01
>
>     - Remote control using MBUS
>       http://tools.ietf.org/html/draft-ma= hy-mmusic-mbus-remotecc-01 &
>       http://tools.ietf.org/html/draft-mahy-mm= usic-mbus-sdp-01
>
>     On top of that there are various proprietary m= echanisms, and even
>     some legacy
>     PBX-CTI protocols.
>
>     >  -----Original Message-----
>     >  From: dispatch-bounces@ietf.org
>     >  [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Lor= eto
>     >  Sent: Monday, July 06, 2009 09:33 >     >  To: d= ispatch@ietf.org
>     >  Subject: [dispatch] Disaggregated M= edia in SIP
>     >
>     >  Hi there,
>     >
>     >  I have just submitted a draft that = talks of Disaggregated
>     >  Media in the Session Initiation Pro= tocol (SIP).
>     >  http://www.ietf.org/internet-drafts= /draft-loreto-dispatch-disa
>     ggregated-media-00.txt
>     >
>     >
>     >  Abstract:
>     >  Disaggregated media refers to the a= bility for a user to create a
>     >  multimedia session combining differ= ent media streams, coming from
>     >  different devices under his or her = control, so that they are
>     >  treated by
>     >  the far end of the session as a sin= gle media session.
>     >  This document lists several use cas= es that involve
>     >  disaggregated media
>     >  in SIP.
>     >  Additionally, this document analyze= s what types of
>     >  disaggregated media
>     >  can be implemented using existing p= rotocol
>     >  mechanisms, and the pros and cons o= f using each of those mechanisms.
>     >  Finally, this document describes sc= enarios that are not covered by
>     >  current mechanisms
>     >  and proposes new IETF work to cover= them.
>     >
>     >
>     >  cheers
>     >  Sal
>     >  ___________________________________= ____________
>     >  dispatch mailing list
>     >  dispa= tch@ietf.org
>     >  https://www.ietf.org/mailman/listinfo/dispatch<= BR> >     >
>     ______________________________________________= _
>     dispatch mailing list
>     dispatch@ietf.or= g
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>
> ----------------------------------------------------------------------= --
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch

--_000_C677FFD148EBhsinnreiadobecom_-- From HKaplan@acmepacket.com Mon Jul 6 22:07:52 2009 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 651283A6DF4; Mon, 6 Jul 2009 22:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 Y1JX9gbFFEt9; Mon, 6 Jul 2009 22:07:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E493D3A6A57; Mon, 6 Jul 2009 22:07:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 7 Jul 2009 01:06:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 7 Jul 2009 01:06:22 -0400 From: Hadriel Kaplan To: "mmusic@ietf.org" Date: Tue, 7 Jul 2009 01:06:16 -0400 Thread-Topic: A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBA= Message-ID: References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr> 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 Cc: "sipping@ietf.org" , "dispatch@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" Subject: [dispatch] A replacement for ANAT 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, 07 Jul 2009 05:07:52 -0000 BTW, this draft was submitted in response to the discussion around the need= for an ANAT-type model that was backwards-compatible, and for a v4/v6 stac= k option-tag indicator, which was a topic of discussion on SIPPING back in = February and March. That thread started with: http://www.ietf.org/mail-archive/web/sipping/current/msg16718.html -hadriel p.s. sorry about the cross-posting, but SIPPING is effectively closed (righ= t?) so it's hard to know where to post such notices which are tightly relat= ed to SIP. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of mohamed.boucadair@orange-ftgroup.com > Sent: Monday, July 06, 2009 7:44 AM >=20 > Dear all, >=20 > This draft has been submitted. >=20 > Comments and suggestions are more than welcome. >=20 >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > De la part de Internet-Drafts@ietf.org > Envoy=E9 : lundi 6 juillet 2009 11:45 > =C0 : i-d-announce@ietf.org > Objet : I-D Action:draft-boucadair-mmusic-ccap-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Session Description Protocol (SDP) Connectivity > Capability (CCAP) Attribute > Author(s) : M. Boucadair, H. Kaplan > Filename : draft-boucadair-mmusic-ccap-00.txt > Pages : 14 > Date : 2009-07-06 >=20 > This memo proposes a mechanism which allows to carry multiple IP > addresses, of different address families (e.g., IPv4, IPv6), in the same > SDP offer/answer. The proposed attribute solves the backward > compatibility problem which plagued ANAT, due to its syntax. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-ccap-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From R.Jesske@telekom.de Mon Jul 6 22:17:26 2009 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 382E43A6B4F for ; Mon, 6 Jul 2009 22:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ekXt9n1WGcYX for ; Mon, 6 Jul 2009 22:17:24 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 4BE4F3A68DA for ; Mon, 6 Jul 2009 22:17:24 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 07 Jul 2009 07:13:38 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 07:13:38 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 07:13:37 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: Acn+T6ZY4XK8mGxETjyJ6VOaKTzT4gAcRVfQ References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> From: To: X-OriginalArrivalTime: 07 Jul 2009 05:13:38.0923 (UTC) FILETIME=[AFDA43B0:01C9FEC1] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 07 Jul 2009 05:17:26 -0000 Hi Dale, Within the SIPPING group I had already discussions on that issue. The assumption was that the use of the Reason Header within Responses is = conditionally allowed.=20 The RFC 3326 says: 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 whose status code explicitly allows the presence of this header field. So we need a draft where it is stated that a reason header can be = included within the SIP Response. That was also the recommendation of = that discussion. That is why I wrote a draft. Nevertheless some standards already include this behaviour like the = ITU-T Q.1912.5 specification. Also 3GPP needs the reason header within Responses. Now due to the fact that the draft is expired and with the = reorganisation of SIP and SIPPING the questioned appeared where such = draft would like to fit best. SIPCORE, DISPATCH or BLISS. =20 Best Regards, Roland =20 -----Urspr=FCngliche Nachricht----- Von: Dale Worley [mailto:dworley@nortel.com]=20 Gesendet: Montag, 6. Juli 2009 17:37 An: Jesske, Roland Cc: DISPATCH Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 On Mon, 2009-07-06 at 13:50 +0200, R.Jesske@telekom.de wrote: > Dear all,=20 > After getting no response to my question from the dispatch. I assume > that there is no interest on this draft within dispatch. >=20 > So now I would like to ask the people from SIPCORE and BILSS where do > they see the work. >=20 > The below mentioned draft describes the use of the Reason Header > within Resoponses for interoperability with the existing PSTN/ISDN > networks. Is the Abstract right? As far as I can tell (by reading section 2), the Abstract doesn't describe the draft at all. That might be a reason that you haven't gotten any response -- the Abstract "proposes the use of the Reason header field in SIP responses", but that is something that is already defined and allowed. Dale From pkyzivat@cisco.com Tue Jul 7 06:04:58 2009 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 5D2673A6E6E for ; Tue, 7 Jul 2009 06:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 nnHcJsOnjBwI for ; Tue, 7 Jul 2009 06:04:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B57D628C4AB for ; Tue, 7 Jul 2009 06:03:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,362,1243814400"; d="scan'208";a="49616705" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2009 13:03:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n67D3O0R020032; Tue, 7 Jul 2009 09:03:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n67D3OBZ015249; Tue, 7 Jul 2009 13:03:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 09:03:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 09:03:23 -0400 Message-ID: <4A53479B.70908@cisco.com> Date: Tue, 07 Jul 2009 09:03:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jul 2009 13:03:23.0779 (UTC) FILETIME=[4F55FD30:01C9FF03] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6497; t=1246971804; x=1247835804; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Henry=20Sinnreich=20; bh=FACH9Z4Az8eFnnhyo2QNRNmGIsgLe5ZBd+UK3hYUFeg=; b=Ewc5i/wh1laMLkuJ+ys97Bf66ZEsHEZ2eXdi/++9GMDSSJx4s0dj18olrm qDb4yddNW4//jH3pC3ZMZh8moDzaSzg6tQdWVJFHuen1XhufSg2OrwCPFIDf +5Zq3kkSRo; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 13:04:58 -0000 Henry Sinnreich wrote: > Paul Kyzivat wrote: >>Past suggestions by various people to send control signals (intended > tobe acted upon >>by automata rather than >people) via IM have generally been >>rejected as inappropriate. > > I am not sure how many people expect a usage scenario for IM with an > automata in the middle or > what the deployment statistics are for such automata (I have never > encountered one). > > All SIP (or other protocol ) Communicator packages have IM and the URI > works there very nicely. > > Do you have any usage statistics that justifies the assertion automata > are the > key usage scenario and “plain person to person” IM does not count? > > Henry I don't know of one either. But my observation is about using the IM message as a solution to the kinds of use cases that were presented in the draft, at least as I imagine them playing out. My mental model is of an environment where a significant fraction of people have multimedia UAs, and an expectation that those various media will be available in calls that they make. Now add to that people who have support for various media, but not in a single device. They then want to play in that same multimedia environment. In such a case, using IMs between people, so that they may establish separate calls for various media is clearly the poor man's choice - better than nothing but not ideal. And its especially poor if the "initial" call is not an IM call. Then just establishing an IM channel between the same two people is non-trivial. Thanks, Paul > On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: > > > > > Henry Sinnreich wrote: > > >We've looked at various approaches to solve this important > > >problem several times before > > > > Actually there is one more: IM-ing a URI to some resource, > mentioned by > > Henning Schulzrinne (I don’t recall the document or presentation). > > > > My two cents is that IM-ing a URL is the most general solution, or > is it? > > Past suggestions by various people to send control signals (intended to > be acted upon by automata rather than people) via IM have generally been > rejected as inappropriate. (The exception so far has been file transfer, > which has some control behavior and some expected human interaction.) > > Now if you just want to say "Bob, please make a video call to > sip:alice_camera@alice.com in order to see me" then I guess IM is ok. > But IMO its not otherwise good. Its just a hack. > > Thanks, > Paul > > > Henry > > > > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > > > I'm glad to see this topic coming back. > > > > I see that this draft doesn't propose a solution to problem: > it list > > three options, and describes why they are not adequate. I > agree with > > the conclusions. > > > > We've looked at various approaches to solve this important problem > > several times before: > > > > - Feature ref (refer to urn: indicating specific features) > > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > > > - Remote control using REFER to requests & responses > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > > (Also, versions -04, -03,-02, -00) > > > > - Remore control using REFER with XML body describing function > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > > > - Remote control using MBUS > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > > > On top of that there are various proprietary mechanisms, and even > > some legacy > > PBX-CTI protocols. > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore > Loreto > > > Sent: Monday, July 06, 2009 09:33 > > > To: dispatch@ietf.org > > > Subject: [dispatch] Disaggregated Media in SIP > > > > > > Hi there, > > > > > > I have just submitted a draft that talks of Disaggregated > > > Media in the Session Initiation Protocol (SIP). > > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > > ggregated-media-00.txt > > > > > > > > > Abstract: > > > Disaggregated media refers to the ability for a user to > create a > > > multimedia session combining different media streams, > coming from > > > different devices under his or her control, so that they are > > > treated by > > > the far end of the session as a single media session. > > > This document lists several use cases that involve > > > disaggregated media > > > in SIP. > > > Additionally, this document analyzes what types of > > > disaggregated media > > > can be implemented using existing protocol > > > mechanisms, and the pros and cons of using each of those > mechanisms. > > > Finally, this document describes scenarios that are not > covered by > > > current mechanisms > > > and proposes new IETF work to cover them. > > > > > > > > > cheers > > > Sal > > > _______________________________________________ > > > 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 pkyzivat@cisco.com Tue Jul 7 06:09:53 2009 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 9D5743A6E67 for ; Tue, 7 Jul 2009 06:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.363 X-Spam-Level: X-Spam-Status: No, score=-5.363 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 aH6or1frpa+7 for ; Tue, 7 Jul 2009 06:09:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F2AE73A67CC for ; Tue, 7 Jul 2009 06:09:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,362,1243814400"; d="scan'208";a="49617611" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2009 13:09:10 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n67D9AoC017516; Tue, 7 Jul 2009 09:09:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n67D9Ac0007786; Tue, 7 Jul 2009 13:09:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 09:09:10 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 09:09:09 -0400 Message-ID: <4A5348F5.5030200@cisco.com> Date: Tue, 07 Jul 2009 09:09:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jul 2009 13:09:09.0882 (UTC) FILETIME=[1DA11DA0:01C9FF04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7712; t=1246972150; x=1247836150; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Francois=20Audet=20; bh=KqRuqd37/f5W4wBBTolJKihXCNd+f6hTFVNHykYEyuY=; b=LtOtpHum9qkkfi5jQaKou9F4yKhL2Mip9Vswi9oX3v3NJifaAsNCIxAzVo BKoBhccv5oH0/i990uN8kj2nwoCSH2WhXedgpV29FReDWdlwiXFuFKrF3cWT FGetzjkLag; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 13:09:53 -0000 Francois Audet wrote: > I think what Paul calls automata is the application on the IM client, so > that would undermine what this spec and all of us in the Enterprise > space have been trying to do for years. > > I will note that the "istyping" indication is already done today with > MESSAGE. And the istyping indicator is certainly an automata. And that > is an RFC today, and is widly deployed. It is not something that is clear cut. I can make a case for istyping - it is indeed a message intended for human eyes, it is just encoded differently from plain text so that the receiving application has more options in rendering it. In that respect it isn't so different from html. > I personally don't really care if its a MESSAGE, a REFER, or an INFO > (although we certainly can rule out MBUS). Or a new message. I still remain unconvinced that it is either necessary or appropriate for one end of a call to be involved in how the other end aggregates media resources for the call. Thanks, Paul > I don't think "other protocols" is a good answer: it has to be routable > just like SIP. > > ------------------------------------------------------------------------ > *From:* Henry Sinnreich [mailto:hsinnrei@adobe.com] > *Sent:* Monday, July 06, 2009 17:24 > *To:* Paul Kyzivat > *Cc:* Audet, Francois (SC100:3055); Salvatore Loreto; dispatch@ietf.org > *Subject:* Re: [dispatch] Disaggregated Media in SIP > > Paul Kyzivat wrote: > >Past suggestions by various people to send control signals (intended > tobe acted upon > >by automata rather than >people) via IM have generally been > >rejected as inappropriate. > > I am not sure how many people expect a usage scenario for IM with an > automata in the middle or > what the deployment statistics are for such automata (I have never > encountered one). > > All SIP (or other protocol ) Communicator packages have IM and the > URI works there very nicely. > > Do you have any usage statistics that justifies the assertion > automata are the > key usage scenario and “plain person to person” IM does not count? > > Henry > > > On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: > > > > > Henry Sinnreich wrote: > > >We've looked at various approaches to solve this important > > >problem several times before > > > > Actually there is one more: IM-ing a URI to some resource, > mentioned by > > Henning Schulzrinne (I don’t recall the document or presentation). > > > > My two cents is that IM-ing a URL is the most general > solution, or is it? > > Past suggestions by various people to send control signals > (intended to > be acted upon by automata rather than people) via IM have > generally been > rejected as inappropriate. (The exception so far has been file > transfer, > which has some control behavior and some expected human > interaction.) > > Now if you just want to say "Bob, please make a video call to > sip:alice_camera@alice.com in order to see me" then I guess IM > is ok. > But IMO its not otherwise good. Its just a hack. > > Thanks, > Paul > > > Henry > > > > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > > > I'm glad to see this topic coming back. > > > > I see that this draft doesn't propose a solution to > problem: it list > > three options, and describes why they are not adequate. I > agree with > > the conclusions. > > > > We've looked at various approaches to solve this important > problem > > several times before: > > > > - Feature ref (refer to urn: indicating specific features) > > > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > > > - Remote control using REFER to requests & responses > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > > (Also, versions -04, -03,-02, -00) > > > > - Remore control using REFER with XML body describing function > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > > > - Remote control using MBUS > > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 > & > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > > > On top of that there are various proprietary mechanisms, > and even > > some legacy > > PBX-CTI protocols. > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of > Salvatore Loreto > > > Sent: Monday, July 06, 2009 09:33 > > > To: dispatch@ietf.org > > > Subject: [dispatch] Disaggregated Media in SIP > > > > > > Hi there, > > > > > > I have just submitted a draft that talks of Disaggregated > > > Media in the Session Initiation Protocol (SIP). > > > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > > ggregated-media-00.txt > > > > > > > > > Abstract: > > > Disaggregated media refers to the ability for a user to > create a > > > multimedia session combining different media streams, > coming from > > > different devices under his or her control, so that > they are > > > treated by > > > the far end of the session as a single media session. > > > This document lists several use cases that involve > > > disaggregated media > > > in SIP. > > > Additionally, this document analyzes what types of > > > disaggregated media > > > can be implemented using existing protocol > > > mechanisms, and the pros and cons of using each of > those mechanisms. > > > Finally, this document describes scenarios that are not > covered by > > > current mechanisms > > > and proposes new IETF work to cover them. > > > > > > > > > cheers > > > Sal > > > _______________________________________________ > > > 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 drage@alcatel-lucent.com Tue Jul 7 07:48:28 2009 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 5948628C1A0 for ; Tue, 7 Jul 2009 07:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-2.005, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_FR=0.35] 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 Q-3aKNMgZLlY for ; Tue, 7 Jul 2009 07:48:27 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id C75DE3A6E8B for ; Tue, 7 Jul 2009 07:48:26 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n67Ea9pE022916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Jul 2009 16:48:06 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 7 Jul 2009 16:47:32 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Francois Audet Date: Tue, 7 Jul 2009 16:47:29 +0200 Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: Acn/BEoK3iWRUm49QwGl1dhy3xpSswADQHyg Message-ID: References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> In-Reply-To: <4A5348F5.5030200@cisco.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: Henry Sinnreich , "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 14:48:28 -0000 I understood the key distinction for MESSAGE method contents was not what g= enerated it, but how it was treated on reception. The prime use of the MESS= AGE method was where the contents were rendered to the user (even if they a= re generated by something that is an automata). If the contents were to be = understood by some automata, then PUBLISH or SUBSCRIBE / NOTIFY may be more= appropriate, or if there is an INVITE dialog around that pertains to the c= ommunication, then something else. Hopever the multiple methods for similar purposes discussion in SIP never r= eally resolved itself so I would say there is no definitive answer to this. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, July 07, 2009 2:09 PM > To: Francois Audet > Cc: Henry Sinnreich; dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 >=20 >=20 > Francois Audet wrote: > > I think what Paul calls automata is the application on the=20 > IM client,=20 > > so that would undermine what this spec and all of us in the=20 > Enterprise=20 > > space have been trying to do for years. > > =20 > > I will note that the "istyping" indication is already done=20 > today with=20 > > MESSAGE. And the istyping indicator is certainly an=20 > automata. And that=20 > > is an RFC today, and is widly deployed. >=20 > It is not something that is clear cut. I can make a case for=20 > istyping - it is indeed a message intended for human eyes, it=20 > is just encoded differently from plain text so that the=20 > receiving application has more options in rendering it. In=20 > that respect it isn't so different from html. >=20 > > I personally don't really care if its a MESSAGE, a REFER,=20 > or an INFO=20 > > (although we certainly can rule out MBUS). Or a new message. >=20 > I still remain unconvinced that it is either necessary or=20 > appropriate for one end of a call to be involved in how the=20 > other end aggregates media resources for the call. >=20 > Thanks, > Paul >=20 > > I don't think "other protocols" is a good answer: it has to be=20 > > routable just like SIP. > >=20 > > =20 > -------------------------------------------------------------- > ---------- > > *From:* Henry Sinnreich [mailto:hsinnrei@adobe.com] > > *Sent:* Monday, July 06, 2009 17:24 > > *To:* Paul Kyzivat > > *Cc:* Audet, Francois (SC100:3055); Salvatore Loreto;=20 > dispatch@ietf.org > > *Subject:* Re: [dispatch] Disaggregated Media in SIP > >=20 > > Paul Kyzivat wrote: > > >Past suggestions by various people to send control=20 > signals (intended > > tobe acted upon > > >by automata rather than >people) via IM have generally been > > >rejected as inappropriate. > >=20 > > I am not sure how many people expect a usage scenario=20 > for IM with an > > automata in the middle or > > what the deployment statistics are for such automata (I=20 > have never > > encountered one). =20 > >=20 > > All SIP (or other protocol ) Communicator packages have=20 > IM and the > > URI works there very nicely. > >=20 > > Do you have any usage statistics that justifies the assertion > > automata are the > > key usage scenario and =93plain person to person=94 IM does=20 > not count? > >=20 > > Henry > >=20 > >=20 > > On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: > >=20 > >=20 > >=20 > >=20 > > Henry Sinnreich wrote: > > > >We've looked at various approaches to solve this=20 > important > > > >problem several times before > > > > > > Actually there is one more: IM-ing a URI to some=20 > resource, > > mentioned by > > > Henning Schulzrinne (I don=92t recall the document=20 > or presentation). > > > > > > My two cents is that IM-ing a URL is the most general > > solution, or is it? > >=20 > > Past suggestions by various people to send control signals > > (intended to > > be acted upon by automata rather than people) via IM have > > generally been > > rejected as inappropriate. (The exception so far=20 > has been file > > transfer, > > which has some control behavior and some expected human > > interaction.) > >=20 > > Now if you just want to say "Bob, please make a=20 > video call to > > sip:alice_camera@alice.com in order to see me" then=20 > I guess IM > > is ok. > > But IMO its not otherwise good. Its just a hack. > >=20 > > Thanks, > > Paul > >=20 > > > Henry > > > > > > > > > On 7/6/09 12:07 PM, "Francois Audet"=20 > wrote: > > > > > > I'm glad to see this topic coming back. > > > > > > I see that this draft doesn't propose a solution to > > problem: it list > > > three options, and describes why they are=20 > not adequate. I > > agree with > > > the conclusions. > > > > > > We've looked at various approaches to solve=20 > this important > > problem > > > several times before: > > > > > > - Feature ref (refer to urn: indicating=20 > specific features) > > > > > =20 > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > > > > > - Remote control using REFER to requests & responses > > > =20 > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > > > (Also, versions -04, -03,-02, -00) > > > > > > - Remore control using REFER with XML body=20 > describing function > > > =20 > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > > > > > - Remote control using MBUS > > > > > =20 > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 > > & > > > =20 > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > > > > > On top of that there are various proprietary=20 > mechanisms, > > and even > > > some legacy > > > PBX-CTI protocols. > > > > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of > > Salvatore Loreto > > > > Sent: Monday, July 06, 2009 09:33 > > > > To: dispatch@ietf.org > > > > Subject: [dispatch] Disaggregated Media in SIP > > > > > > > > Hi there, > > > > > > > > I have just submitted a draft that talks=20 > of Disaggregated > > > > Media in the Session Initiation Protocol (SIP). > > > > > > =20 > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > > > ggregated-media-00.txt > > > > > > > > > > > > Abstract: > > > > Disaggregated media refers to the ability=20 > for a user to > > create a > > > > multimedia session combining different=20 > media streams, > > coming from > > > > different devices under his or her=20 > control, so that > > they are > > > > treated by > > > > the far end of the session as a single=20 > media session. > > > > This document lists several use cases that involve > > > > disaggregated media > > > > in SIP. > > > > Additionally, this document analyzes what types of > > > > disaggregated media > > > > can be implemented using existing protocol > > > > mechanisms, and the pros and cons of using each of > > those mechanisms. > > > > Finally, this document describes=20 > scenarios that are not > > covered by > > > > current mechanisms > > > > and proposes new IETF work to cover them. > > > > > > > > > > > > cheers > > > > Sal > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > =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 AUDET@nortel.com Tue Jul 7 08:23:01 2009 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 67FA83A6BC5 for ; Tue, 7 Jul 2009 08:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 HYNLiz6kNwav for ; Tue, 7 Jul 2009 08:23:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3B11E3A699D for ; Tue, 7 Jul 2009 08:23:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n67FM6l22572; Tue, 7 Jul 2009 15:22:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 10:22:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5348F5.5030200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn/BCBE2EFfML/VQOKaMaSnmaoXdwAEbeUQ References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 15:23:01 -0000 > I still remain unconvinced that it is either necessary or=20 > appropriate for one end of a call to be involved in how the=20 > other end aggregates media resources for the call. I don't understand what this statement means. Everybody now has multiple devices these days. With the amount of implementations of Remote Call Control=20 using various proprietary mechanisms out there, it is pretty clear that there is a need for this type of functionality. That does not necessarily means that one end is necessarily involved in how "the other end aggregates media resources". In my mind, it's more of how do you share the session, and partition the media streams. From AUDET@nortel.com Tue Jul 7 08:44:42 2009 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 2037828C2CB for ; Tue, 7 Jul 2009 08:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 ypPABli3tcC9 for ; Tue, 7 Jul 2009 08:44:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D6BFA28C29E for ; Tue, 7 Jul 2009 08:44:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n67Fgj101940; Tue, 7 Jul 2009 15:42:46 GMT 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_01C9FF19.CA7393C0" Date: Tue, 7 Jul 2009 10:44:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91E24@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn/A1Fz4xI92qwHQBmINfVm9yFUrAAE44DcAAAy4hA= References: <4A53479B.70908@cisco.com> From: "Francois Audet" To: "Henry Sinnreich" , "Paul Kyzivat" Cc: dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 15:44:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FF19.CA7393C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Correct. =20 I agree with Henry. The bootstrap is typically the IM/Presence session, = not the voice session. That would mean XMPP or SIMPLE. =20 To me this is a different than the "multiple device" issue, but they are = quite intertwinned. =20 A scenario where you contact somebody using presence on a PC client or = Web Page, or smart phone/PDA, perhaps IM, and then initiate a voice call = using a desktop phone is a classic example. =20 In a "loosely coupled" model, all that you'd need from the PC Client/Web = Page/Smart Phone/PDA is: * The ability to initiate the call using the alternate device * The ability to do basic control functions for the call using the = primary (rich UI) interface, for that call on the alternate device: = answer/terminate/hold/etc. =20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Tuesday, July 07, 2009 08:23 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); Salvatore Loreto; dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP =09 =09 Paul, =09 This is getting interesting, so let's see... =09 >In such a case, using IMs between people, so that they may establish >separate calls for various media is clearly the poor man's choice - >better than nothing but not ideal. And its especially poor if the = "initial" call is not an IM call.=20 >Then just establishing an IM channel >between the same two people is non-trivial. =09 No matter what type of communicator we use: SIP, Skype, Jabber, iChat, = etc., most courteous people will first IM to ask if the other party can = speak right now or later. While talking, they may also chose to add = video. And if planned, also add desktop sharing. =09 So the natural order of communications seems to be mostly:=20 Presence (or the web conference URI), IM, voice, video, desktop = sharing, conferencing, but certainly it all starts with a URI for the = rendezvous function. =09 It seems we differ (or do we?) on three points: =09 1. Communicator "calls" are not the poor mans choice,=20 2. It most often starts with presence and IM,=20 3. The URI (or Skype name) of the other party in the address book is = all that's required. Or the social network as an address book. =09 =09 Now leaving for a moment telephony aside, let's look at some new usage = scenarios: =09 * People in social networks (Twitter, Facebook, etc.)=20 * Telepresence (business)=20 * Digital living room (consumer) =09 It is a pretty safe guess that SIP PBX-style voice communications are = not the right model for these emerging scenarios. I guess even contact = centers for customer care may benefit from looking at the emerging Web = applications for communications and especially for sharing of documents = (having a URI).=20 Don't we often prefer to IM or email so as not to be tortured by IVR = Hell? And even for voice, just to be called back by an agent? =09 Now if we could only outlaw "automata" :-) =09 Henry =09 =09 On 7/7/09 8:03 AM, "Paul Kyzivat" wrote: =09 =09 Henry Sinnreich wrote: > Paul Kyzivat wrote: >>Past suggestions by various people to send control signals (intended > tobe acted upon >>by automata rather than >people) via IM have generally been >>rejected as inappropriate. > > I am not sure how many people expect a usage scenario for IM with an > automata in the middle or > what the deployment statistics are for such automata (I have never > encountered one).=20 > > All SIP (or other protocol ) Communicator packages have IM and the = URI > works there very nicely. > > Do you have any usage statistics that justifies the assertion = automata > are the > key usage scenario and "plain person to person" IM does not count? > > Henry =09 I don't know of one either. =09 But my observation is about using the IM message as a solution to the kinds of use cases that were presented in the draft, at least as I imagine them playing out. =09 My mental model is of an environment where a significant fraction of people have multimedia UAs, and an expectation that those various = media will be available in calls that they make. Now add to that people who have support for various media, but not in a single device. They then want to play in that same multimedia environment. =09 In such a case, using IMs between people, so that they may establish separate calls for various media is clearly the poor man's choice - better than nothing but not ideal. And its especially poor if the "initial" call is not an IM call. Then just establishing an IM channel between the same two people is non-trivial. =09 Thanks, Paul =09 =09 > On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: > > > > > Henry Sinnreich wrote: > > >We've looked at various approaches to solve this important > > >problem several times before > > > > Actually there is one more: IM-ing a URI to some resource, > mentioned by > > Henning Schulzrinne (I don't recall the document or = presentation). > > > > My two cents is that IM-ing a URL is the most general = solution, or > is it? > > Past suggestions by various people to send control signals = (intended to > be acted upon by automata rather than people) via IM have = generally been > rejected as inappropriate. (The exception so far has been file = transfer, > which has some control behavior and some expected human = interaction.) > > Now if you just want to say "Bob, please make a video call to > sip:alice_camera@alice.com in order to see me" then I guess IM = is ok. > But IMO its not otherwise good. Its just a hack. > > Thanks, > Paul > > > Henry > > > > > > On 7/6/09 12:07 PM, "Francois Audet" = wrote: > > > > I'm glad to see this topic coming back. > > > > I see that this draft doesn't propose a solution to = problem: > it list > > three options, and describes why they are not adequate. I > agree with > > the conclusions. > > > > We've looked at various approaches to solve this = important problem > > several times before: > > > > - Feature ref (refer to urn: indicating specific = features) > > = http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > > > - Remote control using REFER to requests & responses > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > > (Also, versions -04, -03,-02, -00) > > > > - Remore control using REFER with XML body describing = function > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > > > - Remote control using MBUS > > = http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > > = http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > > > On top of that there are various proprietary mechanisms, = and even > > some legacy > > PBX-CTI protocols. > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of = Salvatore > Loreto > > > Sent: Monday, July 06, 2009 09:33 > > > To: dispatch@ietf.org > > > Subject: [dispatch] Disaggregated Media in SIP > > > > > > Hi there, > > > > > > I have just submitted a draft that talks of = Disaggregated > > > Media in the Session Initiation Protocol (SIP). > > > = http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > > ggregated-media-00.txt > > > > > > > > > Abstract: > > > Disaggregated media refers to the ability for a user = to > create a > > > multimedia session combining different media streams, > coming from > > > different devices under his or her control, so that = they are > > > treated by > > > the far end of the session as a single media session. > > > This document lists several use cases that involve > > > disaggregated media > > > in SIP. > > > Additionally, this document analyzes what types of > > > disaggregated media > > > can be implemented using existing protocol > > > mechanisms, and the pros and cons of using each of = those > mechanisms. > > > Finally, this document describes scenarios that are = not > covered by > > > current mechanisms > > > and proposes new IETF work to cover them. > > > > > > > > > cheers > > > Sal > > > _______________________________________________ > > > 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 > =09 =09 ------_=_NextPart_001_01C9FF19.CA7393C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP
Correct.
 
I=20 agree with Henry. The bootstrap is typically the IM/Presence session, = not the=20 voice session. That would mean XMPP or SIMPLE.
 
To me=20 this is a different than the "multiple device" issue, but they are = quite=20 intertwinned.
 
A=20 scenario where you contact somebody using presence on a PC client or Web = Page,=20 or smart phone/PDA, perhaps IM, and then initiate a voice call using a = desktop=20 phone is a classic example.
 
In a=20 "loosely coupled" model, all that you'd need from the PC Client/Web = Page/Smart=20 Phone/PDA is:
  • The=20 ability to initiate the call using the alternate = device
  • The=20 ability to do basic control functions for the call using the primary = (rich UI)=20 interface, for that call on the alternate device:=20 answer/terminate/hold/etc.
 

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Tuesday, July 07, 2009=20 08:23
To: Paul Kyzivat
Cc: Audet, Francois = (SC100:3055);=20 Salvatore Loreto; dispatch@ietf.org
Subject: Re: [dispatch]=20 Disaggregated Media in SIP

Paul,

This is getting interesting, so = let=92s=20 see...

>In such a case, using IMs between people, so that = they may=20 establish
>separate calls for various media is clearly the poor = man's=20 choice -
>better than nothing but not ideal. And its especially = poor if=20 the "initial" call is not an IM call.
>Then just establishing = an IM=20 channel
>between the same two people is non-trivial.

No = matter=20 what type of communicator we use: SIP, Skype, Jabber, iChat, etc., = most=20 courteous people will first IM to ask if the other party can speak = right now=20 or later. While talking, they may also chose to add video. And if = planned,=20 also add desktop sharing.

So the natural order of = communications seems=20 to be mostly:
Presence (or the web conference URI), IM, voice, = video,=20 desktop sharing, conferencing, but certainly it all starts with a URI = for the=20 rendezvous function.

It seems we differ (or do we?) on three=20 points:
  1. Communicator =93calls=94 are not the poor = mans choice,=20
  2. It most often starts with presence and IM, =
  3. The URI (or Skype name) of the other party = in the=20 address book is all that=92s required. Or the social network as an = address=20 book.

Now leaving for a moment telephony = aside, let=92s=20 look at some new usage scenarios:
  • People in social networks (Twitter, = Facebook, etc.)=20
  • Telepresence (business)
  • Digital living room=20 (consumer)
It is=20 a pretty safe guess that SIP PBX-style voice communications are not = the right=20 model for these emerging scenarios. I guess even contact centers for = customer=20 care may benefit from looking at the emerging Web applications for=20 communications and especially for sharing of documents (having a URI). =
Don=92t we often prefer to IM or email so as not to be tortured by = IVR=20 Hell?
And even for voice, just to be called back by an = agent?

Now if=20 we could only outlaw =93automata=94 =   :-)

Henry


On=20 7/7/09 8:03 AM, "Paul Kyzivat" <pkyzivat@cisco.com>=20 wrote:
Henry Sinnreich wrote:
> Paul = Kyzivat=20 wrote:
>>Past suggestions by various people to send control = signals=20 (intended
> tobe acted upon
>>by automata rather than = >people) via IM have generally been
>>rejected as=20 inappropriate.
>
> I am not sure how many people expect = a usage=20 scenario for IM with an
> automata in the middle or
> = what the=20 deployment statistics are for such automata (I have never
>=20 encountered one).
>
> All SIP (or other protocol ) = Communicator=20 packages have IM and the URI
> works there very=20 nicely.
>
> Do you have any usage statistics that = justifies the=20 assertion automata
> are the
> key usage scenario and = =93plain=20 person to person=94 IM does not count?
>
> = Henry

I don't=20 know of one either.

But my observation is about using the IM = message=20 as a solution to the
kinds of use cases that were presented in = the draft,=20 at least as I
imagine them playing out.

My mental model is = of an=20 environment where a significant fraction of
people have = multimedia UAs,=20 and an expectation that those various media
will be available in = calls=20 that they make. Now add to that people who
have support for = various=20 media, but not in a single device. They then
want to play in that = same=20 multimedia environment.

In such a case, using IMs between = people, so=20 that they may establish
separate calls for various media is = clearly the=20 poor man's choice -
better than nothing but not ideal. And its = especially=20 poor if the
"initial" call is not an IM call. Then just = establishing an=20 IM channel
between the same two people is=20 = non-trivial.

        Thank= s,
        Paul


>= ;=20 On 7/6/09 3:43 PM, "Paul Kyzivat" <pkyzivat@cisco.com>=20 wrote:
>
>
>
>
> =     Henry=20 Sinnreich wrote:
>     > >We've = looked at=20 various approaches to solve this important
>=20     > >problem several times = before
>=20     >
>     >=20  Actually there is one more: IM-ing a URI to some = resource,
>=20     mentioned by
> =     >=20  Henning Schulzrinne (I don=92t recall the document or=20 presentation).
>     >
>=20     >  My two cents is that IM-ing a URL = is the=20 most general solution, or
>     is=20 it?
>
>     Past suggestions by = various=20 people to send control signals (intended to
>=20     be acted upon by automata rather than = people) via IM=20 have generally been
>     rejected as=20 inappropriate. (The exception so far has been file transfer,
> =     which has some control behavior and some = expected=20 human interaction.)
>
>     Now if = you just=20 want to say "Bob, please make a video call to
>=20     sip:alice_camera@alice.com in order = to see me"=20 then I guess IM is ok.
>     But IMO its = not=20 otherwise good. Its just a hack.
>
>=20 =             T= hanks,
>=20 =             P= aul
>
>=20     >  Henry
>=20     >
> =     >
>=20     >  On 7/6/09 12:07 PM, "Francois = Audet"=20 <audet@nortel.com> = wrote:
>=20     >
>     >=20      I'm glad to see this topic coming=20 back.
>     >
>=20     >      I see = that this=20 draft doesn't propose a solution to problem:
>=20     it list
>     > =      three options, and describes why they = are not=20 adequate. I
>     agree with
>=20     >      the=20 conclusions.
>     >
>=20     >      We've = looked at=20 various approaches to solve this important problem
>=20     >      several = times=20 before:
>     >
>=20     >      - Feature = ref=20 (refer to urn: indicating specific features)
>=20     > =        ht= tp://tools.ietf.org/html/draft-audet-sipping-feature-ref-00
>=20     >
>     >=20      - Remote control using REFER to = requests &=20 responses
>     >=20        http://to= ols.ietf.org/html/draft-mahy-sip-remote-cc-05
>=20     >=20        (Also, versions -04, = -03,-02,=20 -00)
>     >
>=20     >      - Remore = control=20 using REFER with XML body describing function
>=20     > =        http://to= ols.ietf.org/html/draft-mahy-sip-remote-cc-01
>=20     >
>     >=20      - Remote control using MBUS
>=20     > =        ht= tp://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01=20 &
>     >=20        http://= tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01
>=20     >
>     >=20      On top of that there are various = proprietary=20 mechanisms, and even
>     >=20      some legacy
>=20     >      PBX-CTI=20 protocols.
>     >
>=20     >      >=20  -----Original Message-----
> =     >=20      >  From: dispatch-bounces@ietf.org
> =     >      > =  [mailto:dispatch-bounces@ietf.or= g]=20 On Behalf Of Salvatore
> =     Loreto
>=20     >      > =  Sent:=20 Monday, July 06, 2009 09:33
>     >=20      >  To: dispatch@ietf.org
>=20     >      >=20  Subject: [dispatch] Disaggregated Media in SIP
>=20     > =      >
>=20     >      > =  Hi=20 there,
>     >=20      >
> =     >=20      >  I have just submitted a = draft that=20 talks of Disaggregated
>     >=20      >  Media in the Session = Initiation=20 Protocol (SIP).
>     >=20      >  h= ttp://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa
>= =20     >=20      ggregated-media-00.txt
>=20     > =      >
>=20     > =      >
>=20     >      >=20  Abstract:
>     >=20      >  Disaggregated media refers = to the=20 ability for a user to
>     create = a
>=20     >      >=20  multimedia session combining different media streams,
>=20     coming from
> =     >=20      >  different devices under his = or her=20 control, so that they are
>     >=20      >  treated by
>=20     >      > =  the=20 far end of the session as a single media session.
>=20     >      > =  This=20 document lists several use cases that involve
>=20     >      >=20  disaggregated media
>     >=20      >  in SIP.
>=20     >      >=20  Additionally, this document analyzes what types of
>=20     >      >=20  disaggregated media
>     >=20      >  can be implemented using = existing=20 protocol
>     >=20      >  mechanisms, and the pros = and cons=20 of using each of those
> =     mechanisms.
>=20     >      >=20  Finally, this document describes scenarios that are = not
>=20     covered by
> =     >=20      >  current mechanisms
>=20     >      > =  and=20 proposes new IETF work to cover them.
> =     >=20      >
> =     >=20      >
> =     >=20      >  cheers
>=20     >      >=20  Sal
>     >=20      >=20  _______________________________________________
>=20     >      >=20  dispatch mailing list
>     >=20      >  dispatch@ietf.org
>=20     >      > =  https://www.ietf.= org/mailman/listinfo/dispatch
>=20     > =      >
>=20     >=20 =      ___________________________________________= ____
>=20     >      dispatch = mailing=20 list
>     > =      dispatch@ietf.org
>=20     >      https://www.ietf.= org/mailman/listinfo/dispatch
>=20     >
> =     >
>=20     >
>=20 =     -------------------------------------------------= -----------------------
>=20     >
>     >=20  _______________________________________________
>=20     >  dispatch mailing list
>=20     >  dispatch@ietf.org
>=20     >  https://www.ietf.= org/mailman/listinfo/dispatch
>

------_=_NextPart_001_01C9FF19.CA7393C0-- From pkyzivat@cisco.com Tue Jul 7 08:47:25 2009 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 CB6A93A6E42 for ; Tue, 7 Jul 2009 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 030Bm8TtQYRh for ; Tue, 7 Jul 2009 08:47:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AEC343A6977 for ; Tue, 7 Jul 2009 08:47:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="49639568" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2009 15:47:05 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n67Fl5i4016286; Tue, 7 Jul 2009 11:47:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n67Fl5tH029198; Tue, 7 Jul 2009 15:47:05 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 11:47:05 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 11:47:04 -0400 Message-ID: <4A536DF9.4020906@cisco.com> Date: Tue, 07 Jul 2009 11:47:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 15:47:04.0964 (UTC) FILETIME=[2D37E440:01C9FF1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1975; t=1246981625; x=1247845625; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Francois=20Audet=20; bh=V7PW6qRVPy4myTyUI9QRVA7W6Byi9xOGK7hp1p5Ywts=; b=i9QLHdkB6Z884p/tknULBcUcnGOgkmzQMUsLwsfJxiO8S5HcQyEK1wZCSN c5SLnTFDXzlbA1s5tUeafK18MTKSJUzUNvvII780kZ3itIRpUPTgmiZvIhM7 +wB9j4TwNg; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 15:47:25 -0000 Francois Audet wrote: >> I still remain unconvinced that it is either necessary or >> appropriate for one end of a call to be involved in how the >> other end aggregates media resources for the call. > > I don't understand what this statement means. > > Everybody now has multiple devices these days. > > With the amount of implementations of Remote Call Control > using various proprietary mechanisms out there, it is pretty > clear that there is a need for this type of functionality. > > That does not necessarily means that one end is necessarily involved > in how "the other end aggregates media resources". In my mind, it's > more of how do you share the session, and partition the media streams. My point is that between caller and callee there should be one sip session, with as many media streams as the two ends want to share. If you stick to that principle, then features such as various forms of transfer, conferencing, answering automata, etc. can all work is the same manner as they do when there is really only a single device. If one, or both, ends needs to aggregate multiple devices to assemble its end of those media streams, then that is its problem, not a problem for the other end. IMO, to a first level of approximation, 3pcc is sufficient to do that on one end when the devices contributing media support are sip devices. Certainly there is more that can be done to make that nicer, easier to use, etc. I'm uncertain if there is a need for standardization of that. There may be some cases when I want to aggregate multiple devices of yours in order to provide you with a virtual multimedia device that I can then communicate with. But even then I would just view that as my setting up something separate for you in lieu of your doing it for yourself. I wouldn't view it as the normal course of events. Not one of Sal's use cases called for that. Thanks, Paul Thanks, Paul From AUDET@nortel.com Tue Jul 7 08:58:36 2009 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 85A883A6957 for ; Tue, 7 Jul 2009 08:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 fFWEpOguw-BU for ; Tue, 7 Jul 2009 08:58:35 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 806E43A67A8 for ; Tue, 7 Jul 2009 08:58:35 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n67FtG103975; Tue, 7 Jul 2009 15:55:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 10:56:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A536DF9.4020906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn/GjMFzhO7tyJSSOOcgSRcUDaeMQAAMZyA References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 15:58:36 -0000 =20 > My point is that between caller and callee there should be=20 > one sip session, with as many media streams as the two ends=20 > want to share. If you stick to that principle, then features=20 > such as various forms of transfer, conferencing, answering=20 > automata, etc. can all work is the same manner as they do=20 > when there is really only a single device. I think that's OK for some scenarios (as per my previous email), and low-level remote speaker/microphone/camera techniques may work. But I don't believe it is sufficient. In some cases, the complete opposite may be more appropriate, i.e., where both devices are bona fides SIP UAs with very "loosely coupled" interactions between them. That allows you to do things like take IM on one device and voice on the other. Or initiate a call on one on behalf of the other, and so forth. But I agree with you that this must be done in a way that is transparent to the other side.=20 > If one, or both, ends needs to aggregate multiple devices to=20 > assemble its end of those media streams, then that is its=20 > problem, not a problem for the other end. >=20 > IMO, to a first level of approximation, 3pcc is sufficient to=20 > do that on one end when the devices contributing media=20 > support are sip devices.=20 > Certainly there is more that can be done to make that nicer,=20 > easier to use, etc. I'm uncertain if there is a need for=20 > standardization of that. >=20 > There may be some cases when I want to aggregate multiple=20 > devices of yours in order to provide you with a virtual=20 > multimedia device that I can then communicate with. But even=20 > then I would just view that as my setting up something=20 > separate for you in lieu of your doing it for yourself. I=20 > wouldn't view it as the normal course of events. Not one of=20 > Sal's use cases called for that. >=20 > Thanks, > Paul >=20 > Thanks, > Paul >=20 From spromano@unina.it Tue Jul 7 09:04:45 2009 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 EFF2628C4CC for ; Tue, 7 Jul 2009 09:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.677 X-Spam-Level: X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] 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 i91srrA7nEqV for ; Tue, 7 Jul 2009 09:04:43 -0700 (PDT) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 83DF528C4C3 for ; Tue, 7 Jul 2009 09:04:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id n67ForDW007391; Tue, 7 Jul 2009 17:50:53 +0200 Received: from 143.225.229.187 ([143.225.229.187]) by webmail.unina.it (Horde MIME library) with HTTP; Tue, 07 Jul 2009 17:50:53 +0200 Message-ID: <20090707175053.xfyie2yocg48o0ok@webmail.unina.it> Date: Tue, 07 Jul 2009 17:50:53 +0200 From: spromano@unina.it To: "Jain, Rajnish" References: <4A3F03F6.6060505@alcatel-lucent.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/9540/Tue Jul 7 12:52:52 2009 on webmail.unina.it X-Virus-Status: Clean Cc: "dispatch@ietf.org" , Vijay Gurbani Subject: Re: [dispatch] Session Recording in SIP 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, 07 Jul 2009 16:04:45 -0000 Dear all, please also have a look at the following draft, which has been =20 sumbitted yesterday: Filename: draft-romano-dcon-recording Revision: 00 Title: Session Recording for Conferences using SMIL Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 24 Abstract: This document deals with session recording, specifically for what concerns recording of multimedia conferences, both centralized and distributed. Each involved media is recorded separately, and is then properly tagged. A SMIL [W3C.CR-SMIL3-20080115] metadata is used to put all the separate recordings together and handle their synchronization, as well as the possibly asynchronous opening and closure of media within the context of a conference. This SMIL metadata can subsequently be used by an interested user by means of a compliant player in order to passively receive a playout of the whole multimedia conference session. The motivation for this document comes from our experience with our conferencing framework, Meetecho, for which we implemented a recording functionality. Cheers, Simon Quoting "Jain, Rajnish" : > All: The following draft on SIP session recording requirements was =20 > submitted today: > > http://www.ietf.org/internet-drafts/draft-jain-dispatch-session-recording-= protocol-req-00.txt > > Title: Requirements for Session Recording Protocol (SRP) > > Abstract: > Session recording is a critical requirement in many business > communications environments such as call centers and financial > trading floors. In some of these environments, all calls must be > recorded for regulatory and compliance reasons. In others, calls may > be recorded for quality control or business analytics. Recording is > typically done by sending a copy of the media to the recording > devices. This document specifies requirements for a protocol that > will manage delivery of media from an end-point that originates media > or that has access to it to a recording device. This protocol is > being referred to as Session Recording Protocol and will most likely > be based on SIP. > > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf >> Of Vijay Gurbani >> Sent: Monday, June 22, 2009 12:09 AM >> To: dispatch@ietf.org >> Subject: [dispatch] Summary on Session Recording in SIP >> >> All: Here is the summary of the Session Recording thread from June 9 >> to June 19, 2009. If I misrepresented anything, please let me know. >> >> There was a fair amount of discussion on where to conduct this >> work. In the end, it was decided to continue discussions on >> dispatch, further decisions what to do -- new working group or >> put this work in an existing working group -- will be decided >> later. Regardless of where the work is done, opinions were >> expressed that the work is important that it should commence >> in the IETF. >> >> Need to be crisp about the purpose of this work: is it that users >> record sessions to hear later, or sessions need to be recorded >> because of some business needs? Or both? Is SRTP covered or >> only RTP? >> >> Solutions should cover: >> Always on recording >> Recording on demand >> Required recording >> Pause and resume recording >> Playback facilities and how they interact with recording >> Recording formats and protocols for controlling the stored recording. >> >> A lot of discussion ensued on the specific architecture or >> architectures that would be possible. No decision was reached on >> which specific architecture is good or bad, although various opinions >> were expressed in support for each. >> >> There are essentially four architectures to realize recording >> services: two that discuss where the media stream is forked >> out to the recorder -- at the UA or in a middlebox of some >> sort are outlined here: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html >> >> The third architecture has both UAs sending media to a >> recorder. See: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html >> >> A fourth architecture that is a superset of the third one is at: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://ect.bell-labs.com/who/vkg >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > DISCLAIMER: This e-mail may contain information that is =20 > confidential, privileged or otherwise protected from disclosure. If =20 > you are not an intended recipient of this e-mail, do not duplicate =20 > or redistribute it by any means. Please delete it and any =20 > attachments and notify the sender that you have received it in =20 > error. Unintended recipients are prohibited from taking action on =20 > the basis of information in this e-mail.E-mail messages may contain =20 > computer viruses or other defects, may not be accurately replicated =20 > on other systems, or may be intercepted, deleted or interfered with =20 > without the knowledge of the sender or the intended recipient. If =20 > you are not comfortable with the risks associated with e-mail =20 > messages, you may decide not to use e-mail to communicate with IPC. =20 > IPC reserves the right, to the extent and under circumstances =20 > permitted by applicable law, to retain, monitor and intercept e-mail =20 > messages to and from its systems. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From pkyzivat@cisco.com Tue Jul 7 09:15:37 2009 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 7BE7C28C4DC for ; Tue, 7 Jul 2009 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 llSgf839j4i7 for ; Tue, 7 Jul 2009 09:15:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 98B883A67A8 for ; Tue, 7 Jul 2009 09:15:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="183592460" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2009 16:15:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n67GF1Q2004678; Tue, 7 Jul 2009 09:15:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n67GExJf023704; Tue, 7 Jul 2009 16:15:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 12:15:00 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 12:15:00 -0400 Message-ID: <4A537488.8010403@cisco.com> Date: Tue, 07 Jul 2009 12:15:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jul 2009 16:15:00.0523 (UTC) FILETIME=[13EDE7B0:01C9FF1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12410; t=1246983301; x=1247847301; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20; bh=aT2K2gSI5GeiUkyiKSxWt+Fyruc57eqeF30gktNV978=; b=Mew7KFUX2xR4B3q8AAdKo6wA+bHeG05GsTn2JY+QdmaEwDhd4k/3oLasma P9kyrS6vQoZleurjzmo5leA6itMcaK5by7VHuvBKhdbNs0WI3d+taIsj07gp oXV8wFEAgI5OKVV5xT37+pDvEk1zYYOdBnbLQY91QfpmJbcq+nJRg=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 16:15:37 -0000 Henry Sinnreich wrote: > Paul, > > This is getting interesting, so let’s see... > >>In such a case, using IMs between people, so that they may establish >>separate calls for various media is clearly the poor man's choice - >>better than nothing but not ideal. And its especially poor if the > "initial" call is not an IM call. >>Then just establishing an IM channel >>between the same two people is non-trivial. > > No matter what type of communicator we use: SIP, Skype, Jabber, iChat, > etc., most courteous people will first IM to ask if the other party can > speak right now or later. While talking, they may also chose to add > video. And if planned, also add desktop sharing. I don't think that most people consider that to be required of courteous people. AFAIK most people with cell phones don't send an SMS first to ask "can I call you?" I think this is more a matter of differences in opinion about what the preferred medium of communication is. For some people it is definitely voice, for others IM or email. So people who consider IM their preferred mode of conversation may well IM first and then "escalate to voice" if that seems justified. I do that. And currently it often involves IMing a phone number. But I would much rather simply have an "add voice" button on my IM client. I think we are just starting to get to the point where multimedia communication is common enough that we need to develop an etiquette for using it: - how do we indicate and enforce our preferences of media? - is it polite to request to receive video without offering to send it? - is it ok to initiate addition of another medium to a call without first negotiating its use person to person via the existing media? > So the natural order of communications seems to be mostly: > Presence (or the web conference URI), IM, voice, video, desktop sharing, > conferencing, but certainly it all starts with a URI for the rendezvous > function. I think that is just *your* natural order. (And probably mine too.) But not for the world at large. For many the natural order is: voice, then SMS if the voice doesn't work. As long as people endeavor to have one URI that works for all the media they support, then that is indeed the starting point. > It seems we differ (or do we?) on three points: > > 1. Communicator “calls” are not the poor mans choice, > 2. It most often starts with presence and IM, > 3. The URI (or Skype name) of the other party in the address book is > all that’s required. Or the social network as an address book. I've answered above. IMO there is no one answer to this. If everyone had presence on every communication device they use, then it would likely be a starting point when it provided useful info. But note that I am unlikely to ever have presence data about all the people I want to communicate with. > Now leaving for a moment telephony aside, let’s look at some new usage > scenarios: > > * People in social networks (Twitter, Facebook, etc.) > * Telepresence (business) > * Digital living room (consumer) > > It is a pretty safe guess that SIP PBX-style voice communications are > not the right model for these emerging scenarios. I guess even contact > centers for customer care may benefit from looking at the emerging Web > applications for communications and especially for sharing of documents > (having a URI). > Don’t we often prefer to IM or email so as not to be tortured by IVR Hell? > And even for voice, just to be called back by an agent? As I noted earlier, we are in the very early stages of this because of the diversity of devices with varying capabilities. There currently is no least common denominator that is shared by all. The closest to one is probably still voice. And we still haven't converged the address spaces for these things. So its all very cumbersome. I agree with you that there is a lot of room for progress in this space. > Now if we could only outlaw “automata” :-) You can outlaw them for yourself. Personally I *like* automata that do useful services for me. Of note I very much like the automaton that answers voice calls, takes voice messages, and sends me an email with a text translation of the voice as well as the recorded audio. The key is that it is an automaton that I have chosen to act as an agent on my behalf. Maybe you don't want to talk to my automaton. That is fine. If you'd rather send me an email in the first place, that's fine too. Thanks, Paul > Henry > > > On 7/7/09 8:03 AM, "Paul Kyzivat" wrote: > > Henry Sinnreich wrote: > > Paul Kyzivat wrote: > > >Past suggestions by various people to send control signals (intended > > tobe acted upon > > >by automata rather than >people) via IM have generally been > > >rejected as inappropriate. > > > > I am not sure how many people expect a usage scenario for IM with an > > automata in the middle or > > what the deployment statistics are for such automata (I have never > > encountered one). > > > > All SIP (or other protocol ) Communicator packages have IM and the URI > > works there very nicely. > > > > Do you have any usage statistics that justifies the assertion automata > > are the > > key usage scenario and “plain person to person” IM does not count? > > > > Henry > > I don't know of one either. > > But my observation is about using the IM message as a solution to the > kinds of use cases that were presented in the draft, at least as I > imagine them playing out. > > My mental model is of an environment where a significant fraction of > people have multimedia UAs, and an expectation that those various media > will be available in calls that they make. Now add to that people who > have support for various media, but not in a single device. They then > want to play in that same multimedia environment. > > In such a case, using IMs between people, so that they may establish > separate calls for various media is clearly the poor man's choice - > better than nothing but not ideal. And its especially poor if the > "initial" call is not an IM call. Then just establishing an IM channel > between the same two people is non-trivial. > > Thanks, > Paul > > > > On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: > > > > > > > > > > Henry Sinnreich wrote: > > > >We've looked at various approaches to solve this important > > > >problem several times before > > > > > > Actually there is one more: IM-ing a URI to some resource, > > mentioned by > > > Henning Schulzrinne (I don’t recall the document or > presentation). > > > > > > My two cents is that IM-ing a URL is the most general > solution, or > > is it? > > > > Past suggestions by various people to send control signals > (intended to > > be acted upon by automata rather than people) via IM have > generally been > > rejected as inappropriate. (The exception so far has been file > transfer, > > which has some control behavior and some expected human > interaction.) > > > > Now if you just want to say "Bob, please make a video call to > > sip:alice_camera@alice.com in order to see me" then I guess IM > is ok. > > But IMO its not otherwise good. Its just a hack. > > > > Thanks, > > Paul > > > > > Henry > > > > > > > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > > > > > I'm glad to see this topic coming back. > > > > > > I see that this draft doesn't propose a solution to > problem: > > it list > > > three options, and describes why they are not adequate. I > > agree with > > > the conclusions. > > > > > > We've looked at various approaches to solve this > important problem > > > several times before: > > > > > > - Feature ref (refer to urn: indicating specific features) > > > > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > > > > > - Remote control using REFER to requests & responses > > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > > > (Also, versions -04, -03,-02, -00) > > > > > > - Remore control using REFER with XML body describing > function > > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > > > > > - Remote control using MBUS > > > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > > > > > On top of that there are various proprietary > mechanisms, and even > > > some legacy > > > PBX-CTI protocols. > > > > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of > Salvatore > > Loreto > > > > Sent: Monday, July 06, 2009 09:33 > > > > To: dispatch@ietf.org > > > > Subject: [dispatch] Disaggregated Media in SIP > > > > > > > > Hi there, > > > > > > > > I have just submitted a draft that talks of > Disaggregated > > > > Media in the Session Initiation Protocol (SIP). > > > > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > > > ggregated-media-00.txt > > > > > > > > > > > > Abstract: > > > > Disaggregated media refers to the ability for a user to > > create a > > > > multimedia session combining different media streams, > > coming from > > > > different devices under his or her control, so that > they are > > > > treated by > > > > the far end of the session as a single media session. > > > > This document lists several use cases that involve > > > > disaggregated media > > > > in SIP. > > > > Additionally, this document analyzes what types of > > > > disaggregated media > > > > can be implemented using existing protocol > > > > mechanisms, and the pros and cons of using each of those > > mechanisms. > > > > Finally, this document describes scenarios that are not > > covered by > > > > current mechanisms > > > > and proposes new IETF work to cover them. > > > > > > > > > > > > cheers > > > > Sal > > > > _______________________________________________ > > > > 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 AUDET@nortel.com Tue Jul 7 09:31:46 2009 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 A154128C501 for ; Tue, 7 Jul 2009 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 YevWEAvXnTLT for ; Tue, 7 Jul 2009 09:31:45 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DC51E28C4EF for ; Tue, 7 Jul 2009 09:31:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n67FqCl01815; Tue, 7 Jul 2009 15:52:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 10:51:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91E6B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn+em+0BaLXNsLrTai84REw9nbCHwAHsoYnAABrlGAAAKd/zQAeV9IQ References: <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Henry Sinnreich" , "Paul Kyzivat" Cc: dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 16:31:46 -0000 You asked for real-life data. I've seen many ways to achieve this type of "remote call control" = functionality: 1 - Proprietary Master/Slave protocols This is similar to H.248, but proprietary. Specifically, when in=20 "remote control mode", the device (e.g.., a phone) sees the UA=20 (e.g. a PC client) as it's "PBX". In this mode, the Phone is not=20 a SIP UA anymore in control mode. When control is relinquished,=20 Phone re-SIPifies itself. 2 - CTI-like protocols Things like ECMA TR-87 (CSTA tunnelled over SIP). The two devices = remain SIP UAs at all time, and attempt to "coordinate" their state. 3 - Layer 1/2 integration The device on the LAN is seen as a peripheral (i.e., remote speaker/ microphone/camera) to the device (e.g., PC) controlling it, when in control mode. Typically, this is USB or Bluetooth, or some emulation over Ethernet. Like number 1, the Phone is not a SIP UA anymore in=20 control mode. When control is relinquished, Phone re-SIPifies itself.=20 4 - SIP extensions/B2BUA You can do a lot directly with SIP, if you have a B2BUA, but it is non-trivial. Number 3, and we don't need to standardized anything at IETF for this. I do not think that it is adequate for all applications, and a much more = loosely coupled mechanism is what we would need for those applications. And by "loosely coupled", I really mean it: not media control. More like session sharing, where each UA ultimately retains control over their own = destiny. Something akin to Feature Referal. It could be based on presence or = other=20 mechanisms. ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 06, 2009 17:55 To: Audet, Francois (SC100:3055); Paul Kyzivat Cc: Salvatore Loreto; dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP =09 =09 Francois Audet wrote: >spec and all of us in the Enterprise space have been trying to do for = years. =09 Now this makes sense.=20 But still, can you share some data of its real life usage, as compared = to what is out today in various SIP Communicators? That would rule our = the person-to-person IM scenarios? =09 >I don't think "other protocols" is a good answer: it has to be = routable just like SIP. This again makes sense to me. (neglecting the facts about Jabber IM [such as in the IETF], Skype, = etc.) =09 Henry =09 =09 On 7/6/09 7:41 PM, "Francois Audet" wrote: =09 =09 I think what Paul calls automata is the application on the IM client, = so that would undermine what this spec and all of us in the Enterprise = space have been trying to do for years. =09 I will note that the "istyping" indication is already done today with = MESSAGE. And the istyping indicator is certainly an automata. And that = is an RFC today, and is widly deployed. =09 I personally don't really care if its a MESSAGE, a REFER, or an INFO = (although we certainly can rule out MBUS). Or a new message. =09 I don't think "other protocols" is a good answer: it has to be = routable just like SIP. =09 =09 =09 =20 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 06, 2009 17:24 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); Salvatore Loreto; = dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP =09 =20 Paul Kyzivat wrote: >Past suggestions by various people to send control signals = (intended tobe acted upon=20 >by automata rather than >people) via IM have generally been >rejected as inappropriate.=20 =09 I am not sure how many people expect a usage scenario for IM with an = automata in the middle or=20 what the deployment statistics are for such automata (I have never = encountered one). =20 =09 All SIP (or other protocol ) Communicator packages have IM and the = URI works there very nicely. =09 Do you have any usage statistics that justifies the assertion = automata are the=20 key usage scenario and "plain person to person" IM does not count? =09 Henry =09 =09 On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: =09 =20 =09 =09 =09 =09 Henry Sinnreich wrote: >>We've looked at various approaches to solve this important >>problem several times before > > Actually there is one more: IM-ing a URI to some resource, = mentioned by > Henning Schulzrinne (I don't recall the document or = presentation). > > My two cents is that IM-ing a URL is the most general solution, = or is it? =09 Past suggestions by various people to send control signals = (intended to be acted upon by automata rather than people) via IM have generally = been rejected as inappropriate. (The exception so far has been file = transfer, which has some control behavior and some expected human = interaction.) =09 Now if you just want to say "Bob, please make a video call to sip:alice_camera@alice.com in order to see me" then I guess IM is = ok. But IMO its not otherwise good. Its just a hack. =09 Thanks, Paul =09 > Henry > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > I'm glad to see this topic coming back. > > I see that this draft doesn't propose a solution to problem: = it list > three options, and describes why they are not adequate. I = agree with > the conclusions. > > We've looked at various approaches to solve this important = problem > several times before: > > - Feature ref (refer to urn: indicating specific features) > = http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00 > > - Remote control using REFER to requests & responses > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > (Also, versions -04, -03,-02, -00) > > - Remore control using REFER with XML body describing = function > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > - Remote control using MBUS > = http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 & > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > On top of that there are various proprietary mechanisms, and = even > some legacy > PBX-CTI protocols. > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore = Loreto > > Sent: Monday, July 06, 2009 09:33 > > To: dispatch@ietf.org > > Subject: [dispatch] Disaggregated Media in SIP > > > > Hi there, > > > > I have just submitted a draft that talks of Disaggregated > > Media in the Session Initiation Protocol (SIP). > > = http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > ggregated-media-00.txt > > > > > > Abstract: > > Disaggregated media refers to the ability for a user to = create a > > multimedia session combining different media streams, = coming from > > different devices under his or her control, so that they = are > > treated by > > the far end of the session as a single media session. > > This document lists several use cases that involve > > disaggregated media > > in SIP. > > Additionally, this document analyzes what types of > > disaggregated media > > can be implemented using existing protocol > > mechanisms, and the pros and cons of using each of those = mechanisms. > > Finally, this document describes scenarios that are not = covered by > > current mechanisms > > and proposes new IETF work to cover them. > > > > > > cheers > > Sal > > _______________________________________________ > > 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 =09 =09 =09 =09 From pkyzivat@cisco.com Tue Jul 7 09:44:14 2009 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 60EBE28C4DE for ; Tue, 7 Jul 2009 09:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 QUqdvt46nE7z for ; Tue, 7 Jul 2009 09:44:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2997F28C4E4 for ; Tue, 7 Jul 2009 09:44:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="49598751" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2009 16:44:25 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n67GiPq5017338; Tue, 7 Jul 2009 12:44:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n67GiPPr006432; Tue, 7 Jul 2009 16:44:25 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 12:44:25 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 12:44:24 -0400 Message-ID: <4A537B66.4000608@cisco.com> Date: Tue, 07 Jul 2009 12:44:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 16:44:24.0600 (UTC) FILETIME=[2F66B180:01C9FF22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2704; t=1246985065; x=1247849065; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Francois=20Audet=20; bh=Mt9KRE1aG0GCYoivO98Y/5d2nwxUqXJLQKXvlj2axME=; b=UHVxFz2NBJg1/UEIaiZCQNGC1mLyma+7K8UCKh0VDMMpRQHJXepjHnDBC6 sFFBcFN+21gHy0NFM+PUkyS9BsbzTUZZWrYXSpKLBL5POrfjd9fULGeIOlnc 3WywcMLFZh; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 16:44:14 -0000 Francois Audet wrote: > >> My point is that between caller and callee there should be >> one sip session, with as many media streams as the two ends >> want to share. If you stick to that principle, then features >> such as various forms of transfer, conferencing, answering >> automata, etc. can all work is the same manner as they do >> when there is really only a single device. > > I think that's OK for some scenarios (as per my previous email), > and low-level remote speaker/microphone/camera techniques may work. > > But I don't believe it is sufficient. > > In some cases, the complete opposite may be more appropriate, i.e., > where both devices are bona fides SIP UAs with very "loosely coupled" > interactions between them. > > That allows you to do things like take IM on one device and > voice on the other. Or initiate a call on one on behalf of the > other, and so forth. > > But I agree with you that this must be done in a way that is > transparent to the other side. We aren't communicating very well. I can't piece together the things you say above into a coherent whole. But apparently we agree on the key point - that this should be invisible to the other "side". Maybe we should just start there, since I don't think Sal agrees with that. At least his draft, and its predecessors, don't. If we can agree that one communication session between two parties has one sip session *between them*, then we can work on what the architecture should be like at each end. Of course you are still free to make multiple concurrent "calls" between the same two parties. But if you do, they are unrelated, except perhaps in your head. Thanks, Paul >> If one, or both, ends needs to aggregate multiple devices to >> assemble its end of those media streams, then that is its >> problem, not a problem for the other end. >> >> IMO, to a first level of approximation, 3pcc is sufficient to >> do that on one end when the devices contributing media >> support are sip devices. >> Certainly there is more that can be done to make that nicer, >> easier to use, etc. I'm uncertain if there is a need for >> standardization of that. >> >> There may be some cases when I want to aggregate multiple >> devices of yours in order to provide you with a virtual >> multimedia device that I can then communicate with. But even >> then I would just view that as my setting up something >> separate for you in lieu of your doing it for yourself. I >> wouldn't view it as the normal course of events. Not one of >> Sal's use cases called for that. >> >> Thanks, >> Paul >> >> Thanks, >> Paul >> > From hsinnrei@adobe.com Tue Jul 7 09:45:11 2009 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 4233C3A6E72 for ; Tue, 7 Jul 2009 09:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.536, 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 wJfWOfN9BERR for ; Tue, 7 Jul 2009 09:45:01 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id 65EDA28C2AC for ; Tue, 7 Jul 2009 09:45:00 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKSlN7phsu9NdoOTn46tAxClwxT2zfid8r@postini.com; Tue, 07 Jul 2009 09:45:27 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n67FNWWG004787; Tue, 7 Jul 2009 08:23:33 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n67FN7YC020214; Tue, 7 Jul 2009 08:23:31 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 7 Jul 2009 08:23:29 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Tue, 7 Jul 2009 08:23:29 -0700 From: Henry Sinnreich To: Paul Kyzivat Date: Tue, 7 Jul 2009 08:23:26 -0700 Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: Acn/A1Fz4xI92qwHQBmINfVm9yFUrAAE44Dc Message-ID: In-Reply-To: <4A53479B.70908@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C678D29E492Bhsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 16:45:11 -0000 --_000_C678D29E492Bhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, This is getting interesting, so let's see... >In such a case, using IMs between people, so that they may establish >separate calls for various media is clearly the poor man's choice - >better than nothing but not ideal. And its especially poor if the "initial= " call is not an IM call. >Then just establishing an IM channel >between the same two people is non-trivial. No matter what type of communicator we use: SIP, Skype, Jabber, iChat, etc.= , most courteous people will first IM to ask if the other party can speak r= ight now or later. While talking, they may also chose to add video. And if = planned, also add desktop sharing. So the natural order of communications seems to be mostly: Presence (or the web conference URI), IM, voice, video, desktop sharing, co= nferencing, but certainly it all starts with a URI for the rendezvous funct= ion. It seems we differ (or do we?) on three points: 1. Communicator "calls" are not the poor mans choice, 2. It most often starts with presence and IM, 3. The URI (or Skype name) of the other party in the address book is all = that's required. Or the social network as an address book. Now leaving for a moment telephony aside, let's look at some new usage scen= arios: * People in social networks (Twitter, Facebook, etc.) * Telepresence (business) * Digital living room (consumer) It is a pretty safe guess that SIP PBX-style voice communications are not t= he right model for these emerging scenarios. I guess even contact centers f= or customer care may benefit from looking at the emerging Web applications = for communications and especially for sharing of documents (having a URI). Don't we often prefer to IM or email so as not to be tortured by IVR Hell? And even for voice, just to be called back by an agent? Now if we could only outlaw "automata" :-) Henry On 7/7/09 8:03 AM, "Paul Kyzivat" wrote: Henry Sinnreich wrote: > Paul Kyzivat wrote: >>Past suggestions by various people to send control signals (intended > tobe acted upon >>by automata rather than >people) via IM have generally been >>rejected as inappropriate. > > I am not sure how many people expect a usage scenario for IM with an > automata in the middle or > what the deployment statistics are for such automata (I have never > encountered one). > > All SIP (or other protocol ) Communicator packages have IM and the URI > works there very nicely. > > Do you have any usage statistics that justifies the assertion automata > are the > key usage scenario and "plain person to person" IM does not count? > > Henry I don't know of one either. But my observation is about using the IM message as a solution to the kinds of use cases that were presented in the draft, at least as I imagine them playing out. My mental model is of an environment where a significant fraction of people have multimedia UAs, and an expectation that those various media will be available in calls that they make. Now add to that people who have support for various media, but not in a single device. They then want to play in that same multimedia environment. In such a case, using IMs between people, so that they may establish separate calls for various media is clearly the poor man's choice - better than nothing but not ideal. And its especially poor if the "initial" call is not an IM call. Then just establishing an IM channel between the same two people is non-trivial. Thanks, Paul > On 7/6/09 3:43 PM, "Paul Kyzivat" wrote: > > > > > Henry Sinnreich wrote: > > >We've looked at various approaches to solve this important > > >problem several times before > > > > Actually there is one more: IM-ing a URI to some resource, > mentioned by > > Henning Schulzrinne (I don't recall the document or presentation). > > > > My two cents is that IM-ing a URL is the most general solution, or > is it? > > Past suggestions by various people to send control signals (intended = to > be acted upon by automata rather than people) via IM have generally b= een > rejected as inappropriate. (The exception so far has been file transf= er, > which has some control behavior and some expected human interaction.) > > Now if you just want to say "Bob, please make a video call to > sip:alice_camera@alice.com in order to see me" then I guess IM is ok. > But IMO its not otherwise good. Its just a hack. > > Thanks, > Paul > > > Henry > > > > > > On 7/6/09 12:07 PM, "Francois Audet" wrote: > > > > I'm glad to see this topic coming back. > > > > I see that this draft doesn't propose a solution to problem: > it list > > three options, and describes why they are not adequate. I > agree with > > the conclusions. > > > > We've looked at various approaches to solve this important pro= blem > > several times before: > > > > - Feature ref (refer to urn: indicating specific features) > > http://tools.ietf.org/html/draft-audet-sipping-feature-ref-0= 0 > > > > - Remote control using REFER to requests & responses > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05 > > (Also, versions -04, -03,-02, -00) > > > > - Remore control using REFER with XML body describing function > > http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01 > > > > - Remote control using MBUS > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-0= 1 & > > http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01 > > > > On top of that there are various proprietary mechanisms, and e= ven > > some legacy > > PBX-CTI protocols. > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore > Loreto > > > Sent: Monday, July 06, 2009 09:33 > > > To: dispatch@ietf.org > > > Subject: [dispatch] Disaggregated Media in SIP > > > > > > Hi there, > > > > > > I have just submitted a draft that talks of Disaggregated > > > Media in the Session Initiation Protocol (SIP). > > > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-d= isa > > ggregated-media-00.txt > > > > > > > > > Abstract: > > > Disaggregated media refers to the ability for a user to > create a > > > multimedia session combining different media streams, > coming from > > > different devices under his or her control, so that they ar= e > > > treated by > > > the far end of the session as a single media session. > > > This document lists several use cases that involve > > > disaggregated media > > > in SIP. > > > Additionally, this document analyzes what types of > > > disaggregated media > > > can be implemented using existing protocol > > > mechanisms, and the pros and cons of using each of those > mechanisms. > > > Finally, this document describes scenarios that are not > covered by > > > current mechanisms > > > and proposes new IETF work to cover them. > > > > > > > > > cheers > > > Sal > > > _______________________________________________ > > > 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 > --_000_C678D29E492Bhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Disaggregated Media in SIP Paul,

This is getting interesting, so let’s see...

>In such a case, using IMs between people, so that they may establish >separate calls for various media is clearly the poor man's choice -
>better than nothing but not ideal. And its especially poor if the "= ;initial" call is not an IM call.
>Then just establishing an IM channel
>between the same two people is non-trivial.

No matter what type of communicator we use: SIP, Skype, Jabber, iChat, etc.= , most courteous people will first IM to ask if the other party can speak r= ight now or later. While talking, they may also chose to add video. And if = planned, also add desktop sharing.

So the natural order of communications seems to be mostly:
Presence (or the web conference URI), IM, voice, video, desktop sharing, co= nferencing, but certainly it all starts with a URI for the rendezvous funct= ion.

It seems we differ (or do we?) on three points:
  1. Communicator “calls” are not the po= or mans choice,
  2. It most often starts with presence and IM,
  3. The URI (or Skype name) of the other party in the a= ddress book is all that’s required. Or the social network as an addre= ss book.

Now leaving for a moment telephony aside, let’s look at some new usag= e scenarios:
  • People in social networks (Twitter, Facebook, e= tc.)
  • Telepresence (business)
  • Digital living room (consumer)
It is a pretty safe guess that SIP PBX-style voice= communications are not the right model for these emerging scenarios. I gue= ss even contact centers for customer care may benefit from looking at the e= merging Web applications for communications and especially for sharing of d= ocuments (having a URI).
Don’t we often prefer to IM or email so as not to be tortured by IVR = Hell?
And even for voice, just to be called back by an agent?

Now if we could only outlaw “automata”   :-)

Henry


On 7/7/09 8:03 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

Henry Sinnreich wrote:
> Paul Kyzivat wrote:
>>Past suggestions by various people to send control signals (intende= d
> tobe acted upon
>>by automata rather than >people) via IM have generally been
>>rejected as inappropriate.
>
> I am not sure how many people expect a usage scenario for IM with an > automata in the middle or
> what the deployment statistics are for such automata (I have never
> encountered one).
>
> All SIP (or other protocol ) Communicator packages have IM and the URI=
> works there very nicely.
>
> Do you have any usage statistics that justifies the assertion automata=
> are the
> key usage scenario and “plain person to person” IM does no= t count?
>
> Henry

I don't know of one either.

But my observation is about using the IM message as a solution to the
kinds of use cases that were presented in the draft, at least as I
imagine them playing out.

My mental model is of an environment where a significant fraction of
people have multimedia UAs, and an expectation that those various media
will be available in calls that they make. Now add to that people who
have support for various media, but not in a single device. They then
want to play in that same multimedia environment.

In such a case, using IMs between people, so that they may establish
separate calls for various media is clearly the poor man's choice -
better than nothing but not ideal. And its especially poor if the
"initial" call is not an IM call. Then just establishing an IM ch= annel
between the same two people is non-trivial.

        Thanks,
        Paul


> On 7/6/09 3:43 PM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
>
>
>
>
>     Henry Sinnreich wrote:
>     > >We've looked at various approaches to= solve this important
>     > >problem several times before
>     >
>     >  Actually there is one more: IM-ing = a URI to some resource,
>     mentioned by
>     >  Henning Schulzrinne (I don’t = recall the document or presentation).
>     >
>     >  My two cents is that IM-ing a URL i= s the most general solution, or
>     is it?
>
>     Past suggestions by various people to send con= trol signals (intended to
>     be acted upon by automata rather than people) = via IM have generally been
>     rejected as inappropriate. (The exception so f= ar has been file transfer,
>     which has some control behavior and some expec= ted human interaction.)
>
>     Now if you just want to say "Bob, please = make a video call to
>     sip:alice_c= amera@alice.com in order to see me" then I guess IM is ok.
>     But IMO its not otherwise good. Its just a hac= k.
>
>            &nbs= p;Thanks,
>            &nbs= p;Paul
>
>     >  Henry
>     >
>     >
>     >  On 7/6/09 12:07 PM, "Francois = Audet" <audet@nortel.com> wrote= :
>     >
>     >      I'm glad to= see this topic coming back.
>     >
>     >      I see that = this draft doesn't propose a solution to problem:
>     it list
>     >      three optio= ns, and describes why they are not adequate. I
>     agree with
>     >      the conclus= ions.
>     >
>     >      We've looke= d at various approaches to solve this important problem
>     >      several tim= es before:
>     >
>     >      - Feature r= ef (refer to urn: indicating specific features)
>     >        = ;= http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00
>     >
>     >      - Remote co= ntrol using REFER to requests & responses
>     >        = ;http://= tools.ietf.org/html/draft-mahy-sip-remote-cc-05
>     >        = ;(Also, versions -04, -03,-02, -00)
>     >
>     >      - Remore co= ntrol using REFER with XML body describing function
>     >        = ;http://= tools.ietf.org/html/draft-mahy-sip-remote-cc-01
>     >
>     >      - Remote co= ntrol using MBUS
>     >        = ;= http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 &
>     >        = ;http:= //tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01
>     >
>     >      On top of t= hat there are various proprietary mechanisms, and even
>     >      some legacy=
>     >      PBX-CTI pro= tocols.
>     >
>     >      >  = -----Original Message-----
>     >      >  = From: dispatch-bounces@ietf.org >     >      >  = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Salvatore
>     Loreto
>     >      >  = Sent: Monday, July 06, 2009 09:33
>     >      >  = To: dispatch@ietf.org
>     >      >  = Subject: [dispatch] Disaggregated Media in SIP
>     >      >
>     >      >  = Hi there,
>     >      >
>     >      >  = I have just submitted a draft that talks of Disaggregated
>     >      >  = Media in the Session Initiation Protocol (SIP).
>     >      >  = = http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa
>     >      ggregated-m= edia-00.txt
>     >      >
>     >      >
>     >      >  = Abstract:
>     >      >  = Disaggregated media refers to the ability for a user to
>     create a
>     >      >  = multimedia session combining different media streams,
>     coming from
>     >      >  = different devices under his or her control, so that they are
>     >      >  = treated by
>     >      >  = the far end of the session as a single media session.
>     >      >  = This document lists several use cases that involve
>     >      >  = disaggregated media
>     >      >  = in SIP.
>     >      >  = Additionally, this document analyzes what types of
>     >      >  = disaggregated media
>     >      >  = can be implemented using existing protocol
>     >      >  = mechanisms, and the pros and cons of using each of those
>     mechanisms.
>     >      >  = Finally, this document describes scenarios that are not
>     covered by
>     >      >  = current mechanisms
>     >      >  = and proposes new IETF work to cover them.
>     >      >
>     >      >
>     >      >  = cheers
>     >      >  = Sal
>     >      >  = _______________________________________________
>     >      >  = dispatch mailing list
>     >      >  = dispatch@ietf.org
>     >      >  = https://www.ietf= .org/mailman/listinfo/dispatch
>     >      >
>     >      ___________= ____________________________________
>     >      dispatch ma= iling list
>     >      dispatch@ietf.org
>     >      https://www.ietf.org/mailma= n/listinfo/dispatch
>     >
>     >
>     >
>     ----------------------------------------------= --------------------------
>     >
>     >  ___________________________________= ____________
>     >  dispatch mailing list
>     >  dispa= tch@ietf.org
>     >  https://www.ietf.org/mailman/listinfo/dispatch<= BR> >

--_000_C678D29E492Bhsinnreiadobecom_-- From AUDET@nortel.com Tue Jul 7 10:49:15 2009 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 7D0443A6A55 for ; Tue, 7 Jul 2009 10:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 6ED0Vvgvg+dy for ; Tue, 7 Jul 2009 10:49:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5469128C4DC for ; Tue, 7 Jul 2009 10:49:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n67HlV122415; Tue, 7 Jul 2009 17:47:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 12:49:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EDE4E4E@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A537B66.4000608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: Acn/IjGo7O2yNeAPRmaql6qmawXmvQAB+TtQ References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 17:49:15 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, July 07, 2009 09:44 > To: Audet, Francois (SC100:3055) > Cc: Henry Sinnreich; Salvatore Loreto; dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP > > Of course you are still free to make multiple concurrent=20 > "calls" between the same two parties. But if you do, they are=20 > unrelated, except perhaps in your head. Actually, the "in your head" part is important. If it is "loosely coupled", then you don't need to do complex state = synchronization, because, as you say, it is "done in your head". If I have my PC client, and I click "Make call" or "Answer" or something = similar, it just needs to tell my Phone to do do so. That's what I mean by "loose coupling". The other guy on the other end sees your Phone in this case. For "Make call", it's just a SIP INVITE coming from the Phone. For "Answer", the INVITE from the guy gets forked, the PC client tells = the phone to send a 200.=20 We don't have to make this complicated. From pkyzivat@cisco.com Tue Jul 7 11:17:05 2009 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 CF70328C50C for ; Tue, 7 Jul 2009 11:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.562 X-Spam-Level: X-Spam-Status: No, score=-7.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 ZMSnVW0CG68D for ; Tue, 7 Jul 2009 11:17:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1ABBD28C509 for ; Tue, 7 Jul 2009 11:17:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="49607552" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2009 18:16:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n67IGQfO009883; Tue, 7 Jul 2009 14:16:26 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n67IGQE6013505; Tue, 7 Jul 2009 18:16:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 14:16:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 14:16:26 -0400 Message-ID: <4A5390FA.2020806@cisco.com> Date: Tue, 07 Jul 2009 14:16:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EDE4E4E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EDE4E4E@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 18:16:26.0323 (UTC) FILETIME=[0A9AC230:01C9FF2F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3758; t=1246990586; x=1247854586; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Francois=20Audet=20; bh=POm8SviyjcennlZTC/SdXvLsDJAZjH29itK9hOajCec=; b=mKbWg5InWgE9ogjMU9IheDumNH91uRQxTRAwasbxq5seJ/JgsKFjsDdntU PXO2hsJrOE8QZW0hHew4sacTsnseB5oBixla0qnhxhgRtgSNJ3mbFyb51NjV E3pNvHB5j0; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 07 Jul 2009 18:17:05 -0000 Inline Francois Audet wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, July 07, 2009 09:44 >> To: Audet, Francois (SC100:3055) >> Cc: Henry Sinnreich; Salvatore Loreto; dispatch@ietf.org >> Subject: Re: [dispatch] Disaggregated Media in SIP >> >> Of course you are still free to make multiple concurrent >> "calls" between the same two parties. But if you do, they are >> unrelated, except perhaps in your head. > > Actually, the "in your head" part is important. > > If it is "loosely coupled", then you don't need to do complex state synchronization, > because, as you say, it is "done in your head". > > If I have my PC client, and I click "Make call" or "Answer" or something similar, > it just needs to tell my Phone to do do so. > > That's what I mean by "loose coupling". > > The other guy on the other end sees your Phone in this case. > > For "Make call", it's just a SIP INVITE coming from the Phone. > > For "Answer", the INVITE from the guy gets forked, the PC client tells the > phone to send a 200. > > We don't have to make this complicated. Most of those examples aren't of multimedia at all - they are just remote control of a pt-pt call. And the "in your head" part also means that call control actions, such ans transfer, don't work on the collection - just on an individual one. And recordings won't know the association between them either. Nevertheless, I'm not opposed to such things. They all can have a place. To get anywhere on this I think we need to concentrate on some use cases. The ones in Sal's draft are a reasonable starting point. For instance: > 2.6. Answering a call using Two Separate Devices > > Laura has a PC with a softclient and a desk phone. Bob has an > integrated advanced multimedia phone with camera. > > Laura receives on her desk phone an incoming voice-video call from > Bob. > > Laura decides to answer the Bob's session invitation by establishing > a voice session with Bob using the desk phone and the video session > using her multimedia phone. Two SIP dialogs need to be established: > one between Bob's device and Laura's desk phone and one between Bob's > device and Laura's multimedia phone. > > Laura wants Bob to treat the audio stream from her deskphone and the > video stream from her softclient as part of the same communication > space. That is, Laura wants Bob to treat both streams as belonging > to the same multimedia session. To address this without bothering Bob, *something* on Laura's end must have the intelligence to coordinate this. And then there must be some communications to set it all up. - we might assume the desk phone, while media poor, is intelligent and can handle all the setup. This might be realistic in some cases, but probably not often. - or we might assume that the softphone on her desk is smart enough and has a rich enough UI, to handle this. I find that more likely. Assuming the latter, I can image it popping up a user dialog when it receives the INVITE, offering some options of how to handle the call. (Of course the desk phone is probably ringing too.) One of the options might be to recruit the desk phone for audio. So Laura might just need to click something to select the call setup that the use case describes. Then the softphone would answer the call. There would be some sort of signaling to incorporate the desk phone, but that would all be hidden from Bob. We can discuss what sorts of signaling would be good to accomplish this. (I think it sounds like an excellent task for BLISS.) Thanks, Paul From adam@nostrum.com Tue Jul 7 12:47:33 2009 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 473EB28C562 for ; Tue, 7 Jul 2009 12:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, SPF_PASS=-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 uARmwa6uZ9oB for ; Tue, 7 Jul 2009 12:47:32 -0700 (PDT) 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 090D128C554 for ; Tue, 7 Jul 2009 12:47:31 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n67JlkD1089099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2009 14:47:51 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A53A662.9060503@nostrum.com> Date: Tue, 07 Jul 2009 14:47:46 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: IETF Dispatch Content-Type: multipart/mixed; boundary="------------070506020001050304000406" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Tue, 07 Jul 2009 19:47:33 -0000 This is a multi-part message in MIME format. --------------070506020001050304000406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I've just submitted a new version of draft-roach-sip-http-subscribe, which addresses a couple of minor comments made regarding -01 [1]. I know there are use cases coming out of the BLISS working group that would benefit from such a mechanism. I suspect it has a potential community of interest beyond that single working group, which is why I'm bringing it to DISPATCH. I'm happy to keep working on the document as long as there is enough interest to make the work worthwhile. If we were to form a mailing list with the goal of making progress on this work, who would be interested in joining? /a [1] The only substantive change was in the third paragraph of section 2.2, which now requires the server to indicate which URIs are causing it to forbid a subscription. --------------070506020001050304000406 Content-Type: message/rfc822; name="New Version Notification for draft-roach-sip-http-subscribe-02.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-roach-sip-http-subscribe-"; filename*1="02.eml" Return-Path: Received: from nostrum.com ([unix socket]) by shaman.nostrum.com (Cyrus v2.3.14) with LMTPA; Tue, 07 Jul 2009 14:27:32 -0500 X-Sieve: CMU Sieve 2.3 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by nostrum.com (8.14.3/8.14.3) with ESMTP id n67JR9wD006337 for ; Tue, 7 Jul 2009 14:27:32 -0500 (CDT) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 2DD2C3A6E3C; Tue, 7 Jul 2009 12:26:36 -0700 (PDT) From: IETF I-D Submission Tool To: adam@nostrum.com Subject: New Version Notification for draft-roach-sip-http-subscribe-02 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090707192637.2DD2C3A6E3C@core3.amsl.com> Date: Tue, 7 Jul 2009 12:26:36 -0700 (PDT) Received-SPF: pass (nostrum.com: 64.170.98.32 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on shaman.nostrum.com A new version of I-D, draft-roach-sip-http-subscribe-02.txt has been successfuly submitted by Adam Roach and posted to the IETF repository. Filename: draft-roach-sip-http-subscribe Revision: 02 Title: A SIP Event Package for Subscribing to Changes to an HTTP Resource Creation_date: 2009-07-07 WG ID: Independent Submission Number_of_pages: 12 Abstract: The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. This document further proposes that the HTTP work necessary to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources. The IETF Secretariat. --------------070506020001050304000406-- From michael@voip.co.uk Tue Jul 7 14:33:12 2009 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 8C0403A68DC for ; Tue, 7 Jul 2009 14:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 tKXjh6e9ss9d for ; Tue, 7 Jul 2009 14:33:11 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 5461C3A683B for ; Tue, 7 Jul 2009 14:33:11 -0700 (PDT) Received: from source ([72.14.220.157]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKSlO+9KZMoh3WVeu4AdoHnp1VpRAklnKe@postini.com; Tue, 07 Jul 2009 14:33:38 PDT Received: by fg-out-1718.google.com with SMTP id e12so980787fga.17 for ; Tue, 07 Jul 2009 14:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.84.12 with SMTP id h12mr2522256fgb.21.1247002356375; Tue, 07 Jul 2009 14:32:36 -0700 (PDT) In-Reply-To: <4A53A662.9060503@nostrum.com> References: <4A53A662.9060503@nostrum.com> Date: Tue, 7 Jul 2009 22:32:36 +0100 Message-ID: From: Michael Procter To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Tue, 07 Jul 2009 21:33:12 -0000 2009/7/7 Adam Roach : > I'm happy to keep working on the document as long as there is enough > interest to make the work worthwhile. If we were to form a mailing list with > the goal of making progress on this work, who would be interested in > joining? > I'd be interested in joining. I think there are a number of interesting things that can be done with a package like this, and I would be happy to help it progress. This draft seems to be a fundamentally useful building block for making advanced applications, yet remains small enough in scope and application-agnostic to mean we should be able to achieve consensus relatively quickly. Michael From theo@crazygreek.co.uk Tue Jul 7 16:15:32 2009 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 E20C13A6921 for ; Tue, 7 Jul 2009 16:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7vakFgNe8qEP for ; Tue, 7 Jul 2009 16:15:32 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with SMTP id EB8A23A6A74 for ; Tue, 7 Jul 2009 16:15:26 -0700 (PDT) Received: from source ([72.14.220.158]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSlPXDHUCcFeXGShUZiHB+hMmK04hobZS@postini.com; Tue, 07 Jul 2009 16:15:54 PDT Received: by fg-out-1718.google.com with SMTP id 13so1584151fge.9 for ; Tue, 07 Jul 2009 16:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.31.14 with SMTP id e14mr2479345fge.79.1247008136062; Tue, 07 Jul 2009 16:08:56 -0700 (PDT) In-Reply-To: <4A53A662.9060503@nostrum.com> References: <4A53A662.9060503@nostrum.com> From: Theo Zourzouvillys Date: Wed, 8 Jul 2009 00:08:36 +0100 Message-ID: <167dfb9b0907071608v57e5b64agd803dfdbdaa86a0@mail.gmail.com> To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Tue, 07 Jul 2009 23:15:33 -0000 On Tue, Jul 7, 2009 at 8:47 PM, Adam Roach wrote: > I'm happy to keep working on the document as long as there is enough > interest to make the work worthwhile. If we were to form a mailing list with > the goal of making progress on this work, who would be interested in > joining? I would absolutely be interested, and really would like to see this work progress. ~ Theo From john.elwell@siemens-enterprise.com Wed Jul 8 02:11:51 2009 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 61C6528C3FB for ; Wed, 8 Jul 2009 02:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 CD5gliDjLqqi for ; Wed, 8 Jul 2009 02:11:50 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 52BEF28C1A7 for ; Wed, 8 Jul 2009 02:11:49 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMG0098EHKD2X@siemenscomms.co.uk> for dispatch@ietf.org; Wed, 08 Jul 2009 10:12:14 +0100 (BST) Date: Wed, 08 Jul 2009 10:12:04 +0100 From: "Elwell, John" In-reply-to: <4A522751.9010607@ericsson.com> To: Salvatore Loreto , dispatch@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0021DBF5F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: Acn+WALW92rFTDmGR1WtNzHEEzw5pgBTrQig Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A522751.9010607@ericsson.com> Subject: Re: [dispatch] Disaggregated Media in SIP 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, 08 Jul 2009 09:11:51 -0000 Sal, Thanks for writing this. The centralised approach is what I and some others have been suggesting over the past months. It is good to see a comparison between the centralised approach (in its various flavours) and the distributed approach that you have been advocating for some time. It seems the biggest issue for deciding whether or not to work on the distributed approach is whether there is a need for the "master" device (the one operating SIP) to drop out of the call, while allowing the call and certain media to continue at other devices.=20 I still have a concern that with the distributed approach the remote end of the call needs to exhibit special behaviour in order to handle the multiple dialogs arising from the distributed approach (as Paul also notes). So in practice, to make it work with any degree of reliability, calls will need to go through a B2BUA that provides the necessary aggregation. So it effectively ends up as a centralised approach anyway. The distributed approach (section 4) is not really described in enough detail. There still has to be some communication between Alice's UAs, e.g., to convey information to a UA to be added to the call to allow it to make a call to Bob and allow Bob to associate the new call with the existing call. Also if Alice wants to clear all calls (i.e., all components of the same call) with one button push, there needs to be some communication between the UAs. John John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: 06 July 2009 17:33 > To: dispatch@ietf.org > Subject: [dispatch] Disaggregated Media in SIP >=20 > Hi there, >=20 > I have just submitted a draft that talks of Disaggregated=20 > Media in the=20 > Session Initiation Protocol (SIP). > http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa > ggregated-media-00.txt >=20 >=20 > Abstract: > Disaggregated media refers to the ability for a user to create a=20 > multimedia session combining different media streams, coming from > different devices under his or her control, so that they are=20 > treated by=20 > the far end of the session as a single media session. > This document lists several use cases that involve=20 > disaggregated media=20 > in SIP. > Additionally, this document analyzes what types of=20 > disaggregated media=20 > can be implemented using existing protocol > mechanisms, and the pros and cons of using each of those mechanisms. > Finally, this document describes scenarios that are not covered by=20 > current mechanisms > and proposes new IETF work to cover them. >=20 >=20 > cheers > Sal > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From john.elwell@siemens-enterprise.com Thu Jul 9 00:14:33 2009 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 670A83A6911 for ; Thu, 9 Jul 2009 00:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 Rd40AMQHGpUf for ; Thu, 9 Jul 2009 00:14:32 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 046C128C173 for ; Thu, 9 Jul 2009 00:14:10 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMI00J0D6SAYI@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 09 Jul 2009 08:14:34 +0100 (BST) Date: Thu, 09 Jul 2009 08:14:32 +0100 From: "Elwell, John" In-reply-to: <4A53A662.9060503@nostrum.com> To: Adam Roach , IETF Dispatch Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0021DC3C7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-02] Thread-Index: Acn/PnG7DFCTArWsQo2qyUBfPqQQNwBJhJSw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A53A662.9060503@nostrum.com> Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-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: Thu, 09 Jul 2009 07:14:33 -0000 Adam, I am interested because of the existing BLISS use cases, but I am sure there will be other uses. It seems that having this event package available could save the effort of writing more specific SIP event packages in certain cases. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 07 July 2009 20:48 > To: IETF Dispatch > Subject: [dispatch] SIP HTTP Event Package [Fwd: New Version=20 > Notificationfor draft-roach-sip-http-subscribe-02] >=20 > I've just submitted a new version of draft-roach-sip-http-subscribe,=20 > which addresses a couple of minor comments made regarding -01 [1]. I=20 > know there are use cases coming out of the BLISS working group that=20 > would benefit from such a mechanism. I suspect it has a potential=20 > community of interest beyond that single working group, which=20 > is why I'm=20 > bringing it to DISPATCH. >=20 > I'm happy to keep working on the document as long as there is enough=20 > interest to make the work worthwhile. If we were to form a=20 > mailing list=20 > with the goal of making progress on this work, who would be=20 > interested=20 > in joining? >=20 > /a >=20 >=20 > [1] The only substantive change was in the third paragraph of section=20 > 2.2, which now requires the server to indicate which URIs are=20 > causing it=20 > to forbid a subscription. >=20 From john.elwell@siemens-enterprise.com Thu Jul 9 09:24:15 2009 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 9BDE628C1C7 for ; Thu, 9 Jul 2009 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 fZG0I3y9IOdV for ; Thu, 9 Jul 2009 09:24:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8841D3A6CE6 for ; Thu, 9 Jul 2009 09:23:33 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMI0068PW80Y7@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 09 Jul 2009 17:24:00 +0100 (BST) Date: Thu, 09 Jul 2009 17:23:59 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0907060410jd5389f5q81f28279984c8615@mail.gmail.com> To: Hans Erik van Elburg , dispatch@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221D6A9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] Fwd: [Sipping] Fwd: Expert reviewofdraft-vanelburg-sipping-private-network-indication-03 Thread-Index: Acn+Ksx75CnoQwoEQhWX6DtVpdbSXQCg/4PA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001E1A290@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907021519h5093aec3g5023cc7c6a38ba32@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00218C5B3@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907030710i5e51de42icfbcc0d0064b5ddd@mail.gmail.com> <9ae56b1e0907030716w738f1167n889e26694f71087c@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00218C81B@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907060242r7c408393u5333749a88b958a8@mail.gmail.com> <9ae56b1e0907060406p3d42b0fdled2bb34f55d6b896@mail.gmail.com> <9ae56b1e0907060410jd5389f5q81f28279984c8615@mail.gmail.com> Subject: Re: [dispatch] Fwd: [Sipping] Fwd: Expert reviewofdraft-vanelburg-sipping-private-network-indication-03 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, 09 Jul 2009 16:24:15 -0000 My review comments have been resolved with the exception of the following: - I failed to find an example showing how it would work for private network traffic between two enterprises (as claimed in 1.3 last bullet). Which enterprise is identified, or is there an interworking function that changes the indicator? - "There may be cases where treating the call as a public network call although both participants are from the same enterprise is advantageous to the enterprise." I requested examples, but I didn't find any in the new draft. - "The business trunking application providing routeing capabilities for the enterprise traffic, and supports the identification of calls to and from public network users, break-in and break out of that traffic." This does not parse. I think "providing" should be "provides". - I didn't have time to check the document for correction of the many nits that I mentioned in general terms during my original review. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 06 July 2009 12:10 > To: dispatch@ietf.org > Subject: [dispatch] Fwd: [Sipping] Fwd: Expert=20 > reviewofdraft-vanelburg-sipping-private-network-indication-03 >=20 > The updates after expert review of the=20 > draft-vanelburg-sipping-private-network-indication-03 has=20 > been submitted to dispatch as: > http://tools.ietf.org/html/draft-vanelburg-dispatch-private-ne > twork-ind-00 >=20 >=20 > or plain text: > http://tools.ietf.org/id/draft-vanelburg-dispatch-private-netw > ork-ind-00.txt >=20 >=20 > Best Regards, > /Hans Erik van Elburg >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: Hans Erik van Elburg > Date: Mon, Jul 6, 2009 at 1:06 PM > Subject: Re: [Sipping] Fwd: Expert review=20 > ofdraft-vanelburg-sipping-private-network-indication-03 > To: "Elwell, John" > Cc: "DRAGE, Keith (Keith)" , IETF=20 > Sipping List >=20 >=20 >=20 > Draft has been uploaded as=20 > http://tools.ietf.org/html/draft-vanelburg-dispatch-private-ne > twork-ind-00 >=20 > Best Regards, > /Hans Erik van Elburg=20 >=20 >=20 > On Mon, Jul 6, 2009 at 11:42 AM, Hans Erik van Elburg=20 > wrote: >=20 >=20 > Hi John, >=20 > 1. Done, moved 10 up and inserted as 1.2. Added the=20 > following sentence to 1.1: > "3GPP and ETSI TISPAN have identified a set of=20 > requirements that can be met by defining a new SIP P-header,=20 > according to the procedures in RFC 3427 [RFC3427]." > =09 > 2. Done > 4a. Done > 4b. Done > 4c. Done > 5. I added the following terminology description: >=20 > "3.1. Traffic > =09 > In the context of this document the term=20 > traffic is understood as all > communication pertaining to and/or controlled=20 > by a SIP transaction or > dialog." >=20 > 8. Done >=20 > Will upload this as cutoff day for 00 drafts is today. >=20 > /Hans Erik van Elburg=20 >=20 >=20 >=20 > On Mon, Jul 6, 2009 at 8:52 AM, Elwell, John=20 > wrote: > =09 >=20 > Hans Erik, > =09 >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf=20 > Of Hans Erik van Elburg > > Sent: 03 July 2009 15:17 > > To: Elwell, John; DRAGE, Keith (Keith) > > Cc: IETF Sipping List > > Subject: [Sipping] Fwd: Expert review > >=20 > ofdraft-vanelburg-sipping-private-network-indication-03 > > > > Resent and history removed as otherwise=20 > rejected by mailing list. > > > > Hi John, > > > > 1. Again the required applicability statement=20 > is in section > > 10 of the main body. (Same pattern has been=20 > followed in > > RFC5502, 5002 and 4457) which I took as=20 > examples. Together > > with the additional text in the abstract that=20 > should be > > sufficient. If the text in section 10 needs=20 > to be improved > > then please indicate so. > =09 > [JRE] I must have written the original comment=20 > 1 before I got down to > section 10. Basically section 10 is far too=20 > late in the document, and I > would have expected the statement, perhaps as=20 > section 1, or perhaps as a > section 1.2 before the existing 1.2. > =09 >=20 >=20 > > > > 2. Took in your nits, the abstract now reads: > > "This document specifies the SIP=20 > P-Private-Network-Indication > > P-header. The use of this private network=20 > indication extension > > is only applicable inside an administrative=20 > domain with > > previously agreed-upon policies for=20 > generation, transport and > > usage of such information. A private network=20 > indication > > allows nodes in such a domain to treat=20 > private network traffic > > according to a different set of rules then=20 > than the set > > applicable to public network traffic. The=20 > indication also > > distinguishes traffic from one private=20 > network from another > > private network." > =09 > [JRE] > Delete the word "then". > =09 >=20 > > > > 4a. Regarding 1.2 item b). Would the=20 > following rewrite help?: > > OLD: > > " b) business trunking application, where the=20 > NGN hosts > > transit capabilities between NGCN's, break-in=20 > capabilities > > from NGN to NGCN and break-out capabilities=20 > from NGCN to NGN; and" > > /OLD > > > > > > NEW: > > " b) business trunking application, where the=20 > NGN hosts > > transit capabilities between NGCN's, break-in=20 > capabilities > > where the NGN converts public network traffic=20 > to private > > network traffic for delivery at a served NGCN=20 > and break-out > > capabilities where the NGN converts private=20 > network traffic > > from a served NGCN to public network traffic; and" > > > > /NEW > > > > If not please suggest an improved sentence=20 > that covers your > > concern. Please note that in the example that=20 > you gave it is > > not the business trunking application that does the > > conversion, but the hosted enterprise application. > =09 > [JRE] That would do. > =09 >=20 >=20 > > > > 4b. "normal rules" > > Looking at the definition, would the=20 > following rewrite help: > > OLD > > " Traffic sent to or received from a public=20 > telecommunication > > network for processing according to the normal rules." > > /OLD > > > > NEW > > " Traffic sent to or received from a public=20 > telecommunication > > network for processing according to the rules=20 > for ordinary > > subscribers of a public telecommunication network." > > /NEW > =09 > [JRE] That would do. > =09 >=20 > > > > 4c. NGN is a public telecommunication network > > > - "To summarize a few example reasons=20 > for a public > > telecommunication network to make the=20 > distinction between the > > two types of traffic" Isn't it an NGN that=20 > needs to make the > > distinction? > > > [HE] NGN is a public telecommunication=20 > network. But we can > > rephrase to: "To summarize a few example=20 > reasons for a public > > NGN to make the distinction between the two=20 > types of traffic" [/HE] > =09 > [JRE] OK > =09 >=20 > > > > [JRE] I think that is the problem I am=20 > having. I believe an > > NGN is a network infrastructure that supports=20 > both public > > network traffic and private network traffic,=20 > or in other > > words it supports both a public network and a=20 > number of > > private networks.[/JRE] > > [HE2]Yes, but its main purpose is to serve as a public > > network with all the regulations that apply=20 > to such networks > > etc. This does not prohibit an NGN to be used=20 > as a private > > network of course, but still it has been=20 > designed from the > > perspective of having to serve the needs of=20 > public network > > operators. That is why the "normal"/default =20 > procedures are > > for public network traffic. As we want to=20 > introduce the > > capability for such a public network (NGN) to=20 > also support > > private network traffic that has to be processed to a > > different set of rules, the=20 > Private-Network-Indication is > > needed.[/HE2] > > > > > > 5. Traffic --> SIP traffic > > Calling traffic SIP traffic suggest that the=20 > media is not > > part of the traffic, is that what we want?? > =09 > [JRE] The point is, it is not HTTP traffic or=20 > FTP traffic or SMTP > traffic or whatever. > =09 >=20 > > > > > > 6. Example private network traffic can also=20 > exist between two > > different enterprises > > Where would you like to see this? Obviously=20 > section 1.2 is > > not the right place for such an example. > > Isn't this too obvious, if you imagine that=20 > two companies > > have agreed to form a cooperation and=20 > communicate under this > > agreement? > > Would you like to see this as an additional=20 > example in section 4? > =09 > [JRE] I was not necessarily seeking a further=20 > example. However, given > that the private network indication identifies=20 > the particular private > network, what form does this indication take=20 > when traffic is between two > enterprises? Is there some interworking=20 > function where the identifier > changes from that of the first private network=20 > to that of the second > private network? > =09 >=20 > > > > > > 8. calling line identification > > Yes we agree fully on that "calling line=20 > identification is > > not an adequate distinction". I think that is what the > > current text tries to explain. Actually what=20 > I dont like > > about this text is that it starts explaining what the > > indication is not about. I propose that we=20 > completely remove > > the 1st paragraph in section 1.3 and the 1st=20 > word "Rather" > > from the 2nd paragraph. > =09 > [JRE] Yes. And in the second paragraph, perhaps=20 > we could enhance: > "This > indication is not for the end user on the=20 > private network." > to say: > "This indication does not identify an end user=20 > on a private network and > is not for delivery to an end user on the=20 > private network." > =09 > =09 > John > =09 > =09 > > > > /Hans Erik van Elburg > > > > > > > > > =09 >=20 >=20 >=20 >=20 >=20 From HKaplan@acmepacket.com Thu Jul 9 10:36:40 2009 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 39B1028C22B for ; Thu, 9 Jul 2009 10:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 0i9gnPudp+j9 for ; Thu, 9 Jul 2009 10:36:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 333BD28C1E9 for ; Thu, 9 Jul 2009 10:36:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 9 Jul 2009 13:37:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 9 Jul 2009 13:37:05 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Thu, 9 Jul 2009 13:37:06 -0400 Thread-Topic: Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt Thread-Index: AcoAu+CWNnOuqryqTr+E8nmYviRhHw== 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] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt 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, 09 Jul 2009 17:36:40 -0000 Howdy, As part of a discussion in the SIP Forum regarding a model for Registration= we are using for IP-PBX's, I was asked by someone to submit an I-D describ= ing it, in case it would be of any value. Since I hadn't seen an I-D befor= e on how 3GPP/ETSI did their model, and since their model is different from= SIP-Forum's, I submitted one which describes the models for both SIP Forum= 's SIP-Connect v1.1 and 3GPP/ETSI. NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP,= and I am still talking with colleagues in 3GPP to make sure I got that par= t right. This is purely an individual submission in all respects. Forwarded message: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Session Initiation Protocol (SIP) Implicit Registrations Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-sip-implicit-registrations-00.txt Pages : 12 Date : 2009-07-05 This document identifies several approaches to provide reachability informa= tion for a domain or multiple AoR's using a single SIP REGISTER method tran= saction, in ways not originally envisioned or documented by RFC 3261. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-sip-implicit-regi= strations-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From gonzalo.camarillo@ericsson.com Thu Jul 9 13:48:18 2009 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 D329E3A6D3A for ; Thu, 9 Jul 2009 13:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=-1.936, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 qox0bVICH0pe for ; Thu, 9 Jul 2009 13:48:18 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E16403A6D32 for ; Thu, 9 Jul 2009 13:48:17 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-bd-4a5657ab66d1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 0E.6A.02747.BA7565A4; Thu, 9 Jul 2009 22:48:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 22:48:43 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 22:48:42 +0200 Received: from [131.160.126.232] (rvi2-126-232.lmf.ericsson.se [131.160.126.232]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 29D1923F6; Thu, 9 Jul 2009 23:48:43 +0300 (EEST) Message-ID: <4A5657AA.60401@ericsson.com> Date: Thu, 09 Jul 2009 23:48:42 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2009 20:48:43.0043 (UTC) FILETIME=[A5571730:01CA00D6] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Input requested: abandoning draft-ietf-sipping-profile-datasets-03? 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, 09 Jul 2009 20:48:18 -0000 Folks, the SIPPING WG agreed to work on the following draft a long time ago: http://tools.ietf.org/html/draft-ietf-sipping-profile-datasets-03 As you can see in the following slide, the media-policy draft depends on the draft above: http://www.ietf.org/proceedings/07jul/slides/sipping-4/sld11.htm While there are people interested in the media-policy draft, we have not found anyone interested in the profile-datasets draft. One of the things we agreed to do when restructured RAI and chartered DISPATCH was to drop items people were no longer interested in. Therefore, at this point, we are considering abandoning the profile-dataset draft. If we do this, we would need to import a few things from that draft to the media-policy draft (e.g., the merging rules) but the idea would be to only progress the media-policy draft. Does anyone have any objection to this way forward? Note that in order to progress a draft we need people interested in it and people willing to put cycles on it. Therefore, if you are interested in keeping the draft alive, you will be automatically volunteering to put cycles on it in order to progress it ;o) Thanks, Gonzalo DISPATCH co-chair From AUDET@nortel.com Thu Jul 9 13:52:17 2009 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 2DF9F3A6D3A for ; Thu, 9 Jul 2009 13:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 v2kvJIQZmyKl for ; Thu, 9 Jul 2009 13:52:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 322683A6D37 for ; Thu, 9 Jul 2009 13:52:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n69Kqfi06913; Thu, 9 Jul 2009 20:52:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 15:52:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE8AADC@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5657AA.60401@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Input requested: abandoningdraft-ietf-sipping-profile-datasets-03? thread-index: AcoA1qrEma2tf3OwQg6GZsFdLqjXnwAAGeBA References: <4A5657AA.60401@ericsson.com> From: "Francois Audet" To: "Gonzalo Camarillo" , "DISPATCH" Subject: Re: [dispatch] Input requested: abandoningdraft-ietf-sipping-profile-datasets-03? 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, 09 Jul 2009 20:52:17 -0000 ...and is anybody interested in the media-policy draft?=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Thursday, July 09, 2009 13:49 > To: DISPATCH > Subject: [dispatch] Input requested:=20 > abandoningdraft-ietf-sipping-profile-datasets-03? >=20 > Folks, >=20 > the SIPPING WG agreed to work on the following draft a long time ago: >=20 > http://tools.ietf.org/html/draft-ietf-sipping-profile-datasets-03 >=20 > As you can see in the following slide, the media-policy draft=20 > depends on the draft above: >=20 > http://www.ietf.org/proceedings/07jul/slides/sipping-4/sld11.htm >=20 > While there are people interested in the media-policy draft,=20 > we have not found anyone interested in the profile-datasets draft. >=20 > One of the things we agreed to do when restructured RAI and=20 > chartered DISPATCH was to drop items people were no longer=20 > interested in.=20 > Therefore, at this point, we are considering abandoning the=20 > profile-dataset draft. If we do this, we would need to import=20 > a few things from that draft to the media-policy draft (e.g.,=20 > the merging > rules) but the idea would be to only progress the media-policy draft. >=20 > Does anyone have any objection to this way forward? >=20 > Note that in order to progress a draft we need people=20 > interested in it and people willing to put cycles on it.=20 > Therefore, if you are interested in keeping the draft alive,=20 > you will be automatically volunteering to put cycles on it in=20 > order to progress it ;o) >=20 > Thanks, >=20 > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From AUDET@nortel.com Thu Jul 9 17:16:17 2009 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 3294D3A6CB4 for ; Thu, 9 Jul 2009 17:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 5Qx0iFDwQRKh for ; Thu, 9 Jul 2009 17:16:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 44C6F28C17B for ; Thu, 9 Jul 2009 17:16:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6A0FlO07640; Fri, 10 Jul 2009 00:15:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 9 Jul 2009 19:15:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE8ADB9@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A53A662.9060503@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-02] thread-index: Acn/O9nbVjE8j2VYTuOtklVDa6AHfgBt6nYw References: <4A53A662.9060503@nostrum.com> From: "Francois Audet" To: "Adam Roach" , "IETF Dispatch" Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-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: Fri, 10 Jul 2009 00:16:17 -0000 Q291bnQgbWUgaW4uIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRp c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgDQo+IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNCj4gU2VudDogVHVlc2RheSwgSnVseSAwNywg MjAwOSAxMjo0OA0KPiBUbzogSUVURiBEaXNwYXRjaA0KPiBTdWJqZWN0OiBbZGlzcGF0Y2hdIFNJ UCBIVFRQIEV2ZW50IFBhY2thZ2UgW0Z3ZDogTmV3IFZlcnNpb24gDQo+IE5vdGlmaWNhdGlvbmZv ciBkcmFmdC1yb2FjaC1zaXAtaHR0cC1zdWJzY3JpYmUtMDJdDQo+IA0KPiBJJ3ZlIGp1c3Qgc3Vi bWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgDQo+IGRyYWZ0LXJvYWNoLXNpcC1odHRwLXN1YnNjcmli ZSwgd2hpY2ggYWRkcmVzc2VzIGEgY291cGxlIG9mIA0KPiBtaW5vciBjb21tZW50cyBtYWRlIHJl Z2FyZGluZyAtMDEgWzFdLiBJIGtub3cgdGhlcmUgYXJlIHVzZSANCj4gY2FzZXMgY29taW5nIG91 dCBvZiB0aGUgQkxJU1Mgd29ya2luZyBncm91cCB0aGF0IHdvdWxkIA0KPiBiZW5lZml0IGZyb20g c3VjaCBhIG1lY2hhbmlzbS4gSSBzdXNwZWN0IGl0IGhhcyBhIHBvdGVudGlhbCANCj4gY29tbXVu aXR5IG9mIGludGVyZXN0IGJleW9uZCB0aGF0IHNpbmdsZSB3b3JraW5nIGdyb3VwLCB3aGljaCAN Cj4gaXMgd2h5IEknbSBicmluZ2luZyBpdCB0byBESVNQQVRDSC4NCj4gDQo+IEknbSBoYXBweSB0 byBrZWVwIHdvcmtpbmcgb24gdGhlIGRvY3VtZW50IGFzIGxvbmcgYXMgdGhlcmUgaXMgDQo+IGVu b3VnaCBpbnRlcmVzdCB0byBtYWtlIHRoZSB3b3JrIHdvcnRod2hpbGUuIElmIHdlIHdlcmUgdG8g DQo+IGZvcm0gYSBtYWlsaW5nIGxpc3Qgd2l0aCB0aGUgZ29hbCBvZiBtYWtpbmcgcHJvZ3Jlc3Mg b24gdGhpcyANCj4gd29yaywgd2hvIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gam9pbmluZz8NCj4g DQo+IC9hDQo+IA0KPiANCj4gWzFdIFRoZSBvbmx5IHN1YnN0YW50aXZlIGNoYW5nZSB3YXMgaW4g dGhlIHRoaXJkIHBhcmFncmFwaCBvZiBzZWN0aW9uIA0KPiAyLjIsIHdoaWNoIG5vdyByZXF1aXJl cyB0aGUgc2VydmVyIHRvIGluZGljYXRlIHdoaWNoIFVSSXMgYXJlIA0KPiBjYXVzaW5nIGl0IA0K PiB0byBmb3JiaWQgYSBzdWJzY3JpcHRpb24uDQo+IA0K From gonzalo.camarillo@ericsson.com Thu Jul 9 21:40:33 2009 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 1CC313A681C for ; Thu, 9 Jul 2009 21:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 jbJyBhfYoZTG for ; Thu, 9 Jul 2009 21:40:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CAF4A3A67F1 for ; Thu, 9 Jul 2009 21:40:31 -0700 (PDT) X-AuditID: c1b4fb3e-b7be7ae000001a87-73-4a56c65875ec Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D4.F1.06791.856C65A4; Fri, 10 Jul 2009 06:40:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jul 2009 06:40:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jul 2009 06:40:54 +0200 Received: from [131.160.126.232] (rvi2-126-232.lmf.ericsson.se [131.160.126.232]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6699324B7; Fri, 10 Jul 2009 07:40:54 +0300 (EEST) Message-ID: <4A56C655.6010103@ericsson.com> Date: Fri, 10 Jul 2009 07:40:53 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5657AA.60401@ericsson.com> <1ECE0EB50388174790F9694F77522CCF1EE8AADC@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EE8AADC@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 04:40:54.0387 (UTC) FILETIME=[9C231C30:01CA0118] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Input requested: abandoningdraft-ietf-sipping-profile-datasets-03? 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, 10 Jul 2009 04:40:33 -0000 Hi, yes, as I stated in my email below, there are people interested in the functionality that draft provides. However, we have not found anybody interested in defining new profiles (besides the one defined in the media-policy draft). Cheers, Gonzalo Francois Audet wrote: > ...and is anybody interested in the media-policy draft? > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Thursday, July 09, 2009 13:49 >> To: DISPATCH >> Subject: [dispatch] Input requested: >> abandoningdraft-ietf-sipping-profile-datasets-03? >> >> Folks, >> >> the SIPPING WG agreed to work on the following draft a long time ago: >> >> http://tools.ietf.org/html/draft-ietf-sipping-profile-datasets-03 >> >> As you can see in the following slide, the media-policy draft >> depends on the draft above: >> >> http://www.ietf.org/proceedings/07jul/slides/sipping-4/sld11.htm >> >> While there are people interested in the media-policy draft, >> we have not found anyone interested in the profile-datasets draft. >> >> One of the things we agreed to do when restructured RAI and >> chartered DISPATCH was to drop items people were no longer >> interested in. >> Therefore, at this point, we are considering abandoning the >> profile-dataset draft. If we do this, we would need to import >> a few things from that draft to the media-policy draft (e.g., >> the merging >> rules) but the idea would be to only progress the media-policy draft. >> >> Does anyone have any objection to this way forward? >> >> Note that in order to progress a draft we need people >> interested in it and people willing to put cycles on it. >> Therefore, if you are interested in keeping the draft alive, >> you will be automatically volunteering to put cycles on it in >> order to progress it ;o) >> >> Thanks, >> >> Gonzalo >> DISPATCH co-chair >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From salvatore.loreto@ericsson.com Fri Jul 10 01:41:03 2009 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 DEB273A685E for ; Fri, 10 Jul 2009 01:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.327 X-Spam-Level: X-Spam-Status: No, score=-4.327 tagged_above=-999 required=5 tests=[AWL=-2.078, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 cwhPohx4vfFe for ; Fri, 10 Jul 2009 01:41:03 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9A5503A6931 for ; Fri, 10 Jul 2009 01:41:02 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-68-4a56feb84807 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id F7.80.02747.8BEF65A4; Fri, 10 Jul 2009 10:41:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jul 2009 10:41:28 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jul 2009 10:41:27 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5D3E92450; Fri, 10 Jul 2009 11:41:27 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 27FCF21A07; Fri, 10 Jul 2009 11:41:27 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CEE87219CC; Fri, 10 Jul 2009 11:41:26 +0300 (EEST) Message-ID: <4A56FEB6.7010008@ericsson.com> Date: Fri, 10 Jul 2009 11:41:26 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Adam Roach References: <4A53A662.9060503@nostrum.com> In-Reply-To: <4A53A662.9060503@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 10 Jul 2009 08:41:27.0394 (UTC) FILETIME=[36E13420:01CA013A] X-Brightmail-Tracker: AAAAAA== Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Fri, 10 Jul 2009 08:41:04 -0000 Hi Adam, I'd be interested in joining, but to discuss and decide about the real need of this package. I would understand better: - the advantage of having a SIP Event Package to monitor the changes in an HTTP resource ; (by the way the draft doesn't explain how it would be possible monitor the "creation" or the "deletion" of an HTTP resource!) versus -using directly the HTTP long-polling techniques that can perform at same time the monitoring and the content transfer of HTTP resources. (for an overview of the HTTP long-polling techniques check: http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.txt ) thanks Sal Adam Roach wrote: > I've just submitted a new version of draft-roach-sip-http-subscribe, > which addresses a couple of minor comments made regarding -01 [1]. I > know there are use cases coming out of the BLISS working group that > would benefit from such a mechanism. I suspect it has a potential > community of interest beyond that single working group, which is why > I'm bringing it to DISPATCH. > > I'm happy to keep working on the document as long as there is enough > interest to make the work worthwhile. If we were to form a mailing > list with the goal of making progress on this work, who would be > interested in joining? > > /a > > > [1] The only substantive change was in the third paragraph of section > 2.2, which now requires the server to indicate which URIs are causing > it to forbid a subscription. > > ------------------------------------------------------------------------ > > Subject: > New Version Notification for draft-roach-sip-http-subscribe-02 > From: > IETF I-D Submission Tool > Date: > Tue, 7 Jul 2009 12:26:36 -0700 (PDT) > To: > adam@nostrum.com > > To: > adam@nostrum.com > > > A new version of I-D, draft-roach-sip-http-subscribe-02.txt has been successfuly submitted by Adam Roach and posted to the IETF repository. > > Filename: draft-roach-sip-http-subscribe > Revision: 02 > Title: A SIP Event Package for Subscribing to Changes to an HTTP Resource > Creation_date: 2009-07-07 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > The Session Initiation Protocol (SIP) is increasingly being used in > systems that are tightly coupled with Hypertext Transport Protocol > (HTTP) servers for a variety of reasons. In many of these cases, > applications can benefit from being able to discover, in near-real- > time, when a specific HTTP resource is created, changed, or deleted. > This document proposes a mechanism, based on the SIP events > framework, for doing so. > > This document further proposes that the HTTP work necessary to make > such a mechanism work be extensible to support protocols other than > SIP for monitoring HTTP resources. > > > > The IETF Secretariat. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From theo@crazygreek.co.uk Fri Jul 10 06:17:03 2009 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 A5D5C28C126 for ; Fri, 10 Jul 2009 06:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 FsDNAXp9gQDo for ; Fri, 10 Jul 2009 06:17:02 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id 69BBC3A681E for ; Fri, 10 Jul 2009 06:17:02 -0700 (PDT) Received: from source ([72.14.220.157]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSlc/aqycNx0MpNDUuxDmBiUD4wijWuzZ@postini.com; Fri, 10 Jul 2009 06:17:31 PDT Received: by fg-out-1718.google.com with SMTP id d23so331404fga.8 for ; Fri, 10 Jul 2009 06:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.60.9 with SMTP id i9mr1020753fga.10.1247231849753; Fri, 10 Jul 2009 06:17:29 -0700 (PDT) In-Reply-To: <4A56FEB6.7010008@ericsson.com> References: <4A53A662.9060503@nostrum.com> <4A56FEB6.7010008@ericsson.com> From: Theo Zourzouvillys Date: Fri, 10 Jul 2009 14:17:09 +0100 Message-ID: <167dfb9b0907100617h3dde062cm714fb5cfb6d81a2d@mail.gmail.com> To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Fri, 10 Jul 2009 13:17:03 -0000 On Fri, Jul 10, 2009 at 9:41 AM, Salvatore Loreto wrote: > - the advantage of having a SIP Event Package to monitor the changes in a= n > HTTP resource ; > =A0(by the way the draft doesn't explain how it would be possible monitor= the > "creation" or the "deletion" of > =A0an HTTP resource!) see the last paragraph in 3.5.1 for deletion... > -using directly the HTTP long-polling techniques that can perform at same > time the monitoring > and the content transfer of HTTP resources. > (for an overview of the HTTP long-polling techniques check: > http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.tx= t ) This would require the connection between the notifier and the server to stay open. When a single client is monitoring tens of thousands of resources potentially over as many servers, this becomes very unfriendly. Consider that the period between a SUBSCRIBE and being notified of changes could potentially be days. Additionally, monitoring can be done by millions of clients to a single server - each of which would need an open connection to the server(s). ~ Theo From salvatore.loreto@ericsson.com Fri Jul 10 06:40:46 2009 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 9F43D28C2DB for ; Fri, 10 Jul 2009 06:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[AWL=-2.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ymDxBr9Mmerx for ; Fri, 10 Jul 2009 06:40:45 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7161C28C197 for ; Fri, 10 Jul 2009 06:40:45 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-ba-4a5744f85c68 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id B5.84.02747.8F4475A4; Fri, 10 Jul 2009 15:41:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jul 2009 15:41:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jul 2009 15:41:11 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AA6672450; Fri, 10 Jul 2009 16:41:11 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6F78221A07; Fri, 10 Jul 2009 16:41:11 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1D6B1219CC; Fri, 10 Jul 2009 16:41:11 +0300 (EEST) Message-ID: <4A5744F6.8040803@ericsson.com> Date: Fri, 10 Jul 2009 16:41:10 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Theo Zourzouvillys References: <4A53A662.9060503@nostrum.com> <4A56FEB6.7010008@ericsson.com> <167dfb9b0907100617h3dde062cm714fb5cfb6d81a2d@mail.gmail.com> In-Reply-To: <167dfb9b0907100617h3dde062cm714fb5cfb6d81a2d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 10 Jul 2009 13:41:11.0831 (UTC) FILETIME=[16708270:01CA0164] X-Brightmail-Tracker: AAAAAA== Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Fri, 10 Jul 2009 13:40:46 -0000 don't take me wrong, I am just thinking about the pro and cons... in line! Theo Zourzouvillys wrote: > On Fri, Jul 10, 2009 at 9:41 AM, Salvatore > Loreto wrote: > > >> - the advantage of having a SIP Event Package to monitor the changes in an >> HTTP resource ; >> (by the way the draft doesn't explain how it would be possible monitor the >> "creation" or the "deletion" of >> an HTTP resource!) >> > > see the last paragraph in 3.5.1 for deletion... > right! but then what about "creation" ? > >> -using directly the HTTP long-polling techniques that can perform at same >> time the monitoring >> and the content transfer of HTTP resources. >> (for an overview of the HTTP long-polling techniques check: >> http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.txt ) >> > > This would require the connection between the notifier and the server > to stay open. right a point in favour of the Event package is that SIP goes over UDP > When a single client is monitoring tens of thousands of > resources potentially over as many servers, this becomes very > unfriendly. How to monitoring more resources on the same server is something that people are starting to think also for web-application using HTTP. > Consider that the period between a SUBSCRIBE and being > notified of changes could potentially be days. right, but then you have refresh the SUBSCRIBE... etc etc. > Additionally, > monitoring can be done by millions of clients to a single server - > each of which would need an open connection to the server(s). > that is not a real problem, with HTML5 and the growing number of web applications a Server (a Web Server in this case) will end up in exactly the same scenario. > ~ Theo From theo@crazygreek.co.uk Fri Jul 10 07:04:44 2009 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 DE1763A6AAF for ; Fri, 10 Jul 2009 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 Uy5aSakW9Cp5 for ; Fri, 10 Jul 2009 07:04:44 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id 9924B28C32A for ; Fri, 10 Jul 2009 07:04:08 -0700 (PDT) Received: from source ([72.14.220.155]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSldKdPa3xHNC/zdlOm6q2vYgRGOBMAI+@postini.com; Fri, 10 Jul 2009 07:04:37 PDT Received: by fg-out-1718.google.com with SMTP id e21so22626fga.10 for ; Fri, 10 Jul 2009 07:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.93.20 with SMTP id q20mr1065330fgb.16.1247234676608; Fri, 10 Jul 2009 07:04:36 -0700 (PDT) In-Reply-To: <4A5744F6.8040803@ericsson.com> References: <4A53A662.9060503@nostrum.com> <4A56FEB6.7010008@ericsson.com> <167dfb9b0907100617h3dde062cm714fb5cfb6d81a2d@mail.gmail.com> <4A5744F6.8040803@ericsson.com> From: Theo Zourzouvillys Date: Fri, 10 Jul 2009 15:04:16 +0100 Message-ID: <167dfb9b0907100704s3a3a31c4meea9d3b047bf0586@mail.gmail.com> To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Fri, 10 Jul 2009 14:04:44 -0000 On Fri, Jul 10, 2009 at 2:41 PM, Salvatore Loreto wrote: > right! > but then what about "creation" ? Sorry, i missed that bit :-) My understanding (and how we implement it) is server could return a Link header in a 404 response in the same way as a 200, which can then be monitored. Of course, servers may elect not to return a Link header for the 404, or could reject the SUBSCRIBE request as received if they don't support monitoring of non-existent resources. >> This would require the connection between the notifier and the server >> to stay open. > > right a point in favour of the Event package is that SIP goes over UDP or one connection for many clients on the same proxy. >> Consider that the period between a SUBSCRIBE and being >> notified of changes could potentially be days. > > right, but then you have refresh the SUBSCRIBE... etc etc. only for every interval! >> =A0Additionally, >> monitoring can be done by millions of clients to a single server - >> each of which would need an open connection to the server(s). >> > > that is not a real problem, with HTML5 and the growing number of web > applications a Server (a Web Server in this case) > will end up in exactly the same scenario. agreed. Note that this is just one protocol that can be used for monitoring (using the Link 'monitor' header). There could be others, such as over bi-direcitonal HTTP, XMPP, etc :) ~ Theo From adam@nostrum.com Fri Jul 10 08:40:50 2009 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 E8B883A6A4B for ; Fri, 10 Jul 2009 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, SPF_PASS=-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 NCSaFxLBwB4B for ; Fri, 10 Jul 2009 08:40:50 -0700 (PDT) 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 C79E43A690E for ; Fri, 10 Jul 2009 08:40:49 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6AFfABX055827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 10:41:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A576116.8010403@nostrum.com> Date: Fri, 10 Jul 2009 10:41:10 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Theo Zourzouvillys References: <4A53A662.9060503@nostrum.com> <4A56FEB6.7010008@ericsson.com> <167dfb9b0907100617h3dde062cm714fb5cfb6d81a2d@mail.gmail.com> <4A5744F6.8040803@ericsson.com> <167dfb9b0907100704s3a3a31c4meea9d3b047bf0586@mail.gmail.com> In-Reply-To: <167dfb9b0907100704s3a3a31c4meea9d3b047bf0586@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Fri, 10 Jul 2009 15:40:51 -0000 Theo Zourzouvillys wrote: > On Fri, Jul 10, 2009 at 2:41 PM, Salvatore > Loreto wrote: > > >> right! >> but then what about "creation" ? >> > > Sorry, i missed that bit :-) > > My understanding (and how we implement it) is server could return a > Link header in a 404 response in the same way as a 200, which can then > be monitored. Of course, servers may elect not to return a Link > header for the 404, or could reject the SUBSCRIBE request as received > if they don't support monitoring of non-existent resources. > That seems like a really good idea. I'll put it on the list for the next version. /a >>> Consider that the period between a SUBSCRIBE and being >>> notified of changes could potentially be days. >>> >> right, but then you have refresh the SUBSCRIBE... etc etc. >> > > only for every interval! > And the draft explicitly addresses this point: Subscriptions to slower-changing resources lack this property, and the need to periodically refresh subscriptions render short subscriptions wasteful. For these type of subscriptions, expirations as long as 604800 (one week) or even longer may well make sense. /a From dworley@nortel.com Fri Jul 10 12:42:07 2009 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 6163E3A6D3E for ; Fri, 10 Jul 2009 12:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.69 X-Spam-Level: X-Spam-Status: No, score=-6.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 AOLMGnsV7TJ6 for ; Fri, 10 Jul 2009 12:42:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6C0B53A67B6 for ; Fri, 10 Jul 2009 12:42:06 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6AJgTl02444; Fri, 10 Jul 2009 19:42:29 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 15:42:29 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4A5348F5.5030200@cisco.com> References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Jul 2009 15:42:28 -0400 Message-Id: <1247254948.3757.34.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 19:42:29.0412 (UTC) FILETIME=[8F48DE40:01CA0196] Cc: dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 10 Jul 2009 19:42:07 -0000 On Tue, 2009-07-07 at 09:09 -0400, Paul Kyzivat wrote: > I still remain unconvinced that it is either necessary or appropriate > for one end of a call to be involved in how the other end aggregates > media resources for the call. To support this, I would say that a *primary* requirement for a solution should be that the "other end" does not have to be aware how "this end" is arranging for multiple media source/sinks. Otherwise, there is no interoperability with UAs that do not understand the aggregation scheme. Reading some of the discussion, I realized there is already a *very* common instance of disaggregated media: music-on-hold. UA X puts a call on hold, and then arranges for the music-on-hold source to send RTP to UA Y. The entire design problem for music-on-hold is arranging for UA Y *not* to have to understand what is going on. A typical solution is http://tools.ietf.org/html/draft-worley-service-example-03. We've had luck getting phone manufacturers to implement this, and there are a number of similar schemes that other phones use. Dale From dworley@nortel.com Fri Jul 10 12:51:14 2009 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 051B128C32C for ; Fri, 10 Jul 2009 12:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.686 X-Spam-Level: X-Spam-Status: No, score=-6.686 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 3QwqNHV4DFHq for ; Fri, 10 Jul 2009 12:51:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0CE893A69FB for ; Fri, 10 Jul 2009 12:51:12 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6AJnuj13005; Fri, 10 Jul 2009 19:49:57 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 15:51:32 -0400 From: "Dale Worley" To: R.Jesske@telekom.de In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Jul 2009 15:51:32 -0400 Message-Id: <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 19:51:32.0931 (UTC) FILETIME=[D33F4930:01CA0197] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 10 Jul 2009 19:51:14 -0000 On Tue, 2009-07-07 at 07:13 +0200, R.Jesske@telekom.de wrote: > Hi Dale, > Within the SIPPING group I had already discussions on that issue. > The assumption was that the use of the Reason Header within Responses is conditionally allowed. > > The RFC 3326 says: > 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 whose > status code explicitly allows the presence of this header field. > > > So we need a draft where it is stated that a reason header can be included within the SIP Response. That was also the recommendation of that discussion. That is why I wrote a draft. > Nevertheless some standards already include this behaviour like the ITU-T Q.1912.5 specification. > Also 3GPP needs the reason header within Responses. It is still unclear to me what is being changed. Is the change the replacement of "conditionally allowed" to "allowed"? In any case, in my mind the purpose of the Reason header is to carry Q.850 cause-codes in failure responses. The point is that the Abstract is not at all clear about the change from the status quo (at least to someone who isn't already thoroughly familiar with how Reason is currently specified). And the secondary point is that if the Abstract was clearer about what it is being changed, more people might read and discuss the draft. Dale From volkerh@bell-labs.com Sat Jul 11 09:33:11 2009 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 B005A3A697E for ; Sat, 11 Jul 2009 09:33:11 -0700 (PDT) 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 N1kk7JqtWIUw for ; Sat, 11 Jul 2009 09:33:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id D3F2F3A692E for ; Sat, 11 Jul 2009 09:33:10 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n6BGXbnh019763; Sat, 11 Jul 2009 11:33:38 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n6BGXbxO006906; Sat, 11 Jul 2009 11:33:37 -0500 (CDT) Received: from [135.244.33.221] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 11 Jul 2009 11:33:36 -0500 Message-ID: <4A58BED3.6030008@bell-labs.com> Date: Sat, 11 Jul 2009 12:33:23 -0400 From: Volker Hilt User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Moran, Timothy L." References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Overload Control Design: Loop Control 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, 11 Jul 2009 16:33:11 -0000 Tim, the case you are describing is discussed in the current draft in the Topologies section: If A can reliably determine that D, E and F are its only downstream neighbors and all of them are in overload, it may choose to report overload upstream on behalf of D, E and F. The section you were referring to discusses end-to-end overload control, however, the example is a hop-by-hop control. Thanks, Volker Moran, Timothy L. wrote: > Volker, > > > > A comment on the control loop paragraph in section 2 of the design > considerations for OLC: > > “A control loop spanning multiple hops can be used if the sending > entity has full knowledge about the SIP servers on the path of a SIP > message.” > > > > I read this as the sending entity is required to have full knowledge > of the entire path. I offer that that may not be the case. It may > be possible to only require knowledge of one _level_ downstream. > This sounds pretty much like your example except that the example > limits the case to “one” downstream server. Referring back to the > requirements case of two load balancing servers and the upstream > server “PA”, server PA can declare overload upstream by knowing that > servers P1 _and_ P2 are overloaded. > > > > Perhaps what I am trying to say is that an upstream server in a > managed network would declare overload (upstream) based on knowledge > that all next-hop servers are overloaded. > > > > Br, > > Tim M. > > > > > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ dispatch mailing list > dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From R.Jesske@telekom.de Sun Jul 12 23:16:39 2009 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 438483A6BF3 for ; Sun, 12 Jul 2009 23:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Gvx72RozPR4H for ; Sun, 12 Jul 2009 23:16:38 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id E84713A6BE8 for ; Sun, 12 Jul 2009 23:16:37 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 13 Jul 2009 08:16:56 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 08:16:55 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Jul 2009 08:16:54 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoBl9goQeE8ND9yRoWluh5BWt1legB5v5vQ References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> From: To: X-OriginalArrivalTime: 13 Jul 2009 06:16:55.0840 (UTC) FILETIME=[85785200:01CA0381] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 13 Jul 2009 06:16:39 -0000 Hi Dale, The main probblem is that reasons are currently not allowed in = responses. Neither conditionally nor allowed Please see: = http://www.ietf.org/mail-archive/web/sipping/current/msg09682.html The draft tries to close this gap and allows conditionally Q.850 = resasons within Resopnses. So it would be a service provider decision to = include Reasons in Responses when mapping from ISUP to SIP. The following call flow shows an example: A Gateway Gateway B=20 | IAM | | |=20 |------------------>| INVITE | |=20 | |----------------->| IAM |=20 | | 100 Trying |----------------->|=20 | |<-----------------| 100 Trying |=20 | | 403 Decline | | | | Reason Q850 #87 | REL Cause #87 | | REL Cause #87 | |<-----------------|=20 | |<-----------------| |=20 |<----------------- | | |=20 | | | |=20 | | | |=20 | | | |=20 Due to RFC 3398 a 403 will be mapped back to a ISUP Cause 21. With the = Reason in responses the Cause Value 87 will be secured and transferred = back to ISUP. Mheanwile I got some indications from some persons who see this issue = within the BLISS group due to the fact that this draft solves = interoperability issues within SIP and PSTN. Views? BR, Roland =20 -----Urspr=FCngliche Nachricht----- Von: Dale Worley [mailto:dworley@nortel.com]=20 Gesendet: Freitag, 10. Juli 2009 21:52 An: Jesske, Roland Cc: dispatch@ietf.org Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 On Tue, 2009-07-07 at 07:13 +0200, R.Jesske@telekom.de wrote: > Hi Dale, > Within the SIPPING group I had already discussions on that issue. > The assumption was that the use of the Reason Header within Responses = is conditionally allowed.=20 >=20 > The RFC 3326 says: > 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 whose > status code explicitly allows the presence of this header field. >=20 >=20 > So we need a draft where it is stated that a reason header can be = included within the SIP Response. That was also the recommendation of = that discussion. That is why I wrote a draft. > Nevertheless some standards already include this behaviour like the = ITU-T Q.1912.5 specification. > Also 3GPP needs the reason header within Responses. It is still unclear to me what is being changed. Is the change the replacement of "conditionally allowed" to "allowed"? In any case, in my mind the purpose of the Reason header is to carry Q.850 cause-codes in failure responses. The point is that the Abstract is not at all clear about the change from the status quo (at least to someone who isn't already thoroughly familiar with how Reason is currently specified). And the secondary point is that if the Abstract was clearer about what it is being changed, more people might read and discuss the draft. Dale From salvatore.loreto@ericsson.com Mon Jul 13 01:32:42 2009 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 3F2A728C146 for ; Mon, 13 Jul 2009 01:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.087 X-Spam-Level: X-Spam-Status: No, score=-4.087 tagged_above=-999 required=5 tests=[AWL=-1.838, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 yZ0lM37zWnMR for ; Mon, 13 Jul 2009 01:32:41 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2584F3A6D25 for ; Mon, 13 Jul 2009 01:32:40 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-a5-4a5af1452339 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 44.00.02747.541FA5A4; Mon, 13 Jul 2009 10:33:09 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 10:33:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 10:33:08 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E7CE42462; Mon, 13 Jul 2009 11:33:08 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AD58621A07; Mon, 13 Jul 2009 11:33:08 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 623A121925; Mon, 13 Jul 2009 11:33:08 +0300 (EEST) Message-ID: <4A5AF143.2070404@ericsson.com> Date: Mon, 13 Jul 2009 11:33:07 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Theo Zourzouvillys References: <4A53A662.9060503@nostrum.com> <4A56FEB6.7010008@ericsson.com> <167dfb9b0907100617h3dde062cm714fb5cfb6d81a2d@mail.gmail.com> <4A5744F6.8040803@ericsson.com> <167dfb9b0907100704s3a3a31c4meea9d3b047bf0586@mail.gmail.com> In-Reply-To: <167dfb9b0907100704s3a3a31c4meea9d3b047bf0586@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 13 Jul 2009 08:33:08.0743 (UTC) FILETIME=[8CE65970:01CA0394] X-Brightmail-Tracker: AAAAAA== Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Mon, 13 Jul 2009 08:32:42 -0000 Theo Zourzouvillys wrote: > On Fri, Jul 10, 2009 at 2:41 PM, Salvatore > Loreto wrote: > > >> right! >> but then what about "creation" ? >> > > Sorry, i missed that bit :-) > > My understanding (and how we implement it) is server could return a > Link header in a 404 response in the same way as a 200, which can then > be monitored. Of course, servers may elect not to return a Link > header for the 404, or could reject the SUBSCRIBE request as received > if they don't support monitoring of non-existent resources. > this could be a possibility, but it should be explicitly insert the SUBSCRIBE the willingness to monitor also *non-existent resource* moreover if a subscriber has several subscriptions to the same server, it should be avoided that the server sends this kind of information to each single subscription. for example the server should accept only one SUBSCRIBE willing to monitor *non-existent resource* per each UA. /Sal From RIFATYU@nortel.com Mon Jul 13 12:47:55 2009 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 CED8128C568 for ; Mon, 13 Jul 2009 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Pa3P5rzK6Jy1 for ; Mon, 13 Jul 2009 12:47:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5858D28C40A for ; Mon, 13 Jul 2009 12:47:54 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DJlYI10922; Mon, 13 Jul 2009 19:47:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 15:47:33 -0400 Message-ID: In-Reply-To: <4A53A662.9060503@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-02] Thread-Index: Acn/O9lTkPh6HlGARmGRqhk3rLXK5QEtglYg References: <4A53A662.9060503@nostrum.com> From: "Rifaat Shekh-Yusef" To: "Adam Roach" , "IETF Dispatch" Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-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: Mon, 13 Jul 2009 19:47:55 -0000 I am interested and willing to help this work progress. Regards, Rifaat -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, July 07, 2009 3:48 PM To: IETF Dispatch Subject: [dispatch] SIP HTTP Event Package [Fwd: New Version Notificationfor draft-roach-sip-http-subscribe-02] I've just submitted a new version of draft-roach-sip-http-subscribe, which addresses a couple of minor comments made regarding -01 [1]. I know there are use cases coming out of the BLISS working group that would benefit from such a mechanism. I suspect it has a potential community of interest beyond that single working group, which is why I'm bringing it to DISPATCH. I'm happy to keep working on the document as long as there is enough interest to make the work worthwhile. If we were to form a mailing list with the goal of making progress on this work, who would be interested in joining? /a [1] The only substantive change was in the third paragraph of section=20 2.2, which now requires the server to indicate which URIs are causing it to forbid a subscription. From scott.lawrence@nortel.com Tue Jul 14 07:34:45 2009 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 4A0593A6EED for ; Tue, 14 Jul 2009 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 H5INs1KsFP0H for ; Tue, 14 Jul 2009 07:34:44 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D106828C17B for ; Tue, 14 Jul 2009 07:33:49 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EEJFX15789; Tue, 14 Jul 2009 14:19:16 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 10:20:55 -0400 From: "Scott Lawrence" To: Salvatore Loreto In-Reply-To: <4A56FEB6.7010008@ericsson.com> References: <4A53A662.9060503@nostrum.com> <4A56FEB6.7010008@ericsson.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 14 Jul 2009 10:20:54 -0400 Message-Id: <1247581254.8561.137.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 14:20:55.0764 (UTC) FILETIME=[4D06D140:01CA048E] Cc: IETF Dispatch Subject: Re: [dispatch] SIP HTTP Event Package [Fwd: New Version Notification for draft-roach-sip-http-subscribe-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: Tue, 14 Jul 2009 14:34:45 -0000 Adam wrote: > I've just submitted a new version of draft-roach-sip-http-subscribe, > which addresses a couple of minor comments made regarding -01 [1]. I > know there are use cases coming out of the BLISS working group that > would benefit from such a mechanism. I suspect it has a potential > community of interest beyond that single working group, which is why > I'm bringing it to DISPATCH. I think this draft is a great idea - I've got a few comments, but will send those separately On Fri, 2009-07-10 at 11:41 +0300, Salvatore Loreto wrote: > I'd be interested in joining, but to discuss and decide about the real > need of this package. > > I would understand better: > - the advantage of having a SIP Event Package to monitor the changes in > an HTTP resource ; > (by the way the draft doesn't explain how it would be possible monitor > the "creation" or the "deletion" of > an HTTP resource!) I don't think that the mechanisms used to implement the service need to be a part of the discussion at all. The draft should concern itself with the on-the-wire behavior of the event package, not how the service providing it gets the information it needs. There are any number of ways it could be done, including integrating a SIP UA into the web server, the file store behind the web server, some application providing data via the web server, etc. None of that needs to be (or should be) in the draft defining the event package. From dworley@nortel.com Thu Jul 16 10:02:09 2009 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 1A76A28C134 for ; Thu, 16 Jul 2009 10:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 1vnuNrMdPE+g for ; Thu, 16 Jul 2009 10:02:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1CD003A69F7 for ; Thu, 16 Jul 2009 10:02:08 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GGxiD16175; Thu, 16 Jul 2009 16:59:44 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 13:01:25 -0400 From: "Dale Worley" To: R.Jesske@telekom.de In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 16 Jul 2009 13:01:24 -0400 Message-Id: <1247763684.4085.21.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2009 17:01:25.0461 (UTC) FILETIME=[0D997850:01CA0637] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 16 Jul 2009 17:02:09 -0000 On Mon, 2009-07-13 at 08:16 +0200, R.Jesske@telekom.de wrote: > The main probblem is that reasons are currently not allowed in > responses. Neither conditionally nor allowed > > Please see: http://www.ietf.org/mail-archive/web/sipping/current/msg09682.html That clarifies things. Let me rephrase my complaint: Although the text of the RFC states "The Reason header field MAY appear in [...] any response whose status code explicitly allows the presence of this header field.", that text is stunningly unclear that the consequence is that the Reason header is not allowed in *any* defined response, and a casual reader might not realize that Reason is thus effectively forbidden in all responses. Expanding the Abstract along these lines would make the significance and importance of the draft much clearer: Although the use of the Reason header in responses is considered in RFC 3326, doing so is not specified for any existing response code. This document specifies the use of the Reason header field in SIP responses to carry Q.850 reason codes for the failure of an INVITE. Dale From dworley@nortel.com Thu Jul 16 10:08:14 2009 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 2D6463A6938 for ; Thu, 16 Jul 2009 10:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.706 X-Spam-Level: X-Spam-Status: No, score=-6.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 KiWc4MWBdnjC for ; Thu, 16 Jul 2009 10:08:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 39EC53A68CC for ; Thu, 16 Jul 2009 10:08:13 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GH8cw19936; Thu, 16 Jul 2009 17:08:39 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 13:08:38 -0400 From: "Dale Worley" To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 16 Jul 2009 13:08:38 -0400 Message-Id: <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2009 17:08:38.0894 (UTC) FILETIME=[0FF218E0:01CA0638] Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 16 Jul 2009 17:08:14 -0000 On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) wrote: > Hi Roland, > > You use case is very common. > > I believe you are incorrect in saying that "reasons are currently > not allowed in responses. Neither conditionally nor allowed". > > RFC 3326 says in 1.0: > "[...] it can appear in any request > within a dialog, in any CANCEL request and in any response whose > status code explicitly allows the presence of this header field." > > To be honest, I believe Q.850 codes are much more common in > Responses than in requests. Googling "sip/2.0" reason "q.850" turns up numerous examples of SIP responses using the Reason header in the forbidden manner. I'd say that your draft formally allows what people are already doing. Dale From AUDET@nortel.com Thu Jul 16 10:16:46 2009 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 427B63A6D8C for ; Thu, 16 Jul 2009 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 5EvUFeTk4hiv for ; Thu, 16 Jul 2009 10:16:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 134B43A6D85 for ; Thu, 16 Jul 2009 10:16:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GHFMD18894; Thu, 16 Jul 2009 17:15:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2009 12:16:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 thread-index: AcoGOBA3gEoxC050SEGW+VhY0ywNJAAAB1FA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> From: "Francois Audet" To: "Dale Worley" Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 16 Jul 2009 17:16:46 -0000 Again, the spec is very clear that it IS allowed. I believe the wishy-washy text about "status code explicitly allowing it" was meant to exclude responses that were not appropriate, and restricing it to effectively error responses. At the time this was written, I believe we were not clear on which codes were supposed to be appropriate or not. Seems to me: - Any Error response code should be allowed. - I don't think 2XX makes sense. - 3XX is controversial (as per the email quoted by Roland): seems to me = it would be quite useful - Provisional is interesting... Sounds like 199 error response to me... > -----Original Message----- > From: Worley, Dale (BL60:9D30)=20 > Sent: Thursday, July 16, 2009 10:09 > To: Audet, Francois (SC100:3055) > Cc: R.Jesske@telekom.de; dispatch@ietf.org > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) wrote: > > Hi Roland, > >=20 > > You use case is very common. =20 > >=20 > > I believe you are incorrect in saying that "reasons are=20 > currently not=20 > > allowed in responses. Neither conditionally nor allowed". > >=20 > > RFC 3326 says in 1.0: > > "[...] it can appear in any request > > within a dialog, in any CANCEL request and in any response whose > > status code explicitly allows the presence of this header field." > >=20 > > To be honest, I believe Q.850 codes are much more common in=20 > Responses=20 > > than in requests. >=20 > Googling >=20 > "sip/2.0" reason "q.850" >=20 > turns up numerous examples of SIP responses using the Reason=20 > header in the forbidden manner. >=20 > I'd say that your draft formally allows what people are already doing. >=20 > Dale >=20 >=20 >=20 From AUDET@nortel.com Thu Jul 16 10:23:30 2009 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 A9EDF3A694D for ; Thu, 16 Jul 2009 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 qAWwsv4LA1MO for ; Thu, 16 Jul 2009 10:23:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 821053A6DB0 for ; Thu, 16 Jul 2009 10:23:29 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GGmlw12153; Thu, 16 Jul 2009 16:48:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2009 11:48:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 thread-index: AcoBl9goQeE8ND9yRoWluh5BWt1legB5v5vQAK0s4oA= References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de><1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com><9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de><1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: , "Dale Worley" Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 16 Jul 2009 17:23:30 -0000 Hi Roland, You use case is very common. =20 I believe you are incorrect in saying that "reasons are currently=20 not allowed in responses. Neither conditionally nor allowed". RFC 3326 says in 1.0: "[...] it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field." To be honest, I believe Q.850 codes are much more common in=20 Responses than in requests. > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: Sunday, July 12, 2009 23:17 > To: Worley, Dale (BL60:9D30) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi Dale, > The main probblem is that reasons are currently not allowed=20 > in responses. Neither conditionally nor allowed >=20 > Please see:=20 > http://www.ietf.org/mail-archive/web/sipping/current/msg09682.html >=20 > The draft tries to close this gap and allows conditionally=20 > Q.850 resasons within Resopnses. So it would be a service=20 > provider decision to include Reasons in Responses when=20 > mapping from ISUP to SIP. >=20 > The following call flow shows an example: >=20 > A Gateway Gateway B=20 > | IAM | | |=20 > |------------------>| INVITE | |=20 > | |----------------->| IAM |=20 > | | 100 Trying |----------------->|=20 > | |<-----------------| 100 Trying |=20 > | | 403 Decline | | > | | Reason Q850 #87 | REL Cause #87 | > | REL Cause #87 | |<-----------------|=20 > | |<-----------------| |=20 > |<----------------- | | |=20 > | | | |=20 > | | | |=20 > | | | |=20 >=20 > Due to RFC 3398 a 403 will be mapped back to a ISUP Cause 21.=20 > With the Reason in responses the Cause Value 87 will be=20 > secured and transferred back to ISUP. >=20 > Mheanwile I got some indications from some persons who see=20 > this issue within the BLISS group due to the fact that this=20 > draft solves interoperability issues within SIP and PSTN. >=20 > Views? >=20 > BR, >=20 > Roland > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dale Worley [mailto:dworley@nortel.com] > Gesendet: Freitag, 10. Juli 2009 21:52 > An: Jesske, Roland > Cc: dispatch@ietf.org > Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > On Tue, 2009-07-07 at 07:13 +0200, R.Jesske@telekom.de wrote: > > Hi Dale, > > Within the SIPPING group I had already discussions on that issue. > > The assumption was that the use of the Reason Header within=20 > Responses is conditionally allowed.=20 > >=20 > > The RFC 3326 says: > > Initially, the Reason header field defined here appears=20 > to be most > > useful for BYE and CANCEL requests, but it can appear in=20 > any request > > within a dialog, in any CANCEL request and in any response whose > > status code explicitly allows the presence of this header field. > >=20 > >=20 > > So we need a draft where it is stated that a reason header=20 > can be included within the SIP Response. That was also the=20 > recommendation of that discussion. That is why I wrote a draft. > > Nevertheless some standards already include this behaviour=20 > like the ITU-T Q.1912.5 specification. > > Also 3GPP needs the reason header within Responses. >=20 > It is still unclear to me what is being changed. Is the=20 > change the replacement of "conditionally allowed" to=20 > "allowed"? In any case, in my mind the purpose of the Reason=20 > header is to carry Q.850 cause-codes in failure responses. >=20 > The point is that the Abstract is not at all clear about the=20 > change from the status quo (at least to someone who isn't=20 > already thoroughly familiar with how Reason is currently specified). >=20 > And the secondary point is that if the Abstract was clearer=20 > about what it is being changed, more people might read and=20 > discuss the draft. >=20 > Dale >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From drage@alcatel-lucent.com Thu Jul 16 11:29:47 2009 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 7649C3A6C94 for ; Thu, 16 Jul 2009 11:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.971 X-Spam-Level: X-Spam-Status: No, score=-4.971 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 cKbVKW3-QmCZ for ; Thu, 16 Jul 2009 11:29:46 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 5669F3A6DD4 for ; Thu, 16 Jul 2009 11:29:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6GITkFV005156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jul 2009 20:29:46 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 16 Jul 2009 20:29:46 +0200 From: "DRAGE, Keith (Keith)" To: Francois Audet , Dale Worley Date: Thu, 16 Jul 2009 20:29:44 +0200 Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoGOBA3gEoxC050SEGW+VhY0ywNJAAAB1FAAAJILsA= Message-ID: References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 16 Jul 2009 18:29:47 -0000 If by "the spec" you are referring to the original Reason header RFC 3326, = then yes, it did not preclude it, but specifically indicated that any usage= had to be documented further. 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 whose status code explicitly allows the presence of this header field. There are no RFCs currently specifying the use with any status code. Note also that the rest of the text in the document is specifically about i= ts use in requests. If you go back, you will remember that Reason header was being addressed or= iginally at two problems. One was the issue of transferring clearing inform= ation from elsewhere in a BYE request, the other was the HERFP problem. The= latter was the use case that required things in a response, but there was = no agreement on the way forward on this part of the problem. Therefore the = Reason header draft was cut down only to address the first problem. I would note that the argument has been made in the past, and indeed is hin= ted at in RFC 3326, is that in responses, you should use the response code.= This is what SIP UAs are designed to understand and deal with on reception= . Therefore it has been stated in the past that if one wishes to deliver in= formation to end UAs that is not covered by the existing response codes, th= en a new status code should be defined. Therefore no general use of Reason = headers in responses was given in RFC 3326 for that reason. I did not origi= nate that argument, and maybe the people who gave that argument should spea= k up, but it is certainly the argument that shaped RFC 3326 the way it is. There is a case where you need to get information from a SIP UA acting as a= gateway to another SIP UA acting as a gateway and in that case the Reason = header in a response would be well justified in that case, and that is cert= ainly one of the cases covered by the draft. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Thursday, July 16, 2009 6:16 PM > To: Dale Worley > Cc: dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Again, the spec is very clear that it IS allowed. >=20 > I believe the wishy-washy text about "status code explicitly=20 > allowing it" was meant to exclude responses that were not=20 > appropriate, and restricing it to effectively error responses. >=20 > At the time this was written, I believe we were not clear on=20 > which codes were supposed to be appropriate or not. >=20 > Seems to me: > - Any Error response code should be allowed. > - I don't think 2XX makes sense. > - 3XX is controversial (as per the email quoted by Roland):=20 > seems to me it > would be quite useful > - Provisional is interesting... Sounds like 199 error=20 > response to me... >=20 > > -----Original Message----- > > From: Worley, Dale (BL60:9D30) > > Sent: Thursday, July 16, 2009 10:09 > > To: Audet, Francois (SC100:3055) > > Cc: R.Jesske@telekom.de; dispatch@ietf.org > > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois=20 > (SC100:3055) wrote: > > > Hi Roland, > > >=20 > > > You use case is very common. =20 > > >=20 > > > I believe you are incorrect in saying that "reasons are > > currently not > > > allowed in responses. Neither conditionally nor allowed". > > >=20 > > > RFC 3326 says in 1.0: > > > "[...] it can appear in any request > > > within a dialog, in any CANCEL request and in any=20 > response whose > > > status code explicitly allows the presence of this=20 > header field." > > >=20 > > > To be honest, I believe Q.850 codes are much more common in > > Responses > > > than in requests. > >=20 > > Googling > >=20 > > "sip/2.0" reason "q.850" > >=20 > > turns up numerous examples of SIP responses using the=20 > Reason header in=20 > > the forbidden manner. > >=20 > > I'd say that your draft formally allows what people are=20 > already doing. > >=20 > > Dale > >=20 > >=20 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From R.Jesske@telekom.de Thu Jul 16 22:08:19 2009 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 8BE0F3A6A24 for ; Thu, 16 Jul 2009 22:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 b3M5C-V82B90 for ; Thu, 16 Jul 2009 22:08:18 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 1768D3A6D4A for ; Thu, 16 Jul 2009 22:08:17 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 17 Jul 2009 07:08:43 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 07:08:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 07:08:42 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404A9B6A7@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoGOBNLYYxzk7cRQFCJwxePkwQePQAY9gnA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> From: To: , X-OriginalArrivalTime: 17 Jul 2009 05:08:43.0388 (UTC) FILETIME=[A7D4B3C0:01CA069C] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 17 Jul 2009 05:08:19 -0000 Hi Dale, You are right. The Q.850 causes will be used within ITU-T Q.1912.5 for = interworking SIP-ISUP and SIP-I. Within ETSI ES 383 001 for interworking SIP-ISUP and SIP-I. Within 3GPP TS 29.163 also interworking SIP with ISUP but there it is = referred to the regarding draft we are discussing. Also it is widely deployed also within our network. But nevertheless within 3GPP meetings I have got requests to progress = the ietf draft because people thinks that this is the way to ratify the = use of reason within responses. Best regards Roland -----Urspr=FCngliche Nachricht----- Von: Dale Worley [mailto:dworley@nortel.com]=20 Gesendet: Donnerstag, 16. Juli 2009 19:09 An: Francois Audet Cc: Jesske, Roland; dispatch@ietf.org Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) wrote: > Hi Roland, >=20 > You use case is very common. =20 >=20 > I believe you are incorrect in saying that "reasons are currently=20 > not allowed in responses. Neither conditionally nor allowed". >=20 > RFC 3326 says in 1.0: > "[...] it can appear in any request > within a dialog, in any CANCEL request and in any response whose > status code explicitly allows the presence of this header field." >=20 > To be honest, I believe Q.850 codes are much more common in=20 > Responses than in requests. Googling "sip/2.0" reason "q.850" turns up numerous examples of SIP responses using the Reason header in the forbidden manner. I'd say that your draft formally allows what people are already doing. Dale From R.Jesske@telekom.de Thu Jul 16 22:56:45 2009 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 859D83A6E28 for ; Thu, 16 Jul 2009 22:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ECRTGaXNBsrL for ; Thu, 16 Jul 2009 22:56:44 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 2E63B3A67ED for ; Thu, 16 Jul 2009 22:56:43 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 17 Jul 2009 07:57:07 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 07:57:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 07:59:30 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404A9B6D7@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1247763684.4085.21.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoGNxHV6QgqrAdhT7e9Epm/Rzi3RQAbJyDg References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1247763684.4085.21.camel@victoria-pingtel-com.us.nortel.com> From: To: X-OriginalArrivalTime: 17 Jul 2009 05:57:07.0833 (UTC) FILETIME=[6B03D690:01CA06A3] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 17 Jul 2009 05:56:45 -0000 Thank you Dale for your input. I have changed the Abstract. BR, Roland=20 -----Urspr=FCngliche Nachricht----- Von: Dale Worley [mailto:dworley@nortel.com]=20 Gesendet: Donnerstag, 16. Juli 2009 19:01 An: Jesske, Roland Cc: dispatch@ietf.org; esasaki@shui-usjapan.com Betreff: Re: AW: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 On Mon, 2009-07-13 at 08:16 +0200, R.Jesske@telekom.de wrote: > The main probblem is that reasons are currently not allowed in > responses. Neither conditionally nor allowed >=20 > Please see: = http://www.ietf.org/mail-archive/web/sipping/current/msg09682.html That clarifies things. Let me rephrase my complaint: Although the text of the RFC states "The Reason header field MAY appear in [...] any response whose status code explicitly allows the presence of this header field.", that text is stunningly unclear that the consequence is that the Reason header is not allowed in *any* defined response, and a casual reader might not realize that Reason is thus effectively forbidden in all responses. Expanding the Abstract along these lines would make the significance and importance of the draft much clearer: Although the use of the Reason header in responses is considered in RFC 3326, doing so is not specified for any existing response code. This document specifies the use of the Reason header field in SIP responses to carry Q.850 reason codes for the failure of an INVITE. =20 Dale From R.Jesske@telekom.de Thu Jul 16 23:06:52 2009 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 8426F3A6E25 for ; Thu, 16 Jul 2009 23:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 I8LfIWuz1kVM for ; Thu, 16 Jul 2009 23:06:51 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8169C3A6884 for ; Thu, 16 Jul 2009 23:06:47 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 17 Jul 2009 08:07:19 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 08:07:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 08:09:41 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404A9B6E4@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoBl9goQeE8ND9yRoWluh5BWt1legB5v5vQAK0s4oAAHBPS8A== References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de><1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com><9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de><1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 17 Jul 2009 06:07:19.0325 (UTC) FILETIME=[D77E1CD0:01CA06A4] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 17 Jul 2009 06:06:52 -0000 Hi Francois, The problem is that this is not the opinion I've got in the past. I = would have been happy if somebody had the same view on that issue as you = have now. And I have not seen any RFC that explicitly allows the use of Q.850 = causes within responses. Of course within ISUP the Release can be sent in both directions also = before and after Answer Message (equivalent to 200 OK). So a Release = Message within ISUP has the same functionality as a Response, CANCEL and = BYE. And that was not really taken into consideration when the Reason = Header was developed. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Francois Audet [mailto:audet@nortel.com]=20 Gesendet: Donnerstag, 16. Juli 2009 18:48 An: Jesske, Roland; Dale Worley Cc: dispatch@ietf.org Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Hi Roland, You use case is very common. =20 I believe you are incorrect in saying that "reasons are currently=20 not allowed in responses. Neither conditionally nor allowed". RFC 3326 says in 1.0: "[...] it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field." To be honest, I believe Q.850 codes are much more common in=20 Responses than in requests. > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: Sunday, July 12, 2009 23:17 > To: Worley, Dale (BL60:9D30) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi Dale, > The main probblem is that reasons are currently not allowed=20 > in responses. Neither conditionally nor allowed >=20 > Please see:=20 > http://www.ietf.org/mail-archive/web/sipping/current/msg09682.html >=20 > The draft tries to close this gap and allows conditionally=20 > Q.850 resasons within Resopnses. So it would be a service=20 > provider decision to include Reasons in Responses when=20 > mapping from ISUP to SIP. >=20 > The following call flow shows an example: >=20 > A Gateway Gateway B=20 > | IAM | | |=20 > |------------------>| INVITE | |=20 > | |----------------->| IAM |=20 > | | 100 Trying |----------------->|=20 > | |<-----------------| 100 Trying |=20 > | | 403 Decline | | > | | Reason Q850 #87 | REL Cause #87 | > | REL Cause #87 | |<-----------------|=20 > | |<-----------------| |=20 > |<----------------- | | |=20 > | | | |=20 > | | | |=20 > | | | |=20 >=20 > Due to RFC 3398 a 403 will be mapped back to a ISUP Cause 21.=20 > With the Reason in responses the Cause Value 87 will be=20 > secured and transferred back to ISUP. >=20 > Mheanwile I got some indications from some persons who see=20 > this issue within the BLISS group due to the fact that this=20 > draft solves interoperability issues within SIP and PSTN. >=20 > Views? >=20 > BR, >=20 > Roland > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dale Worley [mailto:dworley@nortel.com] > Gesendet: Freitag, 10. Juli 2009 21:52 > An: Jesske, Roland > Cc: dispatch@ietf.org > Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > On Tue, 2009-07-07 at 07:13 +0200, R.Jesske@telekom.de wrote: > > Hi Dale, > > Within the SIPPING group I had already discussions on that issue. > > The assumption was that the use of the Reason Header within=20 > Responses is conditionally allowed.=20 > >=20 > > The RFC 3326 says: > > Initially, the Reason header field defined here appears=20 > to be most > > useful for BYE and CANCEL requests, but it can appear in=20 > any request > > within a dialog, in any CANCEL request and in any response whose > > status code explicitly allows the presence of this header field. > >=20 > >=20 > > So we need a draft where it is stated that a reason header=20 > can be included within the SIP Response. That was also the=20 > recommendation of that discussion. That is why I wrote a draft. > > Nevertheless some standards already include this behaviour=20 > like the ITU-T Q.1912.5 specification. > > Also 3GPP needs the reason header within Responses. >=20 > It is still unclear to me what is being changed. Is the=20 > change the replacement of "conditionally allowed" to=20 > "allowed"? In any case, in my mind the purpose of the Reason=20 > header is to carry Q.850 cause-codes in failure responses. >=20 > The point is that the Abstract is not at all clear about the=20 > change from the status quo (at least to someone who isn't=20 > already thoroughly familiar with how Reason is currently specified). >=20 > And the secondary point is that if the Abstract was clearer=20 > about what it is being changed, more people might read and=20 > discuss the draft. >=20 > Dale >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From R.Jesske@telekom.de Thu Jul 16 23:31:08 2009 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 03D563A68BE for ; Thu, 16 Jul 2009 23:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 oACLACVbU8ww for ; Thu, 16 Jul 2009 23:31:06 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 456443A6359 for ; Thu, 16 Jul 2009 23:31:06 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 17 Jul 2009 08:30:29 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 08:30:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 08:33:21 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404A9B71F@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoGOBA3gEoxC050SEGW+VhY0ywNJAAAB1FAAAJILsAAGTjr4A== References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de><1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com><9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de><1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com><9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de><1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com><1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 17 Jul 2009 06:30:29.0935 (UTC) FILETIME=[145C5BF0:01CA06A8] Cc: ericksasaki@sbcglobal.net, dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 17 Jul 2009 06:31:08 -0000 Hi, With regard to Keith's answer I see that the draft is needed. But where should this be done? BLISS, DISPATCH or SIPCORE? We have now the discussion within DISPATCH due to the fact that the = draft was issued for the sipping group. The issue shall solve interoperability problems with the PSTN where = Q.850 causes shall be transferred through SIP. An other used case is where applications within SIP networks could = interpret the Reason header to put an announcement towards a user. This = is important within Hybrid networks where SIP and ISUP runs in parallel. Seen from this point of view the work should be done within BLISS to = solve this interoperability problem. RFC3326 was done within SIP and the draft could be seen as an extension = to this RFC so that could be a reason to do this within SIPCORE. Or the discussion takes place within DISPATCH and the draft was brought = to SIPPING. So how to proceed? BR Roland -----Urspr=FCngliche Nachricht----- Von: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Gesendet: Donnerstag, 16. Juli 2009 20:30 An: Francois Audet; Dale Worley Cc: dispatch@ietf.org; Jesske, Roland Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 If by "the spec" you are referring to the original Reason header RFC = 3326, then yes, it did not preclude it, but specifically indicated that = any usage had to be documented further. 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 whose status code explicitly allows the presence of this header field. There are no RFCs currently specifying the use with any status code. Note also that the rest of the text in the document is specifically = about its use in requests. If you go back, you will remember that Reason header was being addressed = originally at two problems. One was the issue of transferring clearing = information from elsewhere in a BYE request, the other was the HERFP = problem. The latter was the use case that required things in a response, = but there was no agreement on the way forward on this part of the = problem. Therefore the Reason header draft was cut down only to address = the first problem. I would note that the argument has been made in the past, and indeed is = hinted at in RFC 3326, is that in responses, you should use the response = code. This is what SIP UAs are designed to understand and deal with on = reception. Therefore it has been stated in the past that if one wishes = to deliver information to end UAs that is not covered by the existing = response codes, then a new status code should be defined. Therefore no = general use of Reason headers in responses was given in RFC 3326 for = that reason. I did not originate that argument, and maybe the people who = gave that argument should speak up, but it is certainly the argument = that shaped RFC 3326 the way it is. There is a case where you need to get information from a SIP UA acting = as a gateway to another SIP UA acting as a gateway and in that case the = Reason header in a response would be well justified in that case, and = that is certainly one of the cases covered by the draft. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Thursday, July 16, 2009 6:16 PM > To: Dale Worley > Cc: dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Again, the spec is very clear that it IS allowed. >=20 > I believe the wishy-washy text about "status code explicitly=20 > allowing it" was meant to exclude responses that were not=20 > appropriate, and restricing it to effectively error responses. >=20 > At the time this was written, I believe we were not clear on=20 > which codes were supposed to be appropriate or not. >=20 > Seems to me: > - Any Error response code should be allowed. > - I don't think 2XX makes sense. > - 3XX is controversial (as per the email quoted by Roland):=20 > seems to me it > would be quite useful > - Provisional is interesting... Sounds like 199 error=20 > response to me... >=20 > > -----Original Message----- > > From: Worley, Dale (BL60:9D30) > > Sent: Thursday, July 16, 2009 10:09 > > To: Audet, Francois (SC100:3055) > > Cc: R.Jesske@telekom.de; dispatch@ietf.org > > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois=20 > (SC100:3055) wrote: > > > Hi Roland, > > >=20 > > > You use case is very common. =20 > > >=20 > > > I believe you are incorrect in saying that "reasons are > > currently not > > > allowed in responses. Neither conditionally nor allowed". > > >=20 > > > RFC 3326 says in 1.0: > > > "[...] it can appear in any request > > > within a dialog, in any CANCEL request and in any=20 > response whose > > > status code explicitly allows the presence of this=20 > header field." > > >=20 > > > To be honest, I believe Q.850 codes are much more common in > > Responses > > > than in requests. > >=20 > > Googling > >=20 > > "sip/2.0" reason "q.850" > >=20 > > turns up numerous examples of SIP responses using the=20 > Reason header in=20 > > the forbidden manner. > >=20 > > I'd say that your draft formally allows what people are=20 > already doing. > >=20 > > Dale > >=20 > >=20 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From sdoken@qualcomm.com Fri Jul 17 00:55:37 2009 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 C89EB3A6A2E for ; Fri, 17 Jul 2009 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_33=0.6, 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 gRhqWYQielWW for ; Fri, 17 Jul 2009 00:55:36 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 406513A683B for ; Fri, 17 Jul 2009 00:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1247817369; x=1279353369; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "Jain,=20Rajnish"=20,=0D=0A=20=20 =20=20=20=20=20=20Vijay=20Gurbani=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"dispatch@ietf.or g"=20|Date:=20Fri,=2017=20Jul=202009 =2000:56:03=20-0700|Subject:=20RE:=20[dispatch]=20Session =20Recording=20in=20SIP|Thread-Topic:=20[dispatch]=20Sess ion=20Recording=20in=20SIP|Thread-Index:=20Acny7zk28PigrO +0SryRcGZzpsB+WwLm/JUQAgaJJ4A=3D|Message-ID:=20|References:=20<4A3F03F6.6060505@alcatel-lucent.com> =0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5678"=3B=20a=3D"20860033"; bh=ut9/j6lteMSkuipJm0j/5dOfNBg82vCsiM6aTO/mzGQ=; b=yIhmyvtbZOPQfqSHqcX4DXoaR4H11emBDyK4LvkXP0nLicr5S8YZW7Um lMObMweG5V6Oklrs6kR+t31n4Qyn526edSDzCvFo+hRx2EXgofR208clQ FxX3epA4b7o7zqPrZ1fDvponduq5VeeYJfTmTRzts8ZFNLoq51cDEyml4 k=; X-IronPort-AV: E=McAfee;i="5300,2777,5678"; a="20860033" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2009 00:56:09 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6H7u95p005538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Jul 2009 00:56:09 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6H7u6Hv018855 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Jul 2009 00:56:08 -0700 (PDT) Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.121]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 17 Jul 2009 00:56:06 -0700 From: "Doken, Serhad" To: "Jain, Rajnish" , Vijay Gurbani , "dispatch@ietf.org" Date: Fri, 17 Jul 2009 00:56:03 -0700 Thread-Topic: [dispatch] Session Recording in SIP Thread-Index: Acny7zk28PigrO+0SryRcGZzpsB+WwLm/JUQAgaJJ4A= Message-ID: References: <4A3F03F6.6060505@alcatel-lucent.com> 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] Session Recording in SIP 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, 17 Jul 2009 07:55:37 -0000 I read this draft and following are my comments : Section 3 Definitions Perhaps Recording Server(RS) should simply be called Recorder. I see the no= te on the last sentence however as long as definitions refer to Client and = Server, it will always imply to the reader to think that RS is the server. = The statement that SRP may be SIP is an understatement since the definition= for RC already referred to as a SIP UA/B2BUA. Dynamic Recording, if the recording session is started and ended at random = points on demand, its length will not be the same as actual media session. Persistent Recording, it is not clear what is meant by "system start up". I= s "system" referring to RC or RS ?=20 Depending on the answer, I am curious how are these persistent recording se= ssions are correlated to many active media sessions and what would be mecha= nism to keep them alive ? What is the number of persistent recording sessio= ns per RC/RS ?=20 Perhaps implications of this should be covered somewhere else, maybe in the= requirements section ? Section 5 Requirements REQ-006 Not a good idea to talk about the solution here and how some RC imp= lementations handle the problem. Perhaps REQ-010 and 011 can be combined into one by just saying "over a sin= gle or separate". REQ-018 can be extended to say that the mechanism MUST support the ability = to find out the associated recorded session(s) given that one(for instance = RS) is only aware of recording session(s). I'd rather prefer this to be a s= eparate requirement.=20 I have another requirement in mind : The mechanism MUST support the ability= to setup recording sessions that will record different conversation direct= ions of the Recorded session(s) from RC(s) and they too should be correlate= d accordingly. For instance, while an agent is talking to a customer, there= should be a way to setup two recording sessions, one carrying the media fr= om agent towards customer and vice versa for the other. Furthermore, these = recording sessions should be marked as such in SRP. REQ-021 talks about a mode where RC just forks media to RS. However, there = is value in studying transcoding, media incompatibility use cases and see i= f there are requirements they bring given that RS/RCs are/will most likely = have different media capabilities. If recorded session media is stopped/temporarily interrupted due to problem= s or features invoked on it(recording session is put on hold or started a c= onferencing or transfer operation), how does that affect the already setup = recording session(s) ? Nit : Section2, sentence that starts with "that draft focuses on the mechanism to= provide the SRTP...." is odd. It is clear that srtp-key draft is not for s= ession recording, so no need to state the obvious. Regards, Serhad Doken > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Jain, Rajnish > Sent: Monday, July 06, 2009 3:48 PM > To: Vijay Gurbani; dispatch@ietf.org > Subject: Re: [dispatch] Session Recording in SIP >=20 > All: The following draft on SIP session recording requirements was > submitted today: >=20 > http://www.ietf.org/internet-drafts/draft-jain-dispatch-session- > recording-protocol-req-00.txt >=20 > Title: Requirements for Session Recording Protocol (SRP) >=20 > Abstract: > Session recording is a critical requirement in many business > communications environments such as call centers and financial > trading floors. In some of these environments, all calls must be > recorded for regulatory and compliance reasons. In others, calls may > be recorded for quality control or business analytics. Recording is > typically done by sending a copy of the media to the recording > devices. This document specifies requirements for a protocol that > will manage delivery of media from an end-point that originates media > or that has access to it to a recording device. This protocol is > being referred to as Session Recording Protocol and will most likely > be based on SIP. >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > > Of Vijay Gurbani > > Sent: Monday, June 22, 2009 12:09 AM > > To: dispatch@ietf.org > > Subject: [dispatch] Summary on Session Recording in SIP > > > > All: Here is the summary of the Session Recording thread from June 9 > > to June 19, 2009. If I misrepresented anything, please let me know. > > > > There was a fair amount of discussion on where to conduct this > > work. In the end, it was decided to continue discussions on > > dispatch, further decisions what to do -- new working group or > > put this work in an existing working group -- will be decided > > later. Regardless of where the work is done, opinions were > > expressed that the work is important that it should commence > > in the IETF. > > > > Need to be crisp about the purpose of this work: is it that users > > record sessions to hear later, or sessions need to be recorded > > because of some business needs? Or both? Is SRTP covered or > > only RTP? > > > > Solutions should cover: > > Always on recording > > Recording on demand > > Required recording > > Pause and resume recording > > Playback facilities and how they interact with recording > > Recording formats and protocols for controlling the stored > recording. > > > > A lot of discussion ensued on the specific architecture or > > architectures that would be possible. No decision was reached on > > which specific architecture is good or bad, although various opinions > > were expressed in support for each. > > > > There are essentially four architectures to realize recording > > services: two that discuss where the media stream is forked > > out to the recorder -- at the UA or in a middlebox of some > > sort are outlined here: > > http://www.ietf.org/mail- > archive/web/dispatch/current/msg00226.html > > > > The third architecture has both UAs sending media to a > > recorder. See: > > http://www.ietf.org/mail- > archive/web/dispatch/current/msg00236.html > > > > A fourth architecture that is a superset of the third one is at: > > http://www.ietf.org/mail- > archive/web/dispatch/current/msg00256.html > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > WWW: http://ect.bell-labs.com/who/vkg > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the > sender that you have received it in error. Unintended recipients are > prohibited from taking action on the basis of information in this e- > mail.E-mail messages may contain computer viruses or other defects, may > not be accurately replicated on other systems, or may be intercepted, > deleted or interfered with without the knowledge of the sender or the > intended recipient. If you are not comfortable with the risks > associated with e-mail messages, you may decide not to use e-mail to > communicate with IPC. IPC reserves the right, to the extent and under > circumstances permitted by applicable law, to retain, monitor and > intercept e-mail messages to and from its systems. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Fri Jul 17 08:06:26 2009 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 7C08B3A6E83 for ; Fri, 17 Jul 2009 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.343 X-Spam-Level: X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 fch4nNsERass for ; Fri, 17 Jul 2009 08:06:25 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2FB0C3A6DB2 for ; Fri, 17 Jul 2009 08:06:25 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6HF57s03060; Fri, 17 Jul 2009 15:05:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 10:07:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F0AA26E@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404A9B71F@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 thread-index: AcoGOBA3gEoxC050SEGW+VhY0ywNJAAAB1FAAAJILsAAGTjr4AASIwZQ References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de><1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com><9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de><1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com><9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de><1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com><1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A9B71F@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , , "Francois Audet" , "Dale Worley" Cc: ericksasaki@sbcglobal.net, dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 17 Jul 2009 15:06:26 -0000 Hi Roland, I think DISPATCH remains the appropriate place for these discussions. = If we did agree specific changes to RFC 3326, that work would not fall = under the charter of SIPCORE (as it's currently scoped as I understand = it). =20 It's not clear to me that this fits the scope of BLISS in that the focus = of this document is on the clarifications to RFC 3326 to support certain = services/environments. It's not under the purview of BLISS to make SIP = protocol changes. [I will note that the BLISS charter needs to be = updated to reflect how it does interface with SIPCORE and DISPATCH, = rather than SIP and SIPPING as it's currently stated.] I do see that = more details of services that would need this reason header might fall = into the BLISS WG charter. My suggestion is that you update the document to incorporate the = conclusions of this discussion ( the doc is currently expired) - you'll = have to wait for the document submissions to be opened again on July = 27th. In my view, the crux of a work item is whether you need a true = update to RFC 3326 or whether you are documenting clarifications - = similar to the sip-offeranswer document in SIPPING. =20 Regards, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of R.Jesske@telekom.de Sent: Friday, July 17, 2009 1:33 AM To: drage@alcatel-lucent.com; Audet, Francois (SC100:3055); Worley, Dale = (BL60:9D30) Cc: ericksasaki@sbcglobal.net; dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Hi, With regard to Keith's answer I see that the draft is needed. But where should this be done? BLISS, DISPATCH or SIPCORE? We have now the discussion within DISPATCH due to the fact that the = draft was issued for the sipping group. The issue shall solve interoperability problems with the PSTN where = Q.850 causes shall be transferred through SIP. An other used case is where applications within SIP networks could = interpret the Reason header to put an announcement towards a user. This = is important within Hybrid networks where SIP and ISUP runs in parallel. Seen from this point of view the work should be done within BLISS to = solve this interoperability problem. RFC3326 was done within SIP and the draft could be seen as an extension = to this RFC so that could be a reason to do this within SIPCORE. Or the discussion takes place within DISPATCH and the draft was brought = to SIPPING. So how to proceed? BR Roland -----Urspr=FCngliche Nachricht----- Von: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Gesendet: Donnerstag, 16. Juli 2009 20:30 An: Francois Audet; Dale Worley Cc: dispatch@ietf.org; Jesske, Roland Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 If by "the spec" you are referring to the original Reason header RFC = 3326, then yes, it did not preclude it, but specifically indicated that = any usage had to be documented further. 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 whose status code explicitly allows the presence of this header field. There are no RFCs currently specifying the use with any status code. Note also that the rest of the text in the document is specifically = about its use in requests. If you go back, you will remember that Reason header was being addressed = originally at two problems. One was the issue of transferring clearing = information from elsewhere in a BYE request, the other was the HERFP = problem. The latter was the use case that required things in a response, = but there was no agreement on the way forward on this part of the = problem. Therefore the Reason header draft was cut down only to address = the first problem. I would note that the argument has been made in the past, and indeed is = hinted at in RFC 3326, is that in responses, you should use the response = code. This is what SIP UAs are designed to understand and deal with on = reception. Therefore it has been stated in the past that if one wishes = to deliver information to end UAs that is not covered by the existing = response codes, then a new status code should be defined. Therefore no = general use of Reason headers in responses was given in RFC 3326 for = that reason. I did not originate that argument, and maybe the people who = gave that argument should speak up, but it is certainly the argument = that shaped RFC 3326 the way it is. There is a case where you need to get information from a SIP UA acting = as a gateway to another SIP UA acting as a gateway and in that case the = Reason header in a response would be well justified in that case, and = that is certainly one of the cases covered by the draft. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Thursday, July 16, 2009 6:16 PM > To: Dale Worley > Cc: dispatch@ietf.org; R.Jesske@telekom.de > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Again, the spec is very clear that it IS allowed. >=20 > I believe the wishy-washy text about "status code explicitly allowing=20 > it" was meant to exclude responses that were not appropriate, and=20 > restricing it to effectively error responses. >=20 > At the time this was written, I believe we were not clear on which=20 > codes were supposed to be appropriate or not. >=20 > Seems to me: > - Any Error response code should be allowed. > - I don't think 2XX makes sense. > - 3XX is controversial (as per the email quoted by Roland):=20 > seems to me it > would be quite useful > - Provisional is interesting... Sounds like 199 error response to=20 > me... >=20 > > -----Original Message----- > > From: Worley, Dale (BL60:9D30) > > Sent: Thursday, July 16, 2009 10:09 > > To: Audet, Francois (SC100:3055) > > Cc: R.Jesske@telekom.de; dispatch@ietf.org > > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois > (SC100:3055) wrote: > > > Hi Roland, > > >=20 > > > You use case is very common. =20 > > >=20 > > > I believe you are incorrect in saying that "reasons are > > currently not > > > allowed in responses. Neither conditionally nor allowed". > > >=20 > > > RFC 3326 says in 1.0: > > > "[...] it can appear in any request > > > within a dialog, in any CANCEL request and in any > response whose > > > status code explicitly allows the presence of this > header field." > > >=20 > > > To be honest, I believe Q.850 codes are much more common in > > Responses > > > than in requests. > >=20 > > Googling > >=20 > > "sip/2.0" reason "q.850" > >=20 > > turns up numerous examples of SIP responses using the > Reason header in > > the forbidden manner. > >=20 > > I'd say that your draft formally allows what people are > already doing. > >=20 > > Dale > >=20 > >=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 dworley@nortel.com Fri Jul 17 11:50:59 2009 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 AF72A3A6CCA for ; Fri, 17 Jul 2009 11:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.689 X-Spam-Level: X-Spam-Status: No, score=-6.689 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 NqtDLSYSkneb for ; Fri, 17 Jul 2009 11:50:58 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ACB553A69A3 for ; Fri, 17 Jul 2009 11:50:58 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6HHwus06509; Fri, 17 Jul 2009 17:58:56 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 14:00:38 -0400 From: "Dale Worley" To: R.Jesske@telekom.de In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404A9B6D7@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1247763684.4085.21.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A9B6D7@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 17 Jul 2009 14:00:37 -0400 Message-Id: <1247853637.3780.25.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 18:00:38.0185 (UTC) FILETIME=[7D99E190:01CA0708] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 17 Jul 2009 18:50:59 -0000 Thinking about this discussion, I would add a sentence to the abstract telling the reader that the Reason header in responses is widely used, even though it is not officially specified. Something along these lines: Although the use of the Reason header field in responses is considered in RFC 3326, doing so is not specified for any existing response code. Nonetheless, the Reason header field has been widely used in responses to carry Q.850 reason codes for failure responses to INVITEs that have been gatewayed to PSTN systems. 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. I think that makes the current situation clear to the uninformed reader (e.g., me), and it only requires 3 sentences. Dale From dworley@nortel.com Fri Jul 17 12:33:28 2009 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 85A643A68EF for ; Fri, 17 Jul 2009 12:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.686 X-Spam-Level: X-Spam-Status: No, score=-6.686 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 srr8VXF5W5ZH for ; Fri, 17 Jul 2009 12:33:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 053363A67C2 for ; Fri, 17 Jul 2009 12:33:26 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6HJXuo28217 for ; Fri, 17 Jul 2009 19:33:56 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:33:55 -0400 From: "Dale Worley" To: DISPATCH Content-Type: text/plain Organization: Nortel Networks Date: Fri, 17 Jul 2009 15:33:55 -0400 Message-Id: <1247859235.3780.28.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 19:33:55.0782 (UTC) FILETIME=[86076660:01CA0715] Subject: [dispatch] Questions regarding draft-kaplan-sipping-interop-bcp-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: Fri, 17 Jul 2009 19:33:28 -0000 Section 2: There are two broad areas of SIP interoperation. One is "phone to PBX", which is assumed to be between a UA and a proxy for its domain. The other is "SIP trunking", that is, between two proxies, often in different administrative domains. The recommendations in this draft seem to cover both areas, and it's likely that the two areas cannot be clearly separated. Nonetheless, a naive reader (me) would likely infer from the author's employer that the draft only covers "SIP trunking" problems. An expansion of the Applicability section would dispel this misinterpretation earlier in the text, and would prevent some readers from leaving off finishing reading the document. Section 4.3: Just after the regexp is the statement "Note this is after removing visual-separators, and any user parameters." Given he need for accuracy here, this statement is problematic because "visual-separator" is not a defined term in regard to SIP URIs (although it is for tel: URIs), and "user parameter" is not defined at all in the grammar (although people generally know what the term means). The initial part of a SIP URI is officially called "user". Isn't the maximum length of an E.164 number 15 digits? If so, why are 16-digit numbers also restricted? A more clearly defined specification is: It is RECOMMENDED that SIP domains not allocate SIP URI AoR user parts which match the following regular expression syntax, unless the URI is intended to have the same significance as the corresponding E.164 number: ^+?([-.()]*[0-9]){11,16}[-.()]*(;.*)?$ This regular expression is to be compared to the user part after removing any escaping. The characters "*" and "#", although allowed in tel: URIs, are not allowed in E.164 numbers, and so user parts containing them are not included in this prohibition. In regard to the statement It is RECOMMENDED, that the SIP Working Group address the fundamental issue of E.164 or telephone number scope in SIP URI's. I don't see what issue needs to be addressed, as the working group's opinion is well-defined and well-known, and nobody has advanced any argument to change it. The TEL URI also has specific syntactic and usage issues beyond simply lack of broad industry support, which may be a reason for not supporting it. This is more interesting, since the question to be answered is "Why don't implementers follow the clear intention of the specification, and what might be done about that?" In regard to the URI schemes that are used in various locations, we need a general statement that elements should tolerate sip:, sips:, and tel: URIs in all situations, excepting when the element must understand the URI to process the message. E.g., there is no excuse for rejecting a syntactically correct From URI, because an element never needs to understand the semantics of the From URI. Similarly, there are situations where a default action is specified to be taken when the element does not understand a URI which might otherwise cause it to take specific action. In such cases, an element should take the default action for such URIs rather than rejecting the message outright. Section 4.4: Although the Tel URI has not seen much usage itself using the "tel" scheme, it is quite common to see SIP URI's containing Tel-URI parameters - i.e., Tel URI's in the form of SIP URI's. There are many URI parameters defined for Tel-URI that are popular, and thus frequently appear in SIP URI's, for example in the request-URI. What is not made clear here is that these parameters show up as "user-part parameters", which is a syntax feature not defined in RFC 3261. Naively, the above paragraph suggests that these parameters show up as URI-parameters. This could be fixed by amending the first sentence to say "... quite common to see SIP URI's user-parts containing Tel-URI parameters ...", and adding an example: "E.g., sip:+12125551212;phone-context=example.com@example.net" The most common interoperability problem in this area is the placement of the Tel URI parameters, for example the "tgrp" and "trunk-context" parameters from [RFC4904], and the "rn", "npdi", and "cic" parameters from [RFC4694]. RFC 3261 section 19.1.6 is very clear that the entire telephone-subscriber portion, including parameters, is placed in the userinfo portion of a SIP URI. Thus the Tel-URI parameters become user parameters for SIP, not SIP URI parameters. "userinfo portion" should be "user portion", as the SIP URI syntax allows phone numbers to be followed by a password part, and presumably such an inserted telephone-subscriber portion can be followed by a password part (yuck). Section 5.1: In regard to failure responses to REGISTER requests: [What can we say here that UA's will actually do?] "In any circumstance the UA MUST take care that it never generates retries of requests without using a suitable back-off strategy. If the UA receives a response which suggests that a particular modification of the request is likely to be successful, it MAY send the modified request immediately. The UA MAY NOT retry any failing request with a long-term average frequency of more than one request sent (new client transaction initiated) per 5 minutes regardless of what responses it receives." Making sure that UAs do not flood systems is a critical need. Section 5.2: Let's add "SIP elements MUST process provided Contact URIs opaquely." Section 5.5: Shouldn't this section refer to sections 2.4 to 2.6 (various forms of transfer) in RFC 5359 (the service examples RFC)? Section 6.1: I suggest softening the first recommendation to require SDP only in initial INVITEs, but permitting offer-less re-INVITEs. The latter is very useful in implementing MOH, and since the dialog path is already established, it is unambiguous what media/codecs the UAS and the middleboxes support/permit *in that dialog*, even if call routing is affected by media/codecs. Section 6.4: [Note: one trick some vendors use is to pretend the unacceptable response was not received and send a CANCEL - should we recommend that?] That's an interesting idea, since it seems to permit the INVITE to fail-over to another destination which might generate an acceptable answer. But thinking more about it, I don't think that works -- the CANCEL gets a 200 response but doesn't do anything (since the UAS has already progressed the dialog to confirmed), and the UAS will retransmit the 200. What is needed is to eat the 200 response with the unacceptable answer so that all upstream proxies have a chance to fork the request to additional destinations. But that means that the proxy that eats the 200 must be well downstream, near the UAS that generated the 200, but must know what the UAC considers unacceptable. It's hard to make that work unless the proxy that eats the 200 is also the one that generates further forks, and also services the UAC. The only workable solution I can think of is for the INVITE to carry "Request-Disposition: no-cancel" so that the intermediate proxies continue to generate forks even though one UAS responds 200. Then the UAC will receive all the 200s as they are generated. If it doesn't like the answer in one 200, it can BYE that dialog. If it receives a 200 with an answer it likes, it can then CANCEL the INVITE to suppress further forking. That's messy, but it might make sense for a UAC to use it as a fallback strategy. Assuming that the intermediate proxies support Request-Disposition, it is even standardized. Section 7: The Call-Info header is used in the call-completion architecture (draft-bliss-ietf-call-completion). I suspect that many other "rare" headers are used sporadically in other situations. A better recommendation is to remind implementers that an implementation MUST ignore header fields, URI-parameters, and header-parameters that it does not understand. Conversely, implementations MUST reject requests with unknown option-tags in Require header fields. If implementations follow these rules, extraneous information should not cause interoperation problems, since SIP features are designed (remarkably carefully!) to be upward-compatible under these rules. Dale From dworley@nortel.com Fri Jul 17 13:13:23 2009 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 ECD5E28C1EF for ; Fri, 17 Jul 2009 13:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.681 X-Spam-Level: X-Spam-Status: No, score=-6.681 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 wbMbzWjnxcER for ; Fri, 17 Jul 2009 13:13:22 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ADE4A28C2AE for ; Fri, 17 Jul 2009 13:13:01 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6HJhvV27977 for ; Fri, 17 Jul 2009 19:43:57 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:45:37 -0400 From: "Dale Worley" To: DISPATCH In-Reply-To: References: <6EA53FAD386F9D46B97D49BFE148D5148CE34B@ISR-JLM-MAIL1.xconnect.co.il> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 17 Jul 2009 15:45:37 -0400 Message-Id: <1247859937.3780.36.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 19:45:37.0831 (UTC) FILETIME=[287B9370:01CA0717] Subject: Re: [dispatch] [Sipping] I-D Action:draft-kaplan-sipping-interop-bcp-02.txt 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, 17 Jul 2009 20:13:23 -0000 On Mon, 2009-07-13 at 02:00 -0400, Hadriel Kaplan wrote: > p.s. My guess is that it's not because they can't generate a 604 > physically, but rather that the systems can't consistently and > programmatically know when it would be correct to do so. That's exactly the problem -- a 604 doesn't mean "the request-URI cannot be reached", it means "the request-URI of the *original* request cannot be reached". But the UAS cannot know the original request-URI, so it can never validly generate any 6xx-class response. See draft-worley-6xx-considered-harmful for a whine about this... Dale From rjsparks@nostrum.com Fri Jul 17 14:15:14 2009 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 E95503A6AE5; Fri, 17 Jul 2009 14:15:14 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 MzWY58jY95Sy; Fri, 17 Jul 2009 14:15:13 -0700 (PDT) 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 1EFFD3A68EC; Fri, 17 Jul 2009 14:15:09 -0700 (PDT) Received: from dn3-232.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 n6HLFf4C098114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jul 2009 16:15:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: sip-ops@ietf.org, dispatch mailing list Content-Type: multipart/alternative; boundary=Apple-Mail-140--1024798114 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 17 Jul 2009 16:15:41 -0500 References: X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [dispatch] Fwd: draft CLF charter 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, 17 Jul 2009 21:15:15 -0000 --Apple-Mail-140--1024798114 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Please follow and participate in this discussion on the sip-clf list if you are interested. RjS Begin forwarded message: > From: Robert Sparks > Date: July 17, 2009 4:13:58 PM CDT > To: sip-clf@ietf.org > Subject: draft CLF charter > > All - > > We are working on forming a CLF working group based on DISPATCH's > decision. > > Below is a proposed charter for this working group. Please review > and comment > on this list. Depending on the feedback we receive, we will target > forming this > group shortly after the Stockholm meeting. > > We'll also be discussing this in Thursday's opsarea meeting. > > Thanks, > > RjS > > >> The SIP Common Log File (CLF) working group is chartered to define >> a standard logging format for systems processing SIP messages. >> >> Well-known web servers such as Apache and web proxies like Squid >> support event logging using a common log format. The logs produced >> using these de-facto standard formats are invaluable to system >> administrators for trouble-shooting a server and tool writers to >> craft tools that mine the log files to produce reports and trends >> and to search for a certain SIP message or messages, a transaction >> or a related set of transactions. Furthermore, these log records >> can also be used to train anomaly detection systems and feed events >> into a security event management system. >> >> The Session Initiation Protocol does not have a common log >> format. Diverse element provide distinct log formats making >> it complex to produce tools to analyze them. >> >> The CLF working group will produce a format suitable for logging >> from any SIP element. The format will anticipate the need to >> search, merge, and summarize the log records from diverse elements. >> The format will anticipate the need to correlate messages from >> multiple elements related to a given request (that may fork) >> or a given dialog. The format will take SIP's extensibility into >> consideration, providing a way to represent SIP message components >> that are defined in the future. The format will anticipate being >> used both for off-line analysis and on-line real-time processing >> applications. The working group will consider the need for >> efficient processing in its design of this format. >> >> The working group is not pre-constrained to producing either a >> bit-field oriented or text-oriented format, and may choose to >> provide both. If the group chooses to specify both, it must be >> possible to mechanically translate between the formats without >> loss of information. >> >> Specifying the mechanics of exchanging, transporting, and storing >> SIP Common Log Format records is explicitly out of scope. Specifying >> a real-time transfer mechanism for heuristic analysis is explicitly >> out of scope. >> >> The group will generate: >> >> - A problem statement enunciating the motivation, >> and use cases for a SIP Common Log Format. This analysis >> will identify the required minimal information that must >> appear in any record. >> >> - A specification of the SIP Common Log Format record. >> >> The group will consider providing one or more reference >> implementations for decoding a CLF record. >> >> Goals and Milestones >> =========================== >> >> Nov 09 - Problem statement, motivation, and use cases to IESG >> (Informational) >> Feb 10 - SIP Common Log Format specification to IESG (PS) >> > --Apple-Mail-140--1024798114 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Please follow and participate = in this discussion on the sip-clf list if you are = interested.

RjS

Begin = forwarded message:

From: = Robert Sparks <rjsparks@nostrum.com>
Date: July 17, 2009 4:13:58 PM = CDT
Subject: = draft CLF charter

All -

We are working on = forming a CLF working group based on DISPATCH's decision.

Below = is a proposed charter for this working group. Please review and = comment
on this list. Depending on the feedback we receive, we will = target forming this
group shortly after the Stockholm = meeting.

We'll also be discussing this in Thursday's opsarea = meeting.

Thanks,

RjS


The SIP Common Log File (CLF) working group is chartered = to define
a standard logging = format for systems processing SIP messages.

Well-known web = servers such as Apache and web proxies like = Squid
support event logging = using a common log format.  The logs = produced
using these de-facto = standard formats are invaluable to system
administrators for trouble-shooting a server and tool = writers to
craft tools that = mine the log files to produce reports and = trends
and to search for a = certain SIP message or messages, a = transaction
or a related set = of transactions.  Furthermore, these log = records
can also be used to = train anomaly detection systems and feed = events
into a security event = management system.

The Session = Initiation Protocol does not have a common = log
format. Diverse element = provide distinct log formats making
it complex to produce tools to analyze = them.

The CLF working = group will produce a format suitable for = logging
from any SIP element. = The format will anticipate the need to
search, merge, and summarize the log records from diverse = elements.
The format will = anticipate the need to correlate messages = from
multiple elements related = to a given request (that may fork)
or a given dialog. The format will take SIP's = extensibility into
consideration, providing a way to represent SIP message = components
that are defined in = the future.  The format will anticipate = being
used both for off-line = analysis and on-line real-time processing
applications. The working group will consider the need = for
efficient processing in = its design of this format.

The working = group is not pre-constrained to producing either = a
bit-field oriented or = text-oriented format, and may choose to
provide both. If the group chooses to specify both, it = must be
possible to = mechanically translate between the formats = without
loss of = information.

Specifying the = mechanics of exchanging, transporting, and = storing
SIP Common Log Format = records is explicitly out of scope. = Specifying
a real-time = transfer mechanism for heuristic analysis is = explicitly
out of = scope.

The group will = generate:

- A problem = statement enunciating the motivation,
and use cases for a SIP Common Log Format. This = analysis
will identify the = required minimal information that must
appear in any record.

- A = specification of the SIP Common Log Format = record.

The group will = consider providing one or more reference
implementations for decoding a CLF = record.

Goals and = Milestones
=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

Nov 09 - = Problem statement, motivation, and use cases to IESG = (Informational)
Feb 10 - SIP = Common Log Format specification to IESG (PS)



= --Apple-Mail-140--1024798114-- From HKaplan@acmepacket.com Fri Jul 17 14:37:00 2009 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 110D33A6F1E for ; Fri, 17 Jul 2009 14:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 VH2XZC9WEaJI for ; Fri, 17 Jul 2009 14:36:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 79A473A6F20 for ; Fri, 17 Jul 2009 14:36:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 17 Jul 2009 17:37:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 17:37:31 -0400 From: Hadriel Kaplan To: Dale Worley , DISPATCH Date: Fri, 17 Jul 2009 17:37:30 -0400 Thread-Topic: [dispatch] Questions regarding draft-kaplan-sipping-interop-bcp-02 Thread-Index: AcoHFYybuB7+MyIOQ86naGUd5A+i8wAEOpng Message-ID: References: <1247859235.3780.28.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1247859235.3780.28.camel@victoria-pingtel-com.us.nortel.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 Subject: Re: [dispatch] Questions regarding draft-kaplan-sipping-interop-bcp-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: Fri, 17 Jul 2009 21:37:00 -0000 Dale, Thanks for the detailed review! I will take your comments for the next rev of the doc. (I thought I had fix= ed one of them already but realized not in the rev I submitted - d'oh) -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dale Worley > Sent: Friday, July 17, 2009 3:34 PM > To: DISPATCH > Subject: [dispatch] Questions regarding draft-kaplan-sipping-interop-bcp- > 02 >=20 > Section 2: >=20 > There are two broad areas of SIP interoperation. One is "phone to > PBX", which is assumed to be between a UA and a proxy for its domain. > The other is "SIP trunking", that is, between two proxies, often in > different administrative domains. The recommendations in this draft > seem to cover both areas, and it's likely that the two areas cannot be > clearly separated. Nonetheless, a naive reader (me) would likely > infer from the author's employer that the draft only covers "SIP > trunking" problems. An expansion of the Applicability section would > dispel this misinterpretation earlier in the text, and would prevent > some readers from leaving off finishing reading the document. >=20 > Section 4.3: >=20 > Just after the regexp is the statement "Note this is after removing > visual-separators, and any user parameters." Given he need for > accuracy here, this statement is problematic because > "visual-separator" is not a defined term in regard to SIP URIs > (although it is for tel: URIs), and "user parameter" is not defined at > all in the grammar (although people generally know what the term > means). >=20 > The initial part of a SIP URI is officially called "user". >=20 > Isn't the maximum length of an E.164 number 15 digits? If so, why are > 16-digit numbers also restricted? >=20 > A more clearly defined specification is: >=20 > It is RECOMMENDED that SIP domains not allocate SIP URI AoR > user parts which match the following regular expression syntax, > unless the URI is intended to have the same significance as > the corresponding E.164 number: >=20 > ^+?([-.()]*[0-9]){11,16}[-.()]*(;.*)?$ >=20 > This regular expression is to be compared to the user part after > removing any escaping. The characters "*" and "#", although > allowed in tel: URIs, are not allowed in E.164 numbers, and so user > parts containing them are not included in this prohibition. >=20 > In regard to the statement >=20 > It is RECOMMENDED, that the SIP Working Group address the > fundamental issue of E.164 or telephone number scope in SIP URI's. >=20 > I don't see what issue needs to be addressed, as the working group's > opinion is well-defined and well-known, and nobody has advanced any > argument to change it. >=20 > The TEL URI also has specific syntactic and usage issues beyond > simply lack of broad industry support, which may be a reason for not > supporting it. >=20 > This is more interesting, since the question to be answered is "Why > don't implementers follow the clear intention of the specification, > and what might be done about that?" >=20 > In regard to the URI schemes that are used in various locations, we > need a general statement that elements should tolerate sip:, sips:, > and tel: URIs in all situations, excepting when the element must > understand the URI to process the message. E.g., there is no excuse > for rejecting a syntactically correct From URI, because an element > never needs to understand the semantics of the From URI. >=20 > Similarly, there are situations where a default action is specified to > be taken when the element does not understand a URI which might > otherwise cause it to take specific action. In such cases, an element > should take the default action for such URIs rather than rejecting the > message outright. >=20 > Section 4.4: >=20 > Although the Tel URI has not seen much usage itself using the "tel" > scheme, it is quite common to see SIP URI's containing Tel-URI > parameters - i.e., Tel URI's in the form of SIP URI's. There are > many URI parameters defined for Tel-URI that are popular, and thus > frequently appear in SIP URI's, for example in the request-URI. >=20 > What is not made clear here is that these parameters show up as > "user-part parameters", which is a syntax feature not defined in RFC > 3261. Naively, the above paragraph suggests that these parameters > show up as URI-parameters. This could be fixed by amending the first > sentence to say "... quite common to see SIP URI's user-parts > containing Tel-URI parameters ...", and adding an example: "E.g., > sip:+12125551212;phone-context=3Dexample.com@example.net" >=20 > The most common interoperability problem in this area is the > placement of the Tel URI parameters, for example the "tgrp" and > "trunk-context" parameters from [RFC4904], and the "rn", "npdi", and > "cic" parameters from [RFC4694]. RFC 3261 section 19.1.6 is very > clear that the entire telephone-subscriber portion, including > parameters, is placed in the userinfo portion of a SIP URI. Thus > the Tel-URI parameters become user parameters for SIP, not SIP URI > parameters. >=20 > "userinfo portion" should be "user portion", as the SIP URI syntax > allows phone numbers to be followed by a password part, and presumably > such an inserted telephone-subscriber portion can be followed by a > password part (yuck). >=20 > Section 5.1: >=20 > In regard to failure responses to REGISTER requests: >=20 > [What can we say here that UA's will actually do?] >=20 > "In any circumstance the UA MUST take care that it never generates > retries of requests without using a suitable back-off strategy. If > the UA receives a response which suggests that a particular > modification of the request is likely to be successful, it MAY send > the modified request immediately. The UA MAY NOT retry any failing > request with a long-term average frequency of more than one request > sent (new client transaction initiated) per 5 minutes regardless of > what responses it receives." >=20 > Making sure that UAs do not flood systems is a critical need. >=20 > Section 5.2: >=20 > Let's add "SIP elements MUST process provided Contact URIs opaquely." >=20 > Section 5.5: >=20 > Shouldn't this section refer to sections 2.4 to 2.6 (various forms of > transfer) in RFC 5359 (the service examples RFC)? >=20 > Section 6.1: >=20 > I suggest softening the first recommendation to require SDP only in > initial INVITEs, but permitting offer-less re-INVITEs. The latter is > very useful in implementing MOH, and since the dialog path is already > established, it is unambiguous what media/codecs the UAS and the > middleboxes support/permit *in that dialog*, even if call routing is > affected by media/codecs. >=20 > Section 6.4: >=20 > [Note: one trick some vendors use is to pretend the unacceptable > response was not received and send a CANCEL - should we recommend > that?] >=20 > That's an interesting idea, since it seems to permit the INVITE to > fail-over to another destination which might generate an acceptable > answer. But thinking more about it, I don't think that works -- the > CANCEL gets a 200 response but doesn't do anything (since the UAS has > already progressed the dialog to confirmed), and the UAS will > retransmit the 200. What is needed is to eat the 200 response with > the unacceptable answer so that all upstream proxies have a chance to > fork the request to additional destinations. But that means that the > proxy that eats the 200 must be well downstream, near the UAS that > generated the 200, but must know what the UAC considers unacceptable. > It's hard to make that work unless the proxy that eats the 200 is also > the one that generates further forks, and also services the UAC. >=20 > The only workable solution I can think of is for the INVITE to carry > "Request-Disposition: no-cancel" so that the intermediate proxies > continue to generate forks even though one UAS responds 200. Then the > UAC will receive all the 200s as they are generated. If it doesn't > like the answer in one 200, it can BYE that dialog. If it receives a > 200 with an answer it likes, it can then CANCEL the INVITE to suppress > further forking. >=20 > That's messy, but it might make sense for a UAC to use it as a > fallback strategy. Assuming that the intermediate proxies support > Request-Disposition, it is even standardized. >=20 > Section 7: >=20 > The Call-Info header is used in the call-completion architecture > (draft-bliss-ietf-call-completion). I suspect that many other "rare" > headers are used sporadically in other situations. >=20 > A better recommendation is to remind implementers that an > implementation MUST ignore header fields, URI-parameters, and > header-parameters that it does not understand. Conversely, > implementations MUST reject requests with unknown option-tags in > Require header fields. If implementations follow these rules, > extraneous information should not cause interoperation problems, since > SIP features are designed (remarkably carefully!) to be > upward-compatible under these rules. >=20 > Dale >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Mon Jul 20 02:59:16 2009 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 005AA3A68EB for ; Mon, 20 Jul 2009 02:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 iW+hAhMwmHNe for ; Mon, 20 Jul 2009 02:59:15 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C3C573A6808 for ; Mon, 20 Jul 2009 02:59:14 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-cd-4a643f9b78a1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 5A.E9.18827.B9F346A4; Mon, 20 Jul 2009 11:57:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:57:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:57:46 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 656A12461; Mon, 20 Jul 2009 12:57:46 +0300 (EEST) Message-ID: <4A643F9A.4000509@ericsson.com> Date: Mon, 20 Jul 2009 12:57:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: DISPATCH References: <4A5657AA.60401@ericsson.com> In-Reply-To: <4A5657AA.60401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 09:57:46.0678 (UTC) FILETIME=[8879FD60:01CA0920] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Input requested: abandoning draft-ietf-sipping-profile-datasets-03? 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, 20 Jul 2009 09:59:16 -0000 Hi, since nobody has expressed interested in this draft, we will be abandoning it. Cheers, Gonzalo DISPATCH co-chair Gonzalo Camarillo wrote: > Folks, > > the SIPPING WG agreed to work on the following draft a long time ago: > > http://tools.ietf.org/html/draft-ietf-sipping-profile-datasets-03 > > As you can see in the following slide, the media-policy draft depends on > the draft above: > > http://www.ietf.org/proceedings/07jul/slides/sipping-4/sld11.htm > > While there are people interested in the media-policy draft, we have not > found anyone interested in the profile-datasets draft. > > One of the things we agreed to do when restructured RAI and chartered > DISPATCH was to drop items people were no longer interested in. > Therefore, at this point, we are considering abandoning the > profile-dataset draft. If we do this, we would need to import a few > things from that draft to the media-policy draft (e.g., the merging > rules) but the idea would be to only progress the media-policy draft. > > Does anyone have any objection to this way forward? > > Note that in order to progress a draft we need people interested in it > and people willing to put cycles on it. Therefore, if you are interested > in keeping the draft alive, you will be automatically volunteering to > put cycles on it in order to progress it ;o) > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Mon Jul 20 03:32:38 2009 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 4422C3A69A0 for ; Mon, 20 Jul 2009 03:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 avzZ1Ys+ktLr for ; Mon, 20 Jul 2009 03:32:37 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0FEC83A687C for ; Mon, 20 Jul 2009 03:32:36 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-32-4a643b967769 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 9D.C8.18827.69B346A4; Mon, 20 Jul 2009 11:40:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:40:38 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:40:37 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 936A52461; Mon, 20 Jul 2009 12:40:37 +0300 (EEST) Message-ID: <4A643B95.3060800@ericsson.com> Date: Mon, 20 Jul 2009 12:40:37 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 09:40:37.0841 (UTC) FILETIME=[233DEC10:01CA091E] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, R.Jesske@telekom.de Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 20 Jul 2009 10:32:38 -0000 Hi, as Francois suggests, a document specifying the use of Reason header fields in responses needs to specify those things (see Francois' list below). Additionally, you should think of whether or not Reason header fields in responses can carry SIP status codes and what happens if they are different to the status code of the response. In short, the document cannot simply say that now it is OK to use Reason in responses. It needs to address the different situations a typical implementation may face. Cheers, Gonzalo Francois Audet wrote: > Again, the spec is very clear that it IS allowed. > > I believe the wishy-washy text about "status code explicitly > allowing it" was meant to exclude responses that were not appropriate, > and restricing it to effectively error responses. > > At the time this was written, I believe we were not clear on which > codes were supposed to be appropriate or not. > > Seems to me: > - Any Error response code should be allowed. > - I don't think 2XX makes sense. > - 3XX is controversial (as per the email quoted by Roland): seems to me it > would be quite useful > - Provisional is interesting... Sounds like 199 error response to me... > >> -----Original Message----- >> From: Worley, Dale (BL60:9D30) >> Sent: Thursday, July 16, 2009 10:09 >> To: Audet, Francois (SC100:3055) >> Cc: R.Jesske@telekom.de; dispatch@ietf.org >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) wrote: >>> Hi Roland, >>> >>> You use case is very common. >>> >>> I believe you are incorrect in saying that "reasons are >> currently not >>> allowed in responses. Neither conditionally nor allowed". >>> >>> RFC 3326 says in 1.0: >>> "[...] it can appear in any request >>> within a dialog, in any CANCEL request and in any response whose >>> status code explicitly allows the presence of this header field." >>> >>> To be honest, I believe Q.850 codes are much more common in >> Responses >>> than in requests. >> Googling >> >> "sip/2.0" reason "q.850" >> >> turns up numerous examples of SIP responses using the Reason >> header in the forbidden manner. >> >> I'd say that your draft formally allows what people are already doing. >> >> Dale >> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Mon Jul 20 03:43:48 2009 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 3ABC13A6B99 for ; Mon, 20 Jul 2009 03:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Zq+2FAioPvKs for ; Mon, 20 Jul 2009 03:43:47 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 481813A6B5D for ; Mon, 20 Jul 2009 03:43:46 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-ee-4a643f6095cf Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9E.F4.14528.06F346A4; Mon, 20 Jul 2009 11:56:49 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:55:58 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:55:58 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E764D2461; Mon, 20 Jul 2009 12:55:57 +0300 (EEST) Message-ID: <4A643F2D.5030300@ericsson.com> Date: Mon, 20 Jul 2009 12:55:57 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> In-Reply-To: <4A537B66.4000608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 09:55:58.0149 (UTC) FILETIME=[47C9C750:01CA0920] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 20 Jul 2009 10:43:48 -0000 Hi Paul, > that this should be invisible > to the other "side". while this is of course a good thing when it can be achieved, it cannot be an absolute requirement for solutions to a given problem. Otherwise, SIP would not have mechanisms such as the Require header field. That is, while in many deployment scenarios you want to be able to deploy things incrementally taking advantage of extensions even if only one UA support them, in others you can actually update all your UAs to support a new extension. Salvatore has described deployment scenarios where UAs can be upgraded to support a new extension. I think we should consider them if they can take advantage of extra functionality when compared with other scenarios where this cannot be done... that is why we included Require header fields in SIP's original design. Cheers, Gonzalo From salvatore.loreto@ericsson.com Mon Jul 20 04:13:19 2009 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 DBAAC3A67AC for ; Mon, 20 Jul 2009 04:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 N92w5FYg4sB5 for ; Mon, 20 Jul 2009 04:13:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A8CEF3A67A8 for ; Mon, 20 Jul 2009 04:13:18 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-ce-4a6450db190c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E1.F9.14528.BD0546A4; Mon, 20 Jul 2009 13:11:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 13:11:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 13:11:20 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 04F032461; Mon, 20 Jul 2009 14:11:20 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C4AD121A07; Mon, 20 Jul 2009 14:11:19 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A994219CC; Mon, 20 Jul 2009 14:11:19 +0300 (EEST) Message-ID: <4A6450D6.90904@ericsson.com> Date: Mon, 20 Jul 2009 14:11:18 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> In-Reply-To: <4A537B66.4000608@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 20 Jul 2009 11:11:20.0200 (UTC) FILETIME=[CF240080:01CA092A] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 20 Jul 2009 11:13:19 -0000 Hi Paul, Paul Kyzivat wrote: > > If we can agree that one communication session between two parties has > one sip session *between them*, then we can work on what the > architecture should be like at each end. that would be a work to improve the centralized scenario and perhaps making it possible without using 3pcc or solving the current 3pcc limitations and them to make it nicer and easier to use. However I still think it would be useful to work on a decentralized scenario, moreover there could be scenario where knowing how one end aggregates media resource for the call will help the other end to better decide how to manage (i.e. answer) the call . thanks Sal From salvatore.loreto@ericsson.com Mon Jul 20 04:25:53 2009 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 A66133A688B for ; Mon, 20 Jul 2009 04:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Oo2QqVGEcd9s for ; Mon, 20 Jul 2009 04:25:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5F0E13A69E1 for ; Mon, 20 Jul 2009 04:25:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-c1-4a64543a4162 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 13.A4.00514.A34546A4; Mon, 20 Jul 2009 13:25:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 13:25:45 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 13:25:44 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DFD4E2461; Mon, 20 Jul 2009 14:25:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AA01E21A07; Mon, 20 Jul 2009 14:25:43 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3D867219CC; Mon, 20 Jul 2009 14:25:43 +0300 (EEST) Message-ID: <4A645436.1090601@ericsson.com> Date: Mon, 20 Jul 2009 14:25:42 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: "Elwell, John" References: <4A522751.9010607@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0021DBF5F@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0021DBF5F@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 20 Jul 2009 11:25:44.0227 (UTC) FILETIME=[D2240F30:01CA092C] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 20 Jul 2009 11:25:53 -0000 Hi John, see my answers in line thanks Sal Elwell, John wrote: > Sal, > > Thanks for writing this. The centralised approach is what I and some > others have been suggesting over the past months. It is good to see a > comparison between the centralised approach (in its various flavours) > and the distributed approach that you have been advocating for some > time. > > It seems the biggest issue for deciding whether or not to work on the > distributed approach is whether there is a need for the "master" device > (the one operating SIP) to drop out of the call, while allowing the call > and certain media to continue at other devices. > exactly! this is one of the main 3pcc issue, but not the only one; > I still have a concern that with the distributed approach the remote end > of the call needs to exhibit special behaviour in order to handle the > multiple dialogs arising from the distributed approach (as Paul also > notes). So in practice, to make it work with any degree of reliability, > calls will need to go through a B2BUA that provides the necessary > aggregation. So it effectively ends up as a centralised approach anyway. > well, if the other end does not support a distributed approach then you can not use it. > The distributed approach (section 4) is not really described in enough > detail. There still has to be some communication between Alice's UAs, > e.g., to convey information to a UA to be added to the call to allow it > to make a call to Bob and allow Bob to associate the new call with the > existing call. Also if Alice wants to clear all calls (i.e., all > components of the same call) with one button push, there needs to be > some communication between the UAs. > right, how the different user devices of one end coordinate and convey information each other in a distributed scenario is something that needs to need to be analysed and describe in more details. > John > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto >> Sent: 06 July 2009 17:33 >> To: dispatch@ietf.org >> Subject: [dispatch] Disaggregated Media in SIP >> >> Hi there, >> >> I have just submitted a draft that talks of Disaggregated >> Media in the >> Session Initiation Protocol (SIP). >> http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa >> ggregated-media-00.txt >> >> >> Abstract: >> Disaggregated media refers to the ability for a user to create a >> multimedia session combining different media streams, coming from >> different devices under his or her control, so that they are >> treated by >> the far end of the session as a single media session. >> This document lists several use cases that involve >> disaggregated media >> in SIP. >> Additionally, this document analyzes what types of >> disaggregated media >> can be implemented using existing protocol >> mechanisms, and the pros and cons of using each of those mechanisms. >> Finally, this document describes scenarios that are not covered by >> current mechanisms >> and proposes new IETF work to cover them. >> >> >> cheers >> Sal >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> From rajnish.jain@ipc.com Mon Jul 20 05:51:13 2009 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 7BAFB28C176 for ; Mon, 20 Jul 2009 05:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_33=0.6] 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 854XFC9zmwi8 for ; Mon, 20 Jul 2009 05:51:12 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) by core3.amsl.com (Postfix) with ESMTP id 3930B3A67F4 for ; Mon, 20 Jul 2009 05:51:12 -0700 (PDT) Received: from unknown [65.244.37.51] (EHLO p01c11o147.mxlogic.net) by p01c11o147.mxlogic.net (mxl_mta-6.3.0-1) with ESMTP id 048646a4.ce329b90.237446.00-505.401520.p01c11o147.mxlogic.net (envelope-from ); Mon, 20 Jul 2009 06:51:12 -0600 (MDT) X-MXL-Hash: 4a646840429b5fcd-a652dc0dc1642b9542a408298d837765dcb86bcb Received: from unknown [65.244.37.51] (EHLO smtp.ipc.com) by p01c11o147.mxlogic.net (mxl_mta-6.3.0-1) over TLS secured channel with ESMTP id 338646a4.0.237409.00-005.401448.p01c11o147.mxlogic.net (envelope-from ); Mon, 20 Jul 2009 06:51:05 -0600 (MDT) X-MXL-Hash: 4a6468395ab2bccf-151f7ad105615f4feb20a6a7176260ad95c75f91 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.1.17]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Mon, 20 Jul 2009 08:50:59 -0400 From: "Jain, Rajnish" To: "Doken, Serhad" , Vijay Gurbani , "dispatch@ietf.org" Date: Mon, 20 Jul 2009 08:50:57 -0400 Thread-Topic: [dispatch] Session Recording in SIP Thread-Index: Acny7zk28PigrO+0SryRcGZzpsB+WwLm/JUQAgaJJ4AAo1zOIA== Message-ID: References: <4A3F03F6.6060505@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16774.004 x-tm-as-result: No--41.884000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009071501)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=yoqeWMBPYRgA:10 a=z+2a4RCZxltofrpCDsS06w==:17 ] X-AnalysisOut: [a=EUspDBNiAAAA:8 a=48vgC7mUAAAA:8 a=qHpt-Nrc73z-MUfq884A:9] X-AnalysisOut: [ a=Qa8jnPax02wjEGMjsMMA:7 a=yws9qXXdRyDtvfaVGOLb_1jDJ1wA:4] X-AnalysisOut: [ a=IG2fH9E8heMA:10 a=lZB815dzVvQA:10 a=YNzOkMco5FRp5Wzw:21] X-AnalysisOut: [ a=G2WCKqIVXCsa0zcH:21] Subject: Re: [dispatch] Session Recording in SIP 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, 20 Jul 2009 12:51:13 -0000 Hi, Thanks for your detailed comments. Please see inline: > -----Original Message----- > From: Doken, Serhad [mailto:sdoken@qualcomm.com] > Sent: Friday, July 17, 2009 3:56 AM > To: Jain, Rajnish; Vijay Gurbani; dispatch@ietf.org > Subject: RE: [dispatch] Session Recording in SIP > > I read this draft and following are my comments : > > Section 3 Definitions > > Perhaps Recording Server(RS) should simply be called Recorder. I see the > note on the last sentence however as long as definitions refer to Client = and > Server, it will always imply to the reader to think that RS is the server= . Naming these things is always a bit tricky. If we called the RS simply the = Recorder given your reasoning, then the RC should also be named differently= (because the RC can act as the "server side" of the SRP signaling). The RS= naming is a bit akin to the term "Media Server". If there is enough confus= ion on RS then, we can consider renaming it. > The statement that SRP may be SIP is an understatement since the definiti= on > for RC already referred to as a SIP UA/B2BUA. This will be clarified in subsequent revisions when we'll say that SRP is i= ndeed SIP. > Dynamic Recording, if the recording session is started and ended at rando= m > points on demand, its length will not be the same as actual media session= . Ok. We can clarify this. > Persistent Recording, it is not clear what is meant by "system start up".= Is > "system" referring to RC or RS ? It meant that when both devices become functional. We can clarify this. > Depending on the answer, I am curious how are these persistent recording > sessions are correlated to many active media sessions and what would be > mechanism to keep them alive ? The data over the call metadata interface will offer the correlation. A sim= ple way to keep SRP persistent sessions alive is through the SIP session-ti= mers. What is the number of persistent recording > sessions per RC/RS ? That's an implementation-dependent choice. > Perhaps implications of this should be covered somewhere else, maybe in t= he > requirements section ? > > Section 5 Requirements > > REQ-006 Not a good idea to talk about the solution here and how some RC > implementations handle the problem. That note is only informative text. I guess we can take it out. > Perhaps REQ-010 and 011 can be combined into one by just saying "over a > single or separate". Fine. Will change this. > REQ-018 can be extended to say that the mechanism MUST support the abilit= y > to find out the associated recorded session(s) given that one(for instanc= e > RS) is only aware of recording session(s). I'd rather prefer this to be a > separate requirement. The RS is aware of the recorded session metadata. REQ-018 is a bit broad in= the sense that it talks about correlation in either direction (i.e. from r= ecorded sessions to recording sessions and vice-versa). I think your commen= t is about splitting the two directions, right? > I have another requirement in mind : The mechanism MUST support the abili= ty > to setup recording sessions that will record different conversation > directions of the Recorded session(s) from RC(s) and they too should be > correlated accordingly. For instance, while an agent is talking to a > customer, there should be a way to setup two recording sessions, one > carrying the media from agent towards customer and vice versa for the oth= er. > Furthermore, these recording sessions should be marked as such in SRP. Yes, this is needed. This requirement was actually in there and somehow got= removed in one of the edits. We'll add this. > REQ-021 talks about a mode where RC just forks media to RS. However, ther= e > is value in studying transcoding, media incompatibility use cases and see= if > there are requirements they bring given that RS/RCs are/will most likely > have different media capabilities. REQ-021 is primarily about a middle-box type of RC that forks the media. Th= e RC vendors in this case want their boxes to be optimal and scalable by do= ing as little media processing as possible. REQ-021 isn't precluding the us= e cases that you mentioned, but I think it'll make sense to address such us= e cases in this document. > If recorded session media is stopped/temporarily interrupted due to probl= ems > or features invoked on it(recording session is put on hold or started a > conferencing or transfer operation), how does that affect the already set= up > recording session(s) ? I think that'll largely depend on the RC/RS implementations and the nature = of the SRP sessions. For instance, if the recording sessions are persistent= and the RC puts recorded session media on hold, then it RC MAY reINVITE th= e RS and put the recording session media on hold or it MAY just temporarily= stop sending such media (silence suppression) to the RS. > Nit : > > Section2, sentence that starts with "that draft focuses on the mechanism = to > provide the SRTP...." is odd. It is clear that srtp-key draft is not for > session recording, so no need to state the obvious. Ok. We can change some wording here. Thanks, Raj DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From pkyzivat@cisco.com Mon Jul 20 06:06:27 2009 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 719303A67F4 for ; Mon, 20 Jul 2009 06:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Jh+LcGt50juH for ; Mon, 20 Jul 2009 06:06:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 396CB3A6A38 for ; Mon, 20 Jul 2009 06:06:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANMIZEpAZnme/2dsb2JhbAC4E4gjjiQFhAw X-IronPort-AV: E=Sophos;i="4.43,234,1246838400"; d="scan'208";a="51022193" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2009 13:05:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6KD5pWu013908; Mon, 20 Jul 2009 09:05:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6KD5pAb028076; Mon, 20 Jul 2009 13:05:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:05:51 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:05:51 -0400 Message-ID: <4A646BAF.7030007@cisco.com> Date: Mon, 20 Jul 2009 09:05:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> In-Reply-To: <4A643F2D.5030300@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 13:05:51.0546 (UTC) FILETIME=[CEC831A0:01CA093A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2295; t=1248095151; x=1248959151; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=JyRnXU3/brjzerB3a93qd7T39S8/dhQe8rH3R5Mk+vM=; b=sMIdx7b7cMkKWP3YOrELcF3hHbIj/fU2eu04UTWoX6IFeYl8RzBAAntXD4 HkDxz5rvOUKjoTQYkMsJPaBDjl3xvLTKkueaYyxBjwWeHZkr3hI+f6MFuHN9 z6LeE3goSf; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 20 Jul 2009 13:06:27 -0000 Gonzalo Camarillo wrote: > Hi Paul, > >> that this should be invisible to the other "side". > > while this is of course a good thing when it can be achieved, it cannot > be an absolute requirement for solutions to a given problem. Otherwise, > SIP would not have mechanisms such as the Require header field. I'm not trying to assert that this is a criterion that is appropriate for all problems - just that it is appropriate for *this* problem. Some problems cannot be solved without the collaboration of both ends, and in that case, if the feature is not one that all UAs must have then some sort of negotiation to determine whether the two ends support it is needed. But in this case it can be shown that the capability *can* be managed on one end without the assistance of the other end. And doing it that way vastly increases the interoperability over an approach that requires the support of both ends. > That is, > while in many deployment scenarios you want to be able to deploy things > incrementally taking advantage of extensions even if only one UA support > them, in others you can actually update all your UAs to support a new > extension. > > Salvatore has described deployment scenarios where UAs can be upgraded > to support a new extension. I think we should consider them if they can > take advantage of extra functionality when compared with other scenarios > where this cannot be done... that is why we included Require header > fields in SIP's original design. I still haven't seen anything showing why this approach ends up being "better" than the "centralized" approach. (Note that I don't agree with the term "centralized", because it isn't really more centralized than the "distributed" approach is. This would become clearer if we looked at all the communications necessary to establish a call with disaggregated media, and the various topologies of devices that might play in such scenarios.) Perhaps we should back off from the signaling mechanisms for the moment and consider the use cases of interest in more detail, and the various sorts of communications between them that are necessary to establish a call that involves them. Thanks, Paul > Cheers, > > Gonzalo > From pkyzivat@cisco.com Mon Jul 20 06:20:38 2009 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 628D528C177 for ; Mon, 20 Jul 2009 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 b6Vhdvl1s2zm for ; Mon, 20 Jul 2009 06:20:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1BEA73A683E for ; Mon, 20 Jul 2009 06:20:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFkMZEpAZnme/2dsb2JhbAC4H4gjjiYFhAw X-IronPort-AV: E=Sophos;i="4.43,234,1246838400"; d="scan'208";a="51026075" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2009 13:20:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6KDKOEJ029954; Mon, 20 Jul 2009 09:20:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6KDKOoo006325; Mon, 20 Jul 2009 13:20:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:20:19 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:20:18 -0400 Message-ID: <4A646F12.8070000@cisco.com> Date: Mon, 20 Jul 2009 09:20:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Salvatore Loreto References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A6450D6.90904@ericsson.com> In-Reply-To: <4A6450D6.90904@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 13:20:18.0879 (UTC) FILETIME=[D3C0B4F0:01CA093C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1655; t=1248096024; x=1248960024; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Salvatore=20Loreto=20; bh=Dmi5QHBFIZAT9Ibk2uH1VH9To5phet5gkUejZGIbBqA=; b=F1qWo/xW0Oa3p5e63OiLpT9ePlxIr95jgJLNR3V322UeF8dkStNT42tLXI OfppxnXiB9TGcZ6EU6Xo+eYOJhojSXDdZk5IowlipCNl6yUaKTL3HkvIDOS2 eXU2kFjeCA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 20 Jul 2009 13:20:38 -0000 Salvatore Loreto wrote: > Hi Paul, > > Paul Kyzivat wrote: >> >> If we can agree that one communication session between two parties has >> one sip session *between them*, then we can work on what the >> architecture should be like at each end. > that would be a work to improve the centralized scenario and perhaps > making it possible without using 3pcc > or solving the current 3pcc limitations and them to make it nicer and > easier to use. > > However I still think it would be useful to work on a decentralized > scenario, moreover there could be scenario where knowing > how one end aggregates media resource for the call will help the other > end to better decide how to manage (i.e. answer) the call . I will try to keep an open mind, but I suspect we have a fundamental disagreement here. IMO there is a fundamental architectural property at stake here. IMO the point is as much as possible to add capabilities without increasing the complexity of the fundamentals - use what we have as building blocks when we can. Only when that is found to be fatally flawed should we be adding more stuff for everybody to implement. IMO there will be many devices that want to support multimedia than those that have need to support disaggregated media. Its a bad thing if those can't participate in multimedia calls with devices that have need support from multiple devices to achieve multimedia capability. I guess the one way I could buy into your "distributed" approach is to simply model it as a conference, where the focus is at one "end". But I think we discussed that once. Thanks, Paul From ietf.hanserik@gmail.com Mon Jul 20 07:38:58 2009 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 460E73A6C34 for ; Mon, 20 Jul 2009 07:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Uim7h75gY8AR for ; Mon, 20 Jul 2009 07:38:57 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 67AC13A6D96 for ; Mon, 20 Jul 2009 07:38:38 -0700 (PDT) Received: by ewy26 with SMTP id 26so2321918ewy.37 for ; Mon, 20 Jul 2009 07:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cqGoaFDdwmMO+ges+KoQe2dVNUDtgylNfygTDUhJpPc=; b=Wy2Rc8g5X9kJN1YhJSb/YnMtaqNAs9UaWNHloWbpsne8CrGgeot/aAude6SJVV351S XP629lzU2pEqv72ROqWTofNc73OylDkdMaS1EkK5Cjh3NYdpC33pqunc/MxNxeW3kiYM xX3XkL2Xs9ULQQfZvXo9sbJQuXHBV+VKAsHic= 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=v6L2dEJBQVO8i1ocJQMoNyOeLZnM1URWsY62DJJ0gWSERCi385knvBNLVod7q8mw8k a6xQDLPc1KNvNg3fiblXLFBPCeuxv/bG13bsBcdwuJnhanfNEuNAl9Y8ilmO1ugzF/cc raRLYZdDtyFSXTi8FlPrTW/pMW+RitClLnAws= MIME-Version: 1.0 Received: by 10.210.11.17 with SMTP id 17mr3740421ebk.38.1248100715474; Mon, 20 Jul 2009 07:38:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2009 16:38:35 +0200 Message-ID: <9ae56b1e0907200738n6685284l17d1282fd0653b9@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174be630ca308c046f2417be Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt 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, 20 Jul 2009 14:38:58 -0000 --0015174be630ca308c046f2417be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Hadriel, Thanks for putting this together, this is useful. - General I think it would be good to add some informative references to the ETSI TISPAN specification where the NGN/IMS way of performing business trunking (SIP trunking) has been specified using the concept of implicitly registered wildcarded public user identities (AORs) The specification numbers are: *ETSI TS 181 019 *V2.0.0 (2007-11) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);*Business Communication Requirements* *ETSI TS 182 023 V2.1.1* (2009-01) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);*Core and enterprise NGN interaction scenarios;Architecture and functional description* *ETSI TS 182 025 V2.1.1 *(2008-09) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);*Business trunking;Architecture and functional description* I think it would also be good to add informative references to the SIP Connect specifications. Further it might be good to say something about the different viewpoints taken by the different bodies: - ETSI TISPAN/3GPP Business Trunking are providing the viewpoint of the service provider connecting IP-PBX's to its IMS/NGN infrastructure - SIP Connect is more looking at the interconnect specifciation between the an SSP and a IP-PBX. Ideally both should match at some point to get an interoperable corporate communication space. - Section 6.2 The 3GPP/ETSI TISPAN mechanism does not add the notion of wildcarded P-Associated-URI, but it adds the notion of wildcarded public user identity, which generates so to speak the set of public user identioties to be registered. This is not only visible on the P-Associated-URI header but also makes configuration of such sets of public user identities easier. 3GPP and ETSI have extended the mechanism described here with the following additions, for connected PBX's a subscription parameter can be set that allows delivery of the target URI is kept in the request URI and the contact address is added to the Route header after the stored path is inserted, which means that in this case the P-Called-Party-ID is not strictly needed for delivery of the target address. Further this mechanism is extended to allow PBX/corporate proxies to use P-Asserted-Identity instead of P-Preferred-Identity, which is a more natural thing to do for corporate proxies. Regarding the side note: This seems misleading as an SSP may very well serve the domain name of the enterprise, even if only for SIP traffic. This can all be arranged with normal DNS infrastructure. Best Regards, /Hans Erik van Elburg On Thu, Jul 9, 2009 at 7:37 PM, Hadriel Kaplan wrote: > Howdy, > As part of a discussion in the SIP Forum regarding a model for Registration > we are using for IP-PBX's, I was asked by someone to submit an I-D > describing it, in case it would be of any value. Since I hadn't seen an I-D > before on how 3GPP/ETSI did their model, and since their model is different > from SIP-Forum's, I submitted one which describes the models for both SIP > Forum's SIP-Connect v1.1 and 3GPP/ETSI. > > NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP, > and I am still talking with colleagues in 3GPP to make sure I got that part > right. This is purely an individual submission in all respects. > > Forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Session Initiation Protocol (SIP) Implicit > Registrations > Author(s) : H. Kaplan > Filename : > draft-kaplan-dispatch-sip-implicit-registrations-00.txt > Pages : 12 > Date : 2009-07-05 > > This document identifies several approaches to provide reachability > information for a domain or multiple AoR's using a single SIP REGISTER > method transaction, in ways not originally envisioned or documented by RFC > 3261. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-sip-implicit-registrations-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0015174be630ca308c046f2417be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hadriel,

Thanks for putting this together, this is=A0= useful.

- General
I think it would b= e good to add some informative references to the ETSI TISPAN specification = where the NGN/IMS way of performing business trunking (SIP trunking) has be= en specified using the concept of implicitly registered wildcarded public u= ser identities (AORs)

The specification numbers are:
ETSI TS 181 019 = V2.0.0 (2007-11)
Telecommunications and Internet converged Services = and Protocols for Advanced Networking (TISPAN);Business Communication Re= quirements

ETSI TS 182 023 V2.1.1 (2009-01)
Telecommunications and Inter= net converged Services and Protocols for Advanced Networking (TISPAN);Co= re and enterprise NGN interaction scenarios;Architecture and functional des= cription

ETSI TS 182 025 V2.1.1 (2008-09)
Telecommunication= s and Internet converged Services and Protocols for Advanced Networking (TI= SPAN);Business trunking;Architecture and functional description

I think it would also be good to add informative references to the= SIP Connect specifications.

Further it might be good to say something about the different = viewpoints taken by the different bodies:
- ETSI TISPAN/3GPP Busi= ness Trunking are providing the viewpoint of the service provider connectin= g IP-PBX's to its IMS/NGN infrastructure
- SIP Connect is more looking at the interconnect specifciation betwee= n the an SSP and a IP-PBX.

Ideally both should mat= ch at some point to get an interoperable corporate communication space.

- Section 6.2
The 3GPP/ETSI TISPAN mechanism does not a= dd the notion of wildcarded P-Associated-URI, but it adds the notion of wil= dcarded public user identity, which generates so to speak the set of public= user identioties to be registered. This is not only visible on the P-Assoc= iated-URI header but also makes configuration of such sets of public user i= dentities easier.

3GPP and ETSI have extended the mechanism described her= e with the following additions, for connected PBX's a subscription para= meter can be set that allows delivery of the target URI is kept in the requ= est URI and the contact address is added to the Route header after the stor= ed path is inserted, which means that in this case the P-Called-Party-ID is= not strictly needed for delivery of the target address.

Further this mechanism is extended to allow PBX/corpora= te proxies to use P-Asserted-Identity instead of P-Preferred-Identity, whic= h is a more natural thing to do for corporate proxies.

Regarding the side note: This seems misleading as an SSP may very well= serve the domain name of =A0the enterprise, even if only for SIP traffic. = This can all be arranged with normal DNS infrastructure.=A0

<= /div>
Best Regards,
/Hans Erik van Elburg

On Thu, Jul 9, 2009 at 7:37 PM, Hadriel Kaplan <HKaplan@acmepacket.c= om> wrote:
Howdy,
As part of a discussion in the SIP Forum regarding a model for Registration= we are using for IP-PBX's, I was asked by someone to submit an I-D des= cribing it, in case it would be of any value. =A0Since I hadn't seen an= I-D before on how 3GPP/ETSI did their model, and since their model is diff= erent from SIP-Forum's, I submitted one which describes the models for = both SIP Forum's SIP-Connect v1.1 and 3GPP/ETSI.

NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP,= and I am still talking with colleagues in 3GPP to make sure I got that par= t right. =A0This is purely an individual submission in all respects.

Forwarded message:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Session Initiation Protocol (SI= P) Implicit Registrations
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-dispatch-sip-implici= t-registrations-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-07-05

This document identifies several approaches to provide reachability informa= tion for a domain or multiple AoR's using a single SIP REGISTER method = transaction, in ways not originally envisioned or documented by RFC 3261.
A URL for this Internet-Draft is:
http://www.ietf.org/internet= -drafts/draft-kaplan-dispatch-sip-implicit-registrations-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft.

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

--0015174be630ca308c046f2417be-- From mdolly@att.com Mon Jul 20 10:04:49 2009 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 6AF2528C21D for ; Mon, 20 Jul 2009 10:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 OZ61gl3fbj24 for ; Mon, 20 Jul 2009 10:04:42 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 39C4028C215 for ; Mon, 20 Jul 2009 10:04:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1248109469!20444981!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 25653 invoked from network); 20 Jul 2009 17:04:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jul 2009 17:04:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6KH4SdF026879 for ; Mon, 20 Jul 2009 13:04:28 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6KH4QxX026855 for ; Mon, 20 Jul 2009 13:04:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 20 Jul 2009 13:04:25 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD48D0@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OMA-Push draft Thread-Index: AcoFe0EnQSQc9CKFRGGN/LiEtWtTiADwhZtwAACV3RAABxzuXg== From: "DOLLY, MARTIN C, ATTLABS" To: Cc: "SULLIVAN, BRYAN L, ATTCINW" Subject: Re: [dispatch] OMA-Push 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: Mon, 20 Jul 2009 17:04:49 -0000 DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IERPTExZLCBNQVJUSU4gQywg QVRUTEFCUw0KVG86IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgPGRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmc+DQpDYzogU1VMTElWQU4sIEJSWUFOIEwsIEFUVENJTlc7IFNhbHZhdG9yZSBMb3Jl dG8gPHNhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPg0KU2VudDogTW9uIEp1bCAyMCAwOTo0 NToyNSAyMDA5DQpTdWJqZWN0OiBPTUEtUHVzaCBkcmFmdA0KDQpHcmVldGluZ3MsDQoNCkxpbmsg Zm9yIGFuIGluZGl2aWR1YWwgcHJvcG9zYWwgZm9yIHJlZ2lzdHJhdGlvbiBvZiBhIFNJUCBldmVu dCBwYWNrYWdlIGluIHN1cHBvcnQgb2YgT01BLVBVU0g6DQoNCmh0dHA6Ly93d3cuc2xvcmV0by5j b20vdG1wL2RyYWZ0LW1kb2xseS1kaXNwYXRjaC1vbWEtcHVzaC0wMC50eHQNCg0KVGhhbmsgeW91 LA0KDQpNYXJ0aW4NCg0K From mramalho@cisco.com Mon Jul 20 11:28:17 2009 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 22DCA3A69F7; Mon, 20 Jul 2009 11:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Od6Ns-EiAKb7; Mon, 20 Jul 2009 11:28:16 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B4DA13A6359; Mon, 20 Jul 2009 11:28:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAORSZEpAZnmf/2dsb2JhbAC6H4gjjjYFhAw X-IronPort-AV: E=Sophos;i="4.43,235,1246838400"; d="scan'208";a="51069629" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2009 18:20:29 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6KIKTIk019774; Mon, 20 Jul 2009 14:20:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6KIKTrO005596; Mon, 20 Jul 2009 18:20:29 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 14:20:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2009 14:20:29 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [dispatch] Proposal to form Internet Wideband AudioCodec WG Thread-Index: Acnkg+tPW7/Qit8kSMO3DzsL4DUqDgAdZA9wCO9h3LA= X-Priority: 5 Priority: Non-Urgent Importance: low References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com><4A2541B9.2000805@octasic.com><00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> From: "Michael Ramalho (mramalho)" To: "DRAGE, Keith (Keith)" , "Dan York" , X-OriginalArrivalTime: 20 Jul 2009 18:20:29.0464 (UTC) FILETIME=[C2E5E180:01CA0966] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4299; t=1248114029; x=1248978029; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20RE=3A=20[AVT]=20[dispatch]=20Proposal=20to=20fo rm=20Internet=20Wideband=20AudioCodec=09WG |Sender:=20 |To:=20=22DRAGE,=20Keith=20(Keith)=22=20,=0A=20=20=20=20=20=20=20=20=22Dan=20York=22=20,=20; bh=exuTRJq18PCVlDOpB6f0RewSGMHnG84ivf+puVpdVYE=; b=qMYy2Lj+9CzspHgYGb6Lcn8kycU/m1lToDRKrF1kLwk1oG4f/BOXUF7o2o 185zmKIFpYb5hyAfnr24az3nuFFAp/6qPr1awSdPIuxV7uKIaQHgy+xHipS9 kkJ5pXzGKR; Authentication-Results: rtp-dkim-2; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Mon, 20 Jul 2009 11:41:38 -0700 Cc: avt@ietf.org Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband AudioCodec WG 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, 20 Jul 2009 18:28:17 -0000 Keith, Comments in-line w/MAR: Regards, Michael A. Ramalho, Ph.D. -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, June 04, 2009 6:01 AM To: Dan York; dispatch@ietf.org Cc: avt@ietf.org Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband AudioCodec WG I would argue that G.711 is implemented, not because anyone can implement it, but because everyone else has implemented it. It essentially forms the lowest common denominator for interoperability. If fancy codec x doesn't work, then assuming you have the bandwidth availabile, G.711 probably will. And I suspect it is royalty free not because it was always so, but because any IPR that existed has pretty much expired by now. G.711 is also the one codec that is probably the most neutral to transcoding. I can do to codec A to G.711 and back to codec A with less impact that with any other intermediate codec. MAR: Let's look at that statement. G.711 is a simple *waveform* codec that achieves a (single frequency) SNR of approximately 25 dB over an approximate 25 dB dynamic range. The reason why you can "go to G.711 and back" is simply that the other (narrowband) codecs you use have less fidelity (i.e., on average much more distortion - or equivalently lesser SNR). The distortion introduced by G.711 is less than the distortion already introduced by the other codecs. MAR: An equivalent statement is that for the 0 - 4kHz band (narrowband), 25 dB SNR is good enough for telephony. For wideband there probably is not any one codec that has achieved that position. MAR: Well, the game changes with VOICE when it comes to wideband. Speech has a spectral tilt to it - lesser power per Hz with increasing frequency (as it comes from a finite energy acoustic source - this MUST be the case in the limit). The end result is that a PSD for an ensemble of speech signals has approximately 6dB less energy per octave (i.e., over all phonetic content). MAR: If you use G.711 for wideband (16k sampling) - the higher frequencies will have more distortion (i.e., much less than 25 dB). Thus G.711 sounds somewhat bad in wideband application due to this. MAR: What I believe you are asking for is: 1) a simple "waveform codec", 2) but one that is "pre-equalized" to whiten the spectral tilt in speech signals. For example, virtually all filter-band-based codecs (e.g., MLT/MCT-based) do this via the "bit allocation" process (sometimes in conjunction with pre-emphasis). MAR: I believe most of the codecs proposed for this proposed "codec" working group are speech-model based. If you want a "waveform based" solution that you can "transform into and out of" (something which I call a "do-no-harm" codec property) - you simply need pre-equalization plus a relatively simple waveform codec behind it (G.711 or something nearly as simple). MAR: Note these codecs will be less bandwidth efficient than the usual (model-based) suspects - as the model-based codecs generally only parameterize the spectrum (NOT the waveform) above 4kHz. But give me 60~90 kbps ... and such a codec becomes a relatively easy task for any signal processing graduate student (at least one that would have me on their thesis committee). MAR: Lastly, waveform based codecs are generally better for speech recognition applications - a quality that we might also desire to consider. I don't believe building a better, even royalty free codec, will guarantee a position in the market place. The world is littered with better solutions that never made it. You need a market where everyone chooses to implement it so that you can use that codec without having to go to transcoding. Pasting IETF on the front cover does not achieve that. I don't really have a problem with people trying to sit down and design a new codec and IETF then publishing it. Without some other selling point however it just becomes yet another codec competing for market place. As such, put it somewhere where it does not interfere with other work. Sticking it on a separate mailing list, and not letting it compete for valuable IETF face to face slots as a working group is fine. regards Keith =20 From HKaplan@acmepacket.com Mon Jul 20 14:02:41 2009 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 494DF3A6B9F for ; Mon, 20 Jul 2009 14:02:41 -0700 (PDT) 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=[AWL=-0.000, 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 qWKuymzKezNO for ; Mon, 20 Jul 2009 14:02:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A5CEC3A67D7 for ; Mon, 20 Jul 2009 14:02:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 20 Jul 2009 16:49:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 20 Jul 2009 16:49:23 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Mon, 20 Jul 2009 16:49:22 -0400 Thread-Topic: [dispatch] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt Thread-Index: AcoJR8tEuegax06VR5CxbDURJjLvygAM1MxA Message-ID: References: <9ae56b1e0907200738n6685284l17d1282fd0653b9@mail.gmail.com> In-Reply-To: <9ae56b1e0907200738n6685284l17d1282fd0653b9@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC3196CEBD111mail_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt 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, 20 Jul 2009 21:02:41 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC3196CEBD111mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the feedback! Yes I agree I need to add the references explicitly into the reference sect= ion. I also got some similar comments from other folks, so I'll update it with t= he consolidated set once the submission tool is open (and once we finalize = this in SIP-Forum as well - it's still under debate). -hadriel ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Monday, July 20, 2009 10:39 AM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-= registrations-00.txt Hi Hadriel, Thanks for putting this together, this is useful. - General I think it would be good to add some informative references to the ETSI TIS= PAN specification where the NGN/IMS way of performing business trunking (SI= P trunking) has been specified using the concept of implicitly registered w= ildcarded public user identities (AORs) The specification numbers are: ETSI TS 181 019 V2.0.0 (2007-11) Telecommunications and Internet converged Services and Protocols for Advanc= ed Networking (TISPAN);Business Communication Requirements ETSI TS 182 023 V2.1.1 (2009-01) Telecommunications and Internet converged Services and Protocols for Advanc= ed Networking (TISPAN);Core and enterprise NGN interaction scenarios;Archit= ecture and functional description ETSI TS 182 025 V2.1.1 (2008-09) Telecommunications and Internet converged Services and Protocols for Advanc= ed Networking (TISPAN);Business trunking;Architecture and functional descri= ption I think it would also be good to add informative references to the SIP Conn= ect specifications. Further it might be good to say something about the different viewpoints ta= ken by the different bodies: - ETSI TISPAN/3GPP Business Trunking are providing the viewpoint of the ser= vice provider connecting IP-PBX's to its IMS/NGN infrastructure - SIP Connect is more looking at the interconnect specifciation between the= an SSP and a IP-PBX. Ideally both should match at some point to get an interoperable corporate c= ommunication space. - Section 6.2 The 3GPP/ETSI TISPAN mechanism does not add the notion of wildcarded P-Asso= ciated-URI, but it adds the notion of wildcarded public user identity, whic= h generates so to speak the set of public user identioties to be registered= . This is not only visible on the P-Associated-URI header but also makes co= nfiguration of such sets of public user identities easier. 3GPP and ETSI have extended the mechanism described here with the following= additions, for connected PBX's a subscription parameter can be set that al= lows delivery of the target URI is kept in the request URI and the contact = address is added to the Route header after the stored path is inserted, whi= ch means that in this case the P-Called-Party-ID is not strictly needed for= delivery of the target address. Further this mechanism is extended to allow PBX/corporate proxies to use P-= Asserted-Identity instead of P-Preferred-Identity, which is a more natural = thing to do for corporate proxies. Regarding the side note: This seems misleading as an SSP may very well serv= e the domain name of the enterprise, even if only for SIP traffic. This ca= n all be arranged with normal DNS infrastructure. Best Regards, /Hans Erik van Elburg On Thu, Jul 9, 2009 at 7:37 PM, Hadriel Kaplan > wrote: Howdy, As part of a discussion in the SIP Forum regarding a model for Registration= we are using for IP-PBX's, I was asked by someone to submit an I-D describ= ing it, in case it would be of any value. Since I hadn't seen an I-D befor= e on how 3GPP/ETSI did their model, and since their model is different from= SIP-Forum's, I submitted one which describes the models for both SIP Forum= 's SIP-Connect v1.1 and 3GPP/ETSI. NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP,= and I am still talking with colleagues in 3GPP to make sure I got that par= t right. This is purely an individual submission in all respects. Forwarded message: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Session Initiation Protocol (SIP) Implicit Registr= ations Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-sip-implicit-registrations-0= 0.txt Pages : 12 Date : 2009-07-05 This document identifies several approaches to provide reachability informa= tion for a domain or multiple AoR's using a single SIP REGISTER method tran= saction, in ways not originally envisioned or documented by RFC 3261. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-sip-implicit-regi= strations-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_E6C2E8958BA59A4FB960963D475F7AC3196CEBD111mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for the feedback!

Yes I agree I need to add the referenc= es explicitly into the reference section.

I also got some similar comments from other folks, so I’ll update it with the consolidated set once the submission tool is open (and once we finalize this in SIP-Forum as well = 211; it’s still under debate).

-hadriel

 

 

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Monday, July 20, 2009 = 10:39 AM
To: Hadriel Kaplan
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Fwd:= I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt

 

Hi Hadriel,

 

Thanks for putting this together, this is useful.

 

- General<= /font>

I think it would be good to add some informative references to the = ETSI TISPAN specification where the NGN/IMS way of performing business trunking = (SIP trunking) has been specified using the concept of implicitly registered wildcarded public user identities (AORs)

 

The specification numbers are:

ETSI TS 181 019 <= /b>V2.0.0 (2007-11)
Telecommunications and Internet converged Services and Protocols for Advanc= ed Networking (TISPAN);Business Communicat= ion Requirements


ETSI TS 182 023 V2.1.1 (2009= -01)
Telecommunications and Internet converged Services and Protocols for Advanc= ed Networking (TISPAN);Core and enterprise= NGN interaction scenarios;Architecture and functional description

ETSI TS 182 025 V2.1.1 <= /font>(2008-09)
Telecommunications and Internet converged Services and Protocols for Advanc= ed Networking (TISPAN);Business trunking;Architecture and functional description

 

I think it would also be good to add informative references to the = SIP Connect specifications.

 

Further it might be good to say something about the different viewpoints taken by the different bodies:

- ETSI TISPAN/3GPP Business Trunking are providing the viewpoint of= the service provider connecting IP-PBX's to its IMS/NGN infrastructure

- SIP Connect is more looking at the interconnect specifciation bet= ween the an SSP and a IP-PBX.

 

Ideally both should match at some point to get an interoperable corporate communication space.

 

- Section 6.2

The 3GPP/ETSI TISPAN mechanism does not add the notion of wildcarde= d P-Associated-URI, but it adds the notion of wildcarded public user identity= , which generates so to speak the set of public user identioties to be registered. This is not only visible on the P-Associated-URI header but als= o makes configuration of such sets of public user identities easier.

 

3GPP and ETSI have extended the mechanism described here with the following additions, for connected PBX's a subscription parameter can be se= t that allows delivery of the target URI is kept in the request URI and the contact address is added to the Route header after the stored path is inser= ted, which means that in this case the P-Called-Party-ID is not strictly needed = for delivery of the target address.

 

Further this mechanism is extended to allow PBX/corporate proxies t= o use P-Asserted-Identity instead of P-Preferred-Identity, which is a more natural thing to do for corporate proxies.

 

Regarding the side note: This seems misleading as an SSP may very w= ell serve the domain name of  the enterprise, even if only for SIP traffic= . This can all be arranged with normal DNS infrastructure. 

 

Best Regards,

/Hans Erik van Elburg<= o:p>

 

On Thu, Jul 9, 2009 at 7:37 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote= :

Howdy,
As part of a discussion in the SIP Forum regarding a model for Registration= we are using for IP-PBX's, I was asked by someone to submit an I-D describing = it, in case it would be of any value.  Since I hadn't seen an I-D before o= n how 3GPP/ETSI did their model, and since their model is different from SIP-= Forum's, I submitted one which describes the models for both SIP Forum's SIP-Connect v1.1 and 3GPP/ETSI.

NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP,= and I am still talking with colleagues in 3GPP to make sure I got that part rig= ht.  This is purely an individual submission in all respects.

Forwarded message:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

       Title           : Sessi= on Initiation Protocol (SIP) Implicit Registrations
       Author(s)       : H. Kaplan
       Filename        : draft-kaplan-dispatch-sip-implicit-registrations-00.txt
       Pages           : 12        Date            : 2009-07-05

This document identifies several approaches to provide reachability informa= tion for a domain or multiple AoR's using a single SIP REGISTER method transacti= on, in ways not originally envisioned or documented by RFC 3261.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch= -sip-implicit-registrations-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft.

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

 

--_000_E6C2E8958BA59A4FB960963D475F7AC3196CEBD111mail_-- From R.Jesske@telekom.de Mon Jul 20 22:03:29 2009 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 21ACA3A657C for ; Mon, 20 Jul 2009 22:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 uAPPB9tLGtfB for ; Mon, 20 Jul 2009 22:03:28 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id B9BDC3A68D9 for ; Mon, 20 Jul 2009 22:03:26 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 21 Jul 2009 07:03:11 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 07:03:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2009 07:03:10 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4A643B95.3060800@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukw References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> <4A643B95.3060800@ericsson.com> From: To: , X-OriginalArrivalTime: 21 Jul 2009 05:03:10.0948 (UTC) FILETIME=[8B556240:01CA09C0] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 21 Jul 2009 05:03:29 -0000 Hi Gonzalo, Thank you for your comments. You are correct. The used cases within the document shows where ISUP = causes will be included. I think in such cases we should clearly state that SIP Reason should be = excluded within SIP responses, to avoid contradictions.=20 Then I will include that only within 4xx/5xx/6xx Responses the Reason = header with an Q.850 Cause makes sense. There are requirements and three used cases described within the draft = so I hope that fits.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Gesendet: Montag, 20. Juli 2009 11:41 An: Francois Audet Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Hi, as Francois suggests, a document specifying the use of Reason header=20 fields in responses needs to specify those things (see Francois' list=20 below). Additionally, you should think of whether or not Reason header=20 fields in responses can carry SIP status codes and what happens if they=20 are different to the status code of the response. In short, the document cannot simply say that now it is OK to use Reason = in responses. It needs to address the different situations a typical=20 implementation may face. Cheers, Gonzalo Francois Audet wrote: > Again, the spec is very clear that it IS allowed. >=20 > I believe the wishy-washy text about "status code explicitly > allowing it" was meant to exclude responses that were not appropriate, > and restricing it to effectively error responses. >=20 > At the time this was written, I believe we were not clear on which > codes were supposed to be appropriate or not. >=20 > Seems to me: > - Any Error response code should be allowed. > - I don't think 2XX makes sense. > - 3XX is controversial (as per the email quoted by Roland): seems to = me it > would be quite useful > - Provisional is interesting... Sounds like 199 error response to = me... >=20 >> -----Original Message----- >> From: Worley, Dale (BL60:9D30)=20 >> Sent: Thursday, July 16, 2009 10:09 >> To: Audet, Francois (SC100:3055) >> Cc: R.Jesske@telekom.de; dispatch@ietf.org >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >> >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) = wrote: >>> Hi Roland, >>> >>> You use case is very common. =20 >>> >>> I believe you are incorrect in saying that "reasons are=20 >> currently not=20 >>> allowed in responses. Neither conditionally nor allowed". >>> >>> RFC 3326 says in 1.0: >>> "[...] it can appear in any request >>> within a dialog, in any CANCEL request and in any response whose >>> status code explicitly allows the presence of this header field." >>> >>> To be honest, I believe Q.850 codes are much more common in=20 >> Responses=20 >>> than in requests. >> Googling >> >> "sip/2.0" reason "q.850" >> >> turns up numerous examples of SIP responses using the Reason=20 >> header in the forbidden manner. >> >> I'd say that your draft formally allows what people are already = doing. >> >> Dale >> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From gonzalo.camarillo@ericsson.com Tue Jul 21 00:53:58 2009 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 63D3428C198 for ; Tue, 21 Jul 2009 00:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.667 X-Spam-Level: X-Spam-Status: No, score=-4.667 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, 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 m-2imxe5OPJL for ; Tue, 21 Jul 2009 00:53:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BB4833A6E43 for ; Tue, 21 Jul 2009 00:53:27 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-eb-4a6573f3ed31 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id EF.D8.14528.3F3756A4; Tue, 21 Jul 2009 09:53:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 09:53:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 09:53:22 +0200 Received: from [131.160.126.242] (rvi2-126-242.lmf.ericsson.se [131.160.126.242]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 56924245F; Tue, 21 Jul 2009 10:53:22 +0300 (EEST) Message-ID: <4A6573F2.6020006@ericsson.com> Date: Tue, 21 Jul 2009 10:53:22 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> <4A643B95.3060800@ericsson.com> <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Jul 2009 07:53:22.0738 (UTC) FILETIME=[5208E120:01CA09D8] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 21 Jul 2009 07:53:58 -0000 Hi, yes, it is normal that the draft has focused on requirements and use cases so far. Once (or if) folks agree with those, we have to make sure that the normative behavior we define is correct and covers most typical cases. Thanks, Gonzalo R.Jesske@telekom.de wrote: > Hi Gonzalo, > Thank you for your comments. > You are correct. The used cases within the document shows where ISUP causes will be included. > I think in such cases we should clearly state that SIP Reason should be excluded within SIP responses, to avoid contradictions. > > Then I will include that only within 4xx/5xx/6xx Responses the Reason header with an Q.850 Cause makes sense. > > There are requirements and three used cases described within the draft so I hope that fits. > > Best Regards > > Roland > -----Ursprüngliche Nachricht----- > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Gesendet: Montag, 20. Juli 2009 11:41 > An: Francois Audet > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > Hi, > > as Francois suggests, a document specifying the use of Reason header > fields in responses needs to specify those things (see Francois' list > below). Additionally, you should think of whether or not Reason header > fields in responses can carry SIP status codes and what happens if they > are different to the status code of the response. > > In short, the document cannot simply say that now it is OK to use Reason > in responses. It needs to address the different situations a typical > implementation may face. > > Cheers, > > Gonzalo > > > Francois Audet wrote: >> Again, the spec is very clear that it IS allowed. >> >> I believe the wishy-washy text about "status code explicitly >> allowing it" was meant to exclude responses that were not appropriate, >> and restricing it to effectively error responses. >> >> At the time this was written, I believe we were not clear on which >> codes were supposed to be appropriate or not. >> >> Seems to me: >> - Any Error response code should be allowed. >> - I don't think 2XX makes sense. >> - 3XX is controversial (as per the email quoted by Roland): seems to me it >> would be quite useful >> - Provisional is interesting... Sounds like 199 error response to me... >> >>> -----Original Message----- >>> From: Worley, Dale (BL60:9D30) >>> Sent: Thursday, July 16, 2009 10:09 >>> To: Audet, Francois (SC100:3055) >>> Cc: R.Jesske@telekom.de; dispatch@ietf.org >>> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >>> >>> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) wrote: >>>> Hi Roland, >>>> >>>> You use case is very common. >>>> >>>> I believe you are incorrect in saying that "reasons are >>> currently not >>>> allowed in responses. Neither conditionally nor allowed". >>>> >>>> RFC 3326 says in 1.0: >>>> "[...] it can appear in any request >>>> within a dialog, in any CANCEL request and in any response whose >>>> status code explicitly allows the presence of this header field." >>>> >>>> To be honest, I believe Q.850 codes are much more common in >>> Responses >>>> than in requests. >>> Googling >>> >>> "sip/2.0" reason "q.850" >>> >>> turns up numerous examples of SIP responses using the Reason >>> header in the forbidden manner. >>> >>> I'd say that your draft formally allows what people are already doing. >>> >>> Dale >>> >>> >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From gonzalo.camarillo@ericsson.com Tue Jul 21 01:05:17 2009 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 1A9DC28C198 for ; Tue, 21 Jul 2009 01:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.713 X-Spam-Level: X-Spam-Status: No, score=-4.713 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, 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 kXWEeNtV1IkX for ; Tue, 21 Jul 2009 01:05:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E0FC228C1A2 for ; Tue, 21 Jul 2009 01:05:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-4d-4a6576ba045f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 66.87.00514.AB6756A4; Tue, 21 Jul 2009 10:05:14 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 10:05:14 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 10:05:13 +0200 Received: from [131.160.126.242] (rvi2-126-242.lmf.ericsson.se [131.160.126.242]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3078D245F; Tue, 21 Jul 2009 11:05:13 +0300 (EEST) Message-ID: <4A6576B9.4020504@ericsson.com> Date: Tue, 21 Jul 2009 11:05:13 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> In-Reply-To: <4A646BAF.7030007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 08:05:13.0514 (UTC) FILETIME=[F9B0B0A0:01CA09D9] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 08:05:17 -0000 Hi Paul, it is good that we agree that some problems need both ends to collaborate. Now, let's discuss whether or not that is the case with *this* problem. > I still haven't seen anything showing why this approach ends up being > "better" than the "centralized" approach. (Note that I don't agree with > the term "centralized", because it isn't really more centralized than > the "distributed" approach is. This would become clearer if we looked at > all the communications necessary to establish a call with disaggregated > media, and the various topologies of devices that might play in such > scenarios.) well, 3pcc is centralized because you have a (central) controller that is in control of all SIP signalling. If that controller leaves the session, the whole session disappears. An approach where several devices have their own SIP dialog with the remote devices is not centralized because you can remove any of them and the other sessions will remain unaffected. > Perhaps we should back off from the signaling mechanisms for the moment > and consider the use cases of interest in more detail, and the various > sorts of communications between them that are necessary to establish a > call that involves them. The arguments have been discussed several times. The thing is that 3pcc is a complex mechanism that is not supported by most UAs. You can argue about its complexity, but the fact that most UAs do not support 3pcc is a fact. There are folks that are willing to implement support for a correlation mechanism for dialogs but would not implement 3pcc because (they think) it is too complicated. A second argument is that any device should be able to leave the session at any point. If you want the 3pcc controller to leave the session while the session remains established, you will need to use a complex combination of REFER and Replaces that very few (if any) UAs support. Therefore, the requirement here is that the mechanism should not be so complicated that implementers do not actually want to implement it :o) ... unfortunately, as we all know too well, we have a history of doing just that. Cheers, Gonzalo From john.elwell@siemens-enterprise.com Tue Jul 21 05:43:08 2009 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 9C41728C0EC for ; Tue, 21 Jul 2009 05:43:08 -0700 (PDT) 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 hTpw42qENfUF for ; Tue, 21 Jul 2009 05:43:07 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D85E63A6897 for ; Tue, 21 Jul 2009 05:43:06 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN400EA9TYRHR@siemenscomms.co.uk> for dispatch@ietf.org; Tue, 21 Jul 2009 13:42:27 +0100 (BST) Date: Tue, 21 Jul 2009 13:42:31 +0100 From: "Elwell, John" In-reply-to: <4A6576B9.4020504@ericsson.com> To: Gonzalo Camarillo , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: AcoJ2gBcCHuZ4nZ7Qu+GBWwheObMrAAJH+pw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 12:43:08 -0000 Gonzalo, I have already expressed opinions similar to Paul on several occasions. Experience tells us we cannot rely on the remote UA supporting a particular feature. Taking REFER as an example, we tend to end up with a B2BUA terminating a REFER request, because: - the remote UA doesn't support REFER; - some UAs don't support REFER, so if the B2BUA sometimes needs to terminate REFER to accommodate those UAs, it might as well always terminate REFER; - some UAs don't accept REFER as a matter of policy. So B2BUAs tend to act as an anchor point and terminate REFER requests, behaving in a 3PCC-like manner. If the distributed form of disaggregated media goes ahead, I think that is what will happen in practice, i.e., a B2BUA will need to act as the anchor point. If UAs wanting to use disaggregated media are behind a B2BUA that concentrates the multiple dialogs into a single ongoing dialog towards the remote UA, that will work. It does indeed have the benefit that one local UA can drop out, leaving the other local UA(s) still in communication with the remote UA. Relying on the remote UA supporting distributed disaggregated media I fear will prevent the capability being used in many cases where it might be required. As part of specifying distributed disaggregated media, we will need to pay attention to all the interactions that can occur when both sides attempt to use disaggregated media, particular when the two sides simultaneously try to add or remove UAs. This sounds like a difficult problem, but I may be wrong. Having an anchor point (thereby making it centralised, in a way) would probably ease these problems. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 21 July 2009 09:05 > To: Paul Kyzivat > Cc: dispatch@ietf.org; Henry Sinnreich > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 > Hi Paul, >=20 > it is good that we agree that some problems need both ends to=20 > collaborate. Now, let's discuss whether or not that is the case with=20 > *this* problem. >=20 > > I still haven't seen anything showing why this approach=20 > ends up being=20 > > "better" than the "centralized" approach. (Note that I=20 > don't agree with=20 > > the term "centralized", because it isn't really more=20 > centralized than=20 > > the "distributed" approach is. This would become clearer if=20 > we looked at=20 > > all the communications necessary to establish a call with=20 > disaggregated=20 > > media, and the various topologies of devices that might=20 > play in such=20 > > scenarios.) >=20 > well, 3pcc is centralized because you have a (central)=20 > controller that=20 > is in control of all SIP signalling. If that controller leaves the=20 > session, the whole session disappears. An approach where=20 > several devices=20 > have their own SIP dialog with the remote devices is not centralized=20 > because you can remove any of them and the other sessions will remain=20 > unaffected. >=20 > > Perhaps we should back off from the signaling mechanisms=20 > for the moment=20 > > and consider the use cases of interest in more detail, and=20 > the various=20 > > sorts of communications between them that are necessary to=20 > establish a=20 > > call that involves them. >=20 > The arguments have been discussed several times. The thing is=20 > that 3pcc=20 > is a complex mechanism that is not supported by most UAs. You=20 > can argue=20 > about its complexity, but the fact that most UAs do not=20 > support 3pcc is=20 > a fact. >=20 > There are folks that are willing to implement support for a=20 > correlation=20 > mechanism for dialogs but would not implement 3pcc because=20 > (they think)=20 > it is too complicated. >=20 > A second argument is that any device should be able to leave=20 > the session=20 > at any point. If you want the 3pcc controller to leave the=20 > session while=20 > the session remains established, you will need to use a complex=20 > combination of REFER and Replaces that very few (if any) UAs support. >=20 > Therefore, the requirement here is that the mechanism should=20 > not be so=20 > complicated that implementers do not actually want to=20 > implement it :o)=20 > ... unfortunately, as we all know too well, we have a history=20 > of doing=20 > just that. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From gonzalo.camarillo@ericsson.com Tue Jul 21 07:51:29 2009 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 15A1B3A6E6E for ; Tue, 21 Jul 2009 07:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, 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 mzqiFb4PkyXf for ; Tue, 21 Jul 2009 07:51:28 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1D90D3A6E5F for ; Tue, 21 Jul 2009 07:51:27 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-d3-4a65d0fde8e7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2F.B6.14528.DF0D56A4; Tue, 21 Jul 2009 16:30:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:29:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:29:49 +0200 Received: from [131.160.126.242] (rvi2-126-242.lmf.ericsson.se [131.160.126.242]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 94CA5245F; Tue, 21 Jul 2009 17:29:49 +0300 (EEST) Message-ID: <4A65D0DD.409@ericsson.com> Date: Tue, 21 Jul 2009 17:29:49 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 14:29:49.0879 (UTC) FILETIME=[B4468C70:01CA0A0F] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Overload charter discussions 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, 21 Jul 2009 14:51:29 -0000 Folks, our charter includes the following milestone: Aug 2009 Proposed charter for SIP Overload WG Volker (in the cc:) will be circulating a charter proposal for such a WG on this list shortly. Additionally, according to its authors, the following draft should be ready for WGLC: draft-ietf-sipping-overload-design-02 Given that we are chartered to form a WG on SIP overload, we will include this draft as the first milestone for the new WG. Therefore, this draft will be WGLC in the new WG. Cheers, Gonzalo DISPATCH co-chair From gonzalo.camarillo@ericsson.com Tue Jul 21 07:55:10 2009 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 C38D73A6E80 for ; Tue, 21 Jul 2009 07:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-1.661, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35] 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 KMgogoBNqhuy for ; Tue, 21 Jul 2009 07:55:09 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C92533A6E7C for ; Tue, 21 Jul 2009 07:53:32 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-63-4a65d2bb31ad Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 7D.F9.18827.BB2D56A4; Tue, 21 Jul 2009 16:37:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:36:48 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 16:36:47 +0200 Received: from [131.160.126.242] (rvi2-126-242.lmf.ericsson.se [131.160.126.242]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4AAE4245F; Tue, 21 Jul 2009 17:36:47 +0300 (EEST) Message-ID: <4A65D27F.1060604@ericsson.com> Date: Tue, 21 Jul 2009 17:36:47 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Elwell, John" References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 14:36:47.0701 (UTC) FILETIME=[AD512050:01CA0A10] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 14:55:10 -0000 Hi John, many UAs already support multiple SIP dialogs in parallel. Adding a header that instruct them to treat the media sessions related to those dialogs as a single one is much easier than anything you have described in your email. The point is that people are going to implement something like this because it is fairly simple and it is needed. We can either design a mechanism that meets their simplicity requirement or propose complex mechanisms that, as usual, will not get implemented. Cheers, Gonzalo Elwell, John wrote: > Gonzalo, > > I have already expressed opinions similar to Paul on several occasions. > Experience tells us we cannot rely on the remote UA supporting a > particular feature. Taking REFER as an example, we tend to end up with a > B2BUA terminating a REFER request, because: > - the remote UA doesn't support REFER; > - some UAs don't support REFER, so if the B2BUA sometimes needs to > terminate REFER to accommodate those UAs, it might as well always > terminate REFER; > - some UAs don't accept REFER as a matter of policy. > > So B2BUAs tend to act as an anchor point and terminate REFER requests, > behaving in a 3PCC-like manner. > > If the distributed form of disaggregated media goes ahead, I think that > is what will happen in practice, i.e., a B2BUA will need to act as the > anchor point. If UAs wanting to use disaggregated media are behind a > B2BUA that concentrates the multiple dialogs into a single ongoing > dialog towards the remote UA, that will work. It does indeed have the > benefit that one local UA can drop out, leaving the other local UA(s) > still in communication with the remote UA. Relying on the remote UA > supporting distributed disaggregated media I fear will prevent the > capability being used in many cases where it might be required. > > As part of specifying distributed disaggregated media, we will need to > pay attention to all the interactions that can occur when both sides > attempt to use disaggregated media, particular when the two sides > simultaneously try to add or remove UAs. This sounds like a difficult > problem, but I may be wrong. Having an anchor point (thereby making it > centralised, in a way) would probably ease these problems. > > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: 21 July 2009 09:05 >> To: Paul Kyzivat >> Cc: dispatch@ietf.org; Henry Sinnreich >> Subject: Re: [dispatch] Disaggregated Media in SIP >> >> Hi Paul, >> >> it is good that we agree that some problems need both ends to >> collaborate. Now, let's discuss whether or not that is the case with >> *this* problem. >> >>> I still haven't seen anything showing why this approach >> ends up being >>> "better" than the "centralized" approach. (Note that I >> don't agree with >>> the term "centralized", because it isn't really more >> centralized than >>> the "distributed" approach is. This would become clearer if >> we looked at >>> all the communications necessary to establish a call with >> disaggregated >>> media, and the various topologies of devices that might >> play in such >>> scenarios.) >> well, 3pcc is centralized because you have a (central) >> controller that >> is in control of all SIP signalling. If that controller leaves the >> session, the whole session disappears. An approach where >> several devices >> have their own SIP dialog with the remote devices is not centralized >> because you can remove any of them and the other sessions will remain >> unaffected. >> >>> Perhaps we should back off from the signaling mechanisms >> for the moment >>> and consider the use cases of interest in more detail, and >> the various >>> sorts of communications between them that are necessary to >> establish a >>> call that involves them. >> The arguments have been discussed several times. The thing is >> that 3pcc >> is a complex mechanism that is not supported by most UAs. You >> can argue >> about its complexity, but the fact that most UAs do not >> support 3pcc is >> a fact. >> >> There are folks that are willing to implement support for a >> correlation >> mechanism for dialogs but would not implement 3pcc because >> (they think) >> it is too complicated. >> >> A second argument is that any device should be able to leave >> the session >> at any point. If you want the 3pcc controller to leave the >> session while >> the session remains established, you will need to use a complex >> combination of REFER and Replaces that very few (if any) UAs support. >> >> Therefore, the requirement here is that the mechanism should >> not be so >> complicated that implementers do not actually want to >> implement it :o) >> ... unfortunately, as we all know too well, we have a history >> of doing >> just that. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From john.elwell@siemens-enterprise.com Tue Jul 21 08:39:43 2009 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 7EBA23A696E for ; Tue, 21 Jul 2009 08:39:43 -0700 (PDT) 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 9eP7xBxXjsdN for ; Tue, 21 Jul 2009 08:39:42 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D23AF3A6848 for ; Tue, 21 Jul 2009 08:39:41 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN5002041YRTW@siemenscomms.co.uk> for dispatch@ietf.org; Tue, 21 Jul 2009 16:35:15 +0100 (BST) Date: Tue, 21 Jul 2009 16:35:14 +0100 From: "Elwell, John" In-reply-to: <4A65D27F.1060604@ericsson.com> To: Gonzalo Camarillo Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A3562@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] Disaggregated Media in SIP Thread-Index: AcoKEOJAoW32cVaHSSeQsSWS3adO2QAB0i9A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> <4A65D27F.1060604@ericsson.com> Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 15:39:43 -0000 Gonzalo, Well, my concern is that it might not be as simple as described when both sides use multiple UAs. If I am using 2 UAs, and you are using 2 UAs, presumably we end up with 4 dialogs - correct? John=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: 21 July 2009 15:37 > To: Elwell, John > Cc: Paul Kyzivat; dispatch@ietf.org; Henry Sinnreich > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 > Hi John, >=20 > many UAs already support multiple SIP dialogs in parallel. Adding a=20 > header that instruct them to treat the media sessions related=20 > to those=20 > dialogs as a single one is much easier than anything you have=20 > described=20 > in your email. >=20 > The point is that people are going to implement something like this=20 > because it is fairly simple and it is needed. We can either design a=20 > mechanism that meets their simplicity requirement or propose complex=20 > mechanisms that, as usual, will not get implemented. >=20 > Cheers, >=20 > Gonzalo >=20 > Elwell, John wrote: > > Gonzalo, > >=20 > > I have already expressed opinions similar to Paul on=20 > several occasions. > > Experience tells us we cannot rely on the remote UA supporting a > > particular feature. Taking REFER as an example, we tend to=20 > end up with a > > B2BUA terminating a REFER request, because: > > - the remote UA doesn't support REFER; > > - some UAs don't support REFER, so if the B2BUA sometimes needs to > > terminate REFER to accommodate those UAs, it might as well always > > terminate REFER; > > - some UAs don't accept REFER as a matter of policy. > >=20 > > So B2BUAs tend to act as an anchor point and terminate=20 > REFER requests, > > behaving in a 3PCC-like manner. > >=20 > > If the distributed form of disaggregated media goes ahead,=20 > I think that > > is what will happen in practice, i.e., a B2BUA will need to=20 > act as the > > anchor point. If UAs wanting to use disaggregated media are behind a > > B2BUA that concentrates the multiple dialogs into a single ongoing > > dialog towards the remote UA, that will work. It does=20 > indeed have the > > benefit that one local UA can drop out, leaving the other=20 > local UA(s) > > still in communication with the remote UA. Relying on the remote UA > > supporting distributed disaggregated media I fear will prevent the > > capability being used in many cases where it might be required. > >=20 > > As part of specifying distributed disaggregated media, we=20 > will need to > > pay attention to all the interactions that can occur when both sides > > attempt to use disaggregated media, particular when the two sides > > simultaneously try to add or remove UAs. This sounds like a=20 > difficult > > problem, but I may be wrong. Having an anchor point=20 > (thereby making it > > centralised, in a way) would probably ease these problems. > >=20 > > John > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org=20 > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >> Sent: 21 July 2009 09:05 > >> To: Paul Kyzivat > >> Cc: dispatch@ietf.org; Henry Sinnreich > >> Subject: Re: [dispatch] Disaggregated Media in SIP > >> > >> Hi Paul, > >> > >> it is good that we agree that some problems need both ends to=20 > >> collaborate. Now, let's discuss whether or not that is the=20 > case with=20 > >> *this* problem. > >> > >>> I still haven't seen anything showing why this approach=20 > >> ends up being=20 > >>> "better" than the "centralized" approach. (Note that I=20 > >> don't agree with=20 > >>> the term "centralized", because it isn't really more=20 > >> centralized than=20 > >>> the "distributed" approach is. This would become clearer if=20 > >> we looked at=20 > >>> all the communications necessary to establish a call with=20 > >> disaggregated=20 > >>> media, and the various topologies of devices that might=20 > >> play in such=20 > >>> scenarios.) > >> well, 3pcc is centralized because you have a (central)=20 > >> controller that=20 > >> is in control of all SIP signalling. If that controller leaves the=20 > >> session, the whole session disappears. An approach where=20 > >> several devices=20 > >> have their own SIP dialog with the remote devices is not=20 > centralized=20 > >> because you can remove any of them and the other sessions=20 > will remain=20 > >> unaffected. > >> > >>> Perhaps we should back off from the signaling mechanisms=20 > >> for the moment=20 > >>> and consider the use cases of interest in more detail, and=20 > >> the various=20 > >>> sorts of communications between them that are necessary to=20 > >> establish a=20 > >>> call that involves them. > >> The arguments have been discussed several times. The thing is=20 > >> that 3pcc=20 > >> is a complex mechanism that is not supported by most UAs. You=20 > >> can argue=20 > >> about its complexity, but the fact that most UAs do not=20 > >> support 3pcc is=20 > >> a fact. > >> > >> There are folks that are willing to implement support for a=20 > >> correlation=20 > >> mechanism for dialogs but would not implement 3pcc because=20 > >> (they think)=20 > >> it is too complicated. > >> > >> A second argument is that any device should be able to leave=20 > >> the session=20 > >> at any point. If you want the 3pcc controller to leave the=20 > >> session while=20 > >> the session remains established, you will need to use a complex=20 > >> combination of REFER and Replaces that very few (if any)=20 > UAs support. > >> > >> Therefore, the requirement here is that the mechanism should=20 > >> not be so=20 > >> complicated that implementers do not actually want to=20 > >> implement it :o)=20 > >> ... unfortunately, as we all know too well, we have a history=20 > >> of doing=20 > >> just that. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> >=20 >=20 From victor.pascual.avila@gmail.com Tue Jul 21 09:17:09 2009 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 931033A6BA3 for ; Tue, 21 Jul 2009 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_SUB_OBFU_Q1=0.227] 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 yqsbocTALS9Q for ; Tue, 21 Jul 2009 09:17:09 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id ABB3C3A6AAB for ; Tue, 21 Jul 2009 09:17:08 -0700 (PDT) Received: by ewy26 with SMTP id 26so3183587ewy.37 for ; Tue, 21 Jul 2009 09:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=AoF6GOXuaTUfEd2txOb1tWvAOWlX0PWru5FGnLS8fhk=; b=NMk8/8F79xoQDHI9hS6ZTUY7eVW8gVUrqLHgC4vNsMIrsaXiEvNWOy4fTjCcJ+M/+T azyh2fqXWFXI6dENCcZG17qHP/EYv0TaO093zpgYsp/mq+isnft/cGIzpEw+poV+iCMe wMTvwMeQ0hus3lOylwYLonuvr+v17cqo1WQ9I= 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 :content-type:content-transfer-encoding; b=dzGdKV1wZxO0PVKE2jP8paW/I+VX21gvL5sotJkE3MsuFivoBc6Ttk3BStY02tj6BS juCze8o9f3fMTB36RQmAINmkXTN0hQ54r2ku8Kji72sBqSMOKYEUEFcPJy0K9QMDHAL8 f6kW/0Zh4W++EKiuRMRalJITc5F2fNWqtIi9I= MIME-Version: 1.0 Received: by 10.216.10.74 with SMTP id 52mr1529811weu.226.1248193020638; Tue, 21 Jul 2009 09:17:00 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> Date: Tue, 21 Jul 2009 18:17:00 +0200 Message-ID: <618e24240907210917h61ce9a62jc5e078db2dda0934@mail.gmail.com> From: Victor Pascual Avila To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 21 Jul 2009 16:17:09 -0000 As mentioned in the below message, the authors would appreciate feedback as to whether this is helpful and going in the right direction. Thanks, -Victor 2009/6/29 Elwell, John : > There was an extensive discussion at IETF#74 on SIP Identity, where a goo= d many views were put forward. The only consensus seemed to be to continue = to discuss the topic. > > One of the themes during that discussion was to focus more on requirement= s, which the authors have attempted to do in this new draft: > http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs-0= 0.txt > > We would appreciate feedback as to whether this is helpful and going in t= he right direction, as well as detailed comments. > > I had hoped to do this a lot earlier, to trigger a discussion in time to = get something set up for DISPATCH at IETF#75, but I failed, and also I fail= ed to talk to the many of you who have interest in the topic and expressed = opinions in the past. But since the deadline is approaching, I thought it b= est to post the draft and let discussion continue on that basis. > > John > From gonzalo.camarillo@ericsson.com Tue Jul 21 09:23:59 2009 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 1A5A128C321 for ; Tue, 21 Jul 2009 09:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, 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 JssUZtlh7-Ii for ; Tue, 21 Jul 2009 09:23:58 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9F7C228C32C for ; Tue, 21 Jul 2009 09:23:56 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-62-4a65eb979c7c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id AB.F9.00514.79BE56A4; Tue, 21 Jul 2009 18:23:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:23:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:23:51 +0200 Received: from [131.160.126.242] (rvi2-126-242.lmf.ericsson.se [131.160.126.242]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D4C11245F; Tue, 21 Jul 2009 19:23:50 +0300 (EEST) Message-ID: <4A65EB96.6070803@ericsson.com> Date: Tue, 21 Jul 2009 19:23:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Elwell, John" References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> <4A65D27F.1060604@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3562@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022A3562@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2009 16:23:51.0244 (UTC) FILETIME=[A20C00C0:01CA0A1F] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 16:23:59 -0000 Hi, > Well, my concern is that it might not be as simple as described when > both sides use multiple UAs. there are two aspects: device coordination among a user's devices and dialog association. > If I am using 2 UAs, and you are using 2 > UAs, presumably we end up with 4 dialogs - correct? Not necessarily. The draft has several use cases. For example, you can use a pair of SIP-enabled speakers to play out my voice and a SIP-enabled giant screen while I send you audio from my mobile phone and video from an external SIP-enabled camera. In this case, there would be two dialogs: one from my camera to your screen and one from my mobile phone to your speakers. Cheers, Gonzalo From AUDET@nortel.com Tue Jul 21 10:12:48 2009 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 C958328C371 for ; Tue, 21 Jul 2009 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 NQDwtNrdfacL for ; Tue, 21 Jul 2009 10:12:47 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B33C428C370 for ; Tue, 21 Jul 2009 10:12:46 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6LHAlx10426; Tue, 21 Jul 2009 17:10:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2009 12:11:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F155A4D@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A6576B9.4020504@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: AcoJ2fxzI8vyYk8dQWGM6koN5mj+xAAS5Stg References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> From: "Francois Audet" To: "Gonzalo Camarillo" , "Paul Kyzivat" Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 17:12:48 -0000 I agree with Gonzalo. I my opinion, we need a very loosely coupled mechanism for this. = Something very simple. People who need a "centralized" approach will continue to use 3PCC. = Typically, those are not simple UAs like phones because of complexity, but Call = Centers and the likes. This is a different problem. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Tuesday, July 21, 2009 01:05 > To: Paul Kyzivat > Cc: Audet, Francois (SC100:3055); Henry Sinnreich; dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 > Hi Paul, >=20 > it is good that we agree that some problems need both ends to=20 > collaborate. Now, let's discuss whether or not that is the case with > *this* problem. >=20 > > I still haven't seen anything showing why this approach=20 > ends up being=20 > > "better" than the "centralized" approach. (Note that I don't agree=20 > > with the term "centralized", because it isn't really more=20 > centralized=20 > > than the "distributed" approach is. This would become clearer if we=20 > > looked at all the communications necessary to establish a call with=20 > > disaggregated media, and the various topologies of devices=20 > that might=20 > > play in such > > scenarios.) >=20 > well, 3pcc is centralized because you have a (central)=20 > controller that is in control of all SIP signalling. If that=20 > controller leaves the session, the whole session disappears.=20 > An approach where several devices have their own SIP dialog=20 > with the remote devices is not centralized because you can=20 > remove any of them and the other sessions will remain unaffected. >=20 > > Perhaps we should back off from the signaling mechanisms for the=20 > > moment and consider the use cases of interest in more=20 > detail, and the=20 > > various sorts of communications between them that are necessary to=20 > > establish a call that involves them. >=20 > The arguments have been discussed several times. The thing is=20 > that 3pcc is a complex mechanism that is not supported by=20 > most UAs. You can argue about its complexity, but the fact=20 > that most UAs do not support 3pcc is a fact. >=20 > There are folks that are willing to implement support for a=20 > correlation mechanism for dialogs but would not implement=20 > 3pcc because (they think) it is too complicated. >=20 > A second argument is that any device should be able to leave=20 > the session at any point. If you want the 3pcc controller to=20 > leave the session while the session remains established, you=20 > will need to use a complex combination of REFER and Replaces=20 > that very few (if any) UAs support. >=20 > Therefore, the requirement here is that the mechanism should=20 > not be so complicated that implementers do not actually want=20 > to implement it :o) ... unfortunately, as we all know too=20 > well, we have a history of doing just that. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 From AUDET@nortel.com Tue Jul 21 10:35:19 2009 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 9949C3A6A81 for ; Tue, 21 Jul 2009 10:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 t0gbRXfYaLAA for ; Tue, 21 Jul 2009 10:35:18 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8754628C371 for ; Tue, 21 Jul 2009 10:34:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6LHYLa07105; Tue, 21 Jul 2009 17:34:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2009 12:34:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 thread-index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukwABqf5HA= References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com> <4A643B95.3060800@ericsson.com> <9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: , Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 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, 21 Jul 2009 17:35:19 -0000 and explain why 3XX, 2XX and 1XX don't make sense.=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Monday, July 20, 2009 22:03 > To: Gonzalo.Camarillo@ericsson.com; Audet, Francois (SC100:3055) > Cc: Worley, Dale (BL60:9D30); dispatch@ietf.org > Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi Gonzalo, > Thank you for your comments. > You are correct. The used cases within the document shows=20 > where ISUP causes will be included. > I think in such cases we should clearly state that SIP Reason=20 > should be excluded within SIP responses, to avoid contradictions.=20 >=20 > Then I will include that only within 4xx/5xx/6xx Responses=20 > the Reason header with an Q.850 Cause makes sense. >=20 > There are requirements and three used cases described within=20 > the draft so I hope that fits.=20 >=20 > Best Regards >=20 > Roland > -----Urspr=FCngliche Nachricht----- > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Gesendet: Montag, 20. Juli 2009 11:41 > An: Francois Audet > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi, >=20 > as Francois suggests, a document specifying the use of Reason=20 > header fields in responses needs to specify those things (see=20 > Francois' list below). Additionally, you should think of=20 > whether or not Reason header fields in responses can carry=20 > SIP status codes and what happens if they are different to=20 > the status code of the response. >=20 > In short, the document cannot simply say that now it is OK to=20 > use Reason in responses. It needs to address the different=20 > situations a typical implementation may face. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > Francois Audet wrote: > > Again, the spec is very clear that it IS allowed. > >=20 > > I believe the wishy-washy text about "status code=20 > explicitly allowing=20 > > it" was meant to exclude responses that were not appropriate, and=20 > > restricing it to effectively error responses. > >=20 > > At the time this was written, I believe we were not clear on which=20 > > codes were supposed to be appropriate or not. > >=20 > > Seems to me: > > - Any Error response code should be allowed. > > - I don't think 2XX makes sense. > > - 3XX is controversial (as per the email quoted by Roland):=20 > seems to me it > > would be quite useful > > - Provisional is interesting... Sounds like 199 error=20 > response to me... > >=20 > >> -----Original Message----- > >> From: Worley, Dale (BL60:9D30) > >> Sent: Thursday, July 16, 2009 10:09 > >> To: Audet, Francois (SC100:3055) > >> Cc: R.Jesske@telekom.de; dispatch@ietf.org > >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >> > >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois=20 > (SC100:3055) wrote: > >>> Hi Roland, > >>> > >>> You use case is very common. =20 > >>> > >>> I believe you are incorrect in saying that "reasons are > >> currently not > >>> allowed in responses. Neither conditionally nor allowed". > >>> > >>> RFC 3326 says in 1.0: > >>> "[...] it can appear in any request > >>> within a dialog, in any CANCEL request and in any=20 > response whose > >>> status code explicitly allows the presence of this=20 > header field." > >>> > >>> To be honest, I believe Q.850 codes are much more common in > >> Responses > >>> than in requests. > >> Googling > >> > >> "sip/2.0" reason "q.850" > >> > >> turns up numerous examples of SIP responses using the=20 > Reason header=20 > >> in the forbidden manner. > >> > >> I'd say that your draft formally allows what people are=20 > already doing. > >> > >> Dale > >> > >> > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 >=20 From ankriste@cisco.com Tue Jul 21 12:22:23 2009 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 2FE1228C369 for ; Tue, 21 Jul 2009 12:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 Z3MVtC-nCcPp for ; Tue, 21 Jul 2009 12:22:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0294528C367 for ; Tue, 21 Jul 2009 12:22:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL+xZUqrR7PE/2dsb2JhbAC6RYgjkBAFhAw X-IronPort-AV: E=Sophos;i="4.43,242,1246838400"; d="scan'208";a="188244178" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2009 19:22:22 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6LJMMCe023841; Tue, 21 Jul 2009 12:22:22 -0700 Received: from [10.21.93.227] (sjc-vpn5-1507.cisco.com [10.21.93.227]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6LJMLOU008525; Tue, 21 Jul 2009 19:22:22 GMT Message-ID: <4A661564.9000008@cisco.com> Date: Tue, 21 Jul 2009 12:22:12 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> <4A65D27F.1060604@ericsson.com> In-Reply-To: <4A65D27F.1060604@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6237; t=1248204142; x=1249068142; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ankriste@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20; bh=jkDs72T87nDMDh8LDbyRJwQO7wdssWXgD46u3wXpP40=; b=Y6pBIu+nf1M2PMbdHEYXYuAyNVhBnMm8RR46ISRl4mr372HLUpZtbN/ZW5 EEKZX27BPcly+9jtFOOC2E+lJZYKOpjMNQ2T/2EoGXiltjFE0DLu2Tt97hT7 M3CCSlvHFu; Authentication-Results: sj-dkim-4; header.From=ankriste@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Tue, 21 Jul 2009 13:10:35 -0700 Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 21 Jul 2009 19:52:33 -0000 I would agree with Paul and John. There's a well established way of handling multiple media streams in SIP - part of SIP since the beginning. Don't tamper with that. If someone wants to disaggregate the streams they should be the ones to pay for it - by dealing with the added complexity and the changes to the existing model. Plus I'd be very skeptical about claims that the alternative is simple. For example, how do you transfer an audio+video call that is actually two SIP dialogs? Now all of a sudden there are additional failure modes because the dialogs have to be transferred separately and can succeed or fail independently. Existing UAs may already support simultaneous dialogs. If they're independent calls then that's not at all the same thing. Thanks, Anders Gonzalo Camarillo wrote: > Hi John, > > many UAs already support multiple SIP dialogs in parallel. Adding a > header that instruct them to treat the media sessions related to those > dialogs as a single one is much easier than anything you have described > in your email. > > The point is that people are going to implement something like this > because it is fairly simple and it is needed. We can either design a > mechanism that meets their simplicity requirement or propose complex > mechanisms that, as usual, will not get implemented. > > Cheers, > > Gonzalo > > Elwell, John wrote: >> Gonzalo, >> >> I have already expressed opinions similar to Paul on several occasions. >> Experience tells us we cannot rely on the remote UA supporting a >> particular feature. Taking REFER as an example, we tend to end up with a >> B2BUA terminating a REFER request, because: >> - the remote UA doesn't support REFER; >> - some UAs don't support REFER, so if the B2BUA sometimes needs to >> terminate REFER to accommodate those UAs, it might as well always >> terminate REFER; >> - some UAs don't accept REFER as a matter of policy. >> >> So B2BUAs tend to act as an anchor point and terminate REFER requests, >> behaving in a 3PCC-like manner. >> >> If the distributed form of disaggregated media goes ahead, I think that >> is what will happen in practice, i.e., a B2BUA will need to act as the >> anchor point. If UAs wanting to use disaggregated media are behind a >> B2BUA that concentrates the multiple dialogs into a single ongoing >> dialog towards the remote UA, that will work. It does indeed have the >> benefit that one local UA can drop out, leaving the other local UA(s) >> still in communication with the remote UA. Relying on the remote UA >> supporting distributed disaggregated media I fear will prevent the >> capability being used in many cases where it might be required. >> >> As part of specifying distributed disaggregated media, we will need to >> pay attention to all the interactions that can occur when both sides >> attempt to use disaggregated media, particular when the two sides >> simultaneously try to add or remove UAs. This sounds like a difficult >> problem, but I may be wrong. Having an anchor point (thereby making it >> centralised, in a way) would probably ease these problems. >> >> John >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Gonzalo Camarillo >>> Sent: 21 July 2009 09:05 >>> To: Paul Kyzivat >>> Cc: dispatch@ietf.org; Henry Sinnreich >>> Subject: Re: [dispatch] Disaggregated Media in SIP >>> >>> Hi Paul, >>> >>> it is good that we agree that some problems need both ends to >>> collaborate. Now, let's discuss whether or not that is the case with >>> *this* problem. >>> >>>> I still haven't seen anything showing why this approach >>> ends up being >>>> "better" than the "centralized" approach. (Note that I >>> don't agree with >>>> the term "centralized", because it isn't really more >>> centralized than >>>> the "distributed" approach is. This would become clearer if >>> we looked at >>>> all the communications necessary to establish a call with >>> disaggregated >>>> media, and the various topologies of devices that might >>> play in such >>>> scenarios.) >>> well, 3pcc is centralized because you have a (central) controller >>> that is in control of all SIP signalling. If that controller leaves >>> the session, the whole session disappears. An approach where several >>> devices have their own SIP dialog with the remote devices is not >>> centralized because you can remove any of them and the other sessions >>> will remain unaffected. >>> >>>> Perhaps we should back off from the signaling mechanisms >>> for the moment >>>> and consider the use cases of interest in more detail, and >>> the various >>>> sorts of communications between them that are necessary to >>> establish a >>>> call that involves them. >>> The arguments have been discussed several times. The thing is that >>> 3pcc is a complex mechanism that is not supported by most UAs. You >>> can argue about its complexity, but the fact that most UAs do not >>> support 3pcc is a fact. >>> >>> There are folks that are willing to implement support for a >>> correlation mechanism for dialogs but would not implement 3pcc >>> because (they think) it is too complicated. >>> >>> A second argument is that any device should be able to leave the >>> session at any point. If you want the 3pcc controller to leave the >>> session while the session remains established, you will need to use a >>> complex combination of REFER and Replaces that very few (if any) UAs >>> support. >>> >>> Therefore, the requirement here is that the mechanism should not be >>> so complicated that implementers do not actually want to implement it >>> :o) ... unfortunately, as we all know too well, we have a history of >>> doing just that. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> 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 volkerh@bell-labs.com Tue Jul 21 14:10:48 2009 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 A13E53A6EA1; Tue, 21 Jul 2009 14:10:48 -0700 (PDT) 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 ZqWFkeYiffm6; Tue, 21 Jul 2009 14:10:47 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B12693A68B4; Tue, 21 Jul 2009 14:10:44 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n6LLAA02004470; Tue, 21 Jul 2009 16:10:10 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n6LLAADh020725; Tue, 21 Jul 2009 16:10:10 -0500 (CDT) Received: from [135.244.35.65] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 21 Jul 2009 16:10:09 -0500 Message-ID: <4A662EA7.6060003@bell-labs.com> Date: Tue, 21 Jul 2009 17:09:59 -0400 From: Volker Hilt User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: DISPATCH , SIP-OVERLOAD Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [dispatch] Charter Proposal for SIP Overload 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, 21 Jul 2009 21:10:48 -0000 All, below is a charter proposal for a WG on SIP Overload Control. All comments, thoughts, feedback is very welcome! Thanks, Volker SIP Overload Control WG Charter ------------------------------- As with any network element, a Session Initiation Protocol (SIP) [RFC3261] server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to process all incoming SIP messages. These resources can include CPU, memory, network bandwidth, input/output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse. To objective of a SIP overload control mechanism is to enable SIP servers to perform close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, it may cause traffic to oscillate and to shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in [RFC5390]. The objective of the proposed working group is to develop mechanisms for SIP overload control. Two complementary approaches exist for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. Specifically, the proposed working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. From gunnar.hellstrom@omnitor.se Tue Jul 21 14:47:46 2009 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 401E928C3B0 for ; Tue, 21 Jul 2009 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, 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 65SRo0NcrUZl for ; Tue, 21 Jul 2009 14:47:45 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id D2A7728C3AE for ; Tue, 21 Jul 2009 14:47:44 -0700 (PDT) Received: (qmail 58372 invoked from network); 21 Jul 2009 21:47:52 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 21 Jul 2009 21:47:52 -0000 Received: (qmail 80600 invoked from network); 21 Jul 2009 21:47:43 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 21 Jul 2009 21:47:43 -0000 From: "Gunnar Hellstrom" To: Date: Tue, 21 Jul 2009 23:47:42 +0200 Message-ID: <00c901ca0a4c$e0253ed0$e800a8c0@GunnarH> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CA0A5D.A3AE0ED0" X-Mailer: Microsoft Office Outlook 11 thread-index: AcoKTN48SM8l5uzJTIKeLJBlYzXMzQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: [dispatch] Registration of the "real-time-text" Media Feature Tag 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, 21 Jul 2009 21:47:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01CA0A5D.A3AE0ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new draft draft-hellstrom-text-turntaking-02.txt is available. Since I am not sure what group is responsible for approving this kind of registrations, I turn to the Dispatch group.=20 In an earlier version of this draft, there were more values defined for = in detail specifying what limitations in simultaneity a network component = has. This was regarded too complex, so in this version, the indication is = limited to two variants: full and restricted. For further info, see the = document. =20 Details: =20 Title : Registration of the Real-time-text Media Feature Tag Author(s) : G. Hellstrom, A. Wijk Filename : draft-hellstrom-text-turntaking-02.txt Pages : 6 Date : 2009-07-12 This memo defines a new Media Feature Tag "real-time-text" for use in = SIP registration and session establishment. This is used to indicate if a = device capable of text communication has full real-time text capabilities or limitations in its capabilities requiring the users to apply some turn-taking habits. A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.tx= t =20 ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se =20 =20 ------=_NextPart_000_00CA_01CA0A5D.A3AE0ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A new draft=20 draft-hellstrom-text-turntaking-02.txt  is = available.
Since I am not sure = what group=20 is responsible for approving this kind of registrations, I turn to the = Dispatch=20 group.
In an earlier = version of this=20 draft, there were more values defined for in detail specifying what = limitations=20 in simultaneity a network component has. This was regarded too complex, = so in=20 this version, the indication is limited to two variants: full and=20 restricted.  For further info, see the = document.
 
Details:
 
Title : = Registration=20 of the Real-time-text Media Feature Tag

Author(s) : G. Hellstrom, A. Wijk

Filename : = draft-hellstrom-text-turntaking-02.txt

Pages : 6

Date : 2009-07-12

This memo defines a new Media Feature Tag = "real-time-text" for=20 use in SIP registration and session establishment. This is used to = indicate if a=20 device capable of text communication has full real-time text = capabilities or=20 limitations in its capabilities requiring the users to apply some = turn-taking=20 habits.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntak= ing-02.txt
 
----------------------------------------------------------------= ---
Gunnar = Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
Tel: = +46708204288
www.omnitor.se
 
------=_NextPart_000_00CA_01CA0A5D.A3AE0ED0-- From AUDET@nortel.com Tue Jul 21 21:40:49 2009 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 7030D3A6BAA for ; Tue, 21 Jul 2009 21:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 qFeDfIwojxpV for ; Tue, 21 Jul 2009 21:40:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2152A3A6BBE for ; Tue, 21 Jul 2009 21:40:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6M4eHi23540; Wed, 22 Jul 2009 04:40:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2009 23:40:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A661564.9000008@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: AcoKP1JogruDFZwjSOedWlt7Ma6TGwARuVxA References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> From: "Francois Audet" To: "Anders Kristensen" , "Gonzalo Camarillo" Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 04:40:49 -0000 Well, that particular example is already supported in SIP with the REFER method. This is not an issue. It's other things, like, "please answer dialog X" or "please kill dialog Y" that are an issue.=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Anders Kristensen > Sent: Tuesday, July 21, 2009 12:22 > To: Gonzalo Camarillo > Cc: Henry Sinnreich; dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 > I would agree with Paul and John. There's a well established=20 > way of handling multiple media streams in SIP - part of SIP=20 > since the beginning. Don't tamper with that. If someone wants=20 > to disaggregate the streams they should be the ones to pay=20 > for it - by dealing with the added complexity and the changes=20 > to the existing model. >=20 > Plus I'd be very skeptical about claims that the alternative=20 > is simple.=20 > For example, how do you transfer an audio+video call that is=20 > actually two SIP dialogs? Now all of a sudden there are=20 > additional failure modes because the dialogs have to be=20 > transferred separately and can succeed or fail independently. >=20 > Existing UAs may already support simultaneous dialogs. If=20 > they're independent calls then that's not at all the same thing. >=20 > Thanks, > Anders >=20 > Gonzalo Camarillo wrote: > > Hi John, > >=20 > > many UAs already support multiple SIP dialogs in parallel. Adding a=20 > > header that instruct them to treat the media sessions=20 > related to those=20 > > dialogs as a single one is much easier than anything you have=20 > > described in your email. > >=20 > > The point is that people are going to implement something like this=20 > > because it is fairly simple and it is needed. We can either=20 > design a=20 > > mechanism that meets their simplicity requirement or=20 > propose complex=20 > > mechanisms that, as usual, will not get implemented. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > Elwell, John wrote: > >> Gonzalo, > >> > >> I have already expressed opinions similar to Paul on=20 > several occasions. > >> Experience tells us we cannot rely on the remote UA supporting a=20 > >> particular feature. Taking REFER as an example, we tend to end up=20 > >> with a B2BUA terminating a REFER request, because: > >> - the remote UA doesn't support REFER; > >> - some UAs don't support REFER, so if the B2BUA sometimes needs to=20 > >> terminate REFER to accommodate those UAs, it might as well always=20 > >> terminate REFER; > >> - some UAs don't accept REFER as a matter of policy. > >> > >> So B2BUAs tend to act as an anchor point and terminate REFER=20 > >> requests, behaving in a 3PCC-like manner. > >> > >> If the distributed form of disaggregated media goes ahead, I think=20 > >> that is what will happen in practice, i.e., a B2BUA will=20 > need to act=20 > >> as the anchor point. If UAs wanting to use disaggregated media are=20 > >> behind a B2BUA that concentrates the multiple dialogs into=20 > a single=20 > >> ongoing dialog towards the remote UA, that will work. It=20 > does indeed=20 > >> have the benefit that one local UA can drop out, leaving the other=20 > >> local UA(s) still in communication with the remote UA.=20 > Relying on the=20 > >> remote UA supporting distributed disaggregated media I fear will=20 > >> prevent the capability being used in many cases where it=20 > might be required. > >> > >> As part of specifying distributed disaggregated media, we=20 > will need=20 > >> to pay attention to all the interactions that can occur when both=20 > >> sides attempt to use disaggregated media, particular when the two=20 > >> sides simultaneously try to add or remove UAs. This sounds like a=20 > >> difficult problem, but I may be wrong. Having an anchor point=20 > >> (thereby making it centralised, in a way) would probably=20 > ease these problems. > >> > >> John > >> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org]=20 > >>> On Behalf Of Gonzalo Camarillo > >>> Sent: 21 July 2009 09:05 > >>> To: Paul Kyzivat > >>> Cc: dispatch@ietf.org; Henry Sinnreich > >>> Subject: Re: [dispatch] Disaggregated Media in SIP > >>> > >>> Hi Paul, > >>> > >>> it is good that we agree that some problems need both ends to=20 > >>> collaborate. Now, let's discuss whether or not that is=20 > the case with > >>> *this* problem. > >>> > >>>> I still haven't seen anything showing why this approach > >>> ends up being > >>>> "better" than the "centralized" approach. (Note that I > >>> don't agree with > >>>> the term "centralized", because it isn't really more > >>> centralized than > >>>> the "distributed" approach is. This would become clearer if > >>> we looked at > >>>> all the communications necessary to establish a call with > >>> disaggregated > >>>> media, and the various topologies of devices that might > >>> play in such > >>>> scenarios.) > >>> well, 3pcc is centralized because you have a (central) controller=20 > >>> that is in control of all SIP signalling. If that=20 > controller leaves=20 > >>> the session, the whole session disappears. An approach=20 > where several=20 > >>> devices have their own SIP dialog with the remote devices is not=20 > >>> centralized because you can remove any of them and the other=20 > >>> sessions will remain unaffected. > >>> > >>>> Perhaps we should back off from the signaling mechanisms > >>> for the moment > >>>> and consider the use cases of interest in more detail, and > >>> the various > >>>> sorts of communications between them that are necessary to > >>> establish a > >>>> call that involves them. > >>> The arguments have been discussed several times. The=20 > thing is that=20 > >>> 3pcc is a complex mechanism that is not supported by most=20 > UAs. You=20 > >>> can argue about its complexity, but the fact that most UAs do not=20 > >>> support 3pcc is a fact. > >>> > >>> There are folks that are willing to implement support for a=20 > >>> correlation mechanism for dialogs but would not implement 3pcc=20 > >>> because (they think) it is too complicated. > >>> > >>> A second argument is that any device should be able to leave the=20 > >>> session at any point. If you want the 3pcc controller to=20 > leave the=20 > >>> session while the session remains established, you will=20 > need to use=20 > >>> a complex combination of REFER and Replaces that very few=20 > (if any)=20 > >>> UAs support. > >>> > >>> Therefore, the requirement here is that the mechanism=20 > should not be=20 > >>> so complicated that implementers do not actually want to=20 > implement=20 > >>> it > >>> :o) ... unfortunately, as we all know too well, we have a=20 > history of=20 > >>> doing just that. > >>> > >>> Cheers, > >>> > >>> Gonzalo > >>> > >>> _______________________________________________ > >>> 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 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From ankriste@cisco.com Tue Jul 21 22:23:23 2009 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 BDFBB3A68E2 for ; Tue, 21 Jul 2009 22:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 vVGqTzoyGpYc for ; Tue, 21 Jul 2009 22:23:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 610513A6853 for ; Tue, 21 Jul 2009 22:23:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACQ/ZkqrR7O6/2dsb2JhbAC4aogjkFcFhA4 X-IronPort-AV: E=Sophos;i="4.43,244,1246838400"; d="scan'208";a="217346641" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Jul 2009 05:23:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6M5N7Mp007429; Tue, 21 Jul 2009 22:23:07 -0700 Received: from [128.107.151.73] (dhcp-128-107-151-73.cisco.com [128.107.151.73]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6M5N6gn026959; Wed, 22 Jul 2009 05:23:07 GMT Message-ID: <4A66A239.4090806@cisco.com> Date: Tue, 21 Jul 2009 22:23:05 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7662; t=1248240187; x=1249104187; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ankriste@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20; bh=Qq28KafPQnfPQDx9/6zeY0ab7mE+KXtacwnOgfvXeR0=; b=KqBQIquHA5nW0bpiz+doQsc4dDDFsLki0XvtKLINJWgKHKl7tB215vB+4h q31dXR56W8OpWG+oAH6azIkVVHvj/gAmldTY4XATNYfXFS3rrbzc60n7JkJz 5Q/rOPk+EQ; Authentication-Results: sj-dkim-2; header.From=ankriste@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 05:23:24 -0000 Francois Audet wrote: > Well, that particular example is already supported in SIP with > the REFER method. This is not an issue. Are you saying that in this example a single REFER will work because the triggered INVITE will contain both audio and media streams? Maybe so. However, other aspects of transfer flows will be impacted. The Replaces header field can refer to just one dialog, for example. Anders > > It's other things, like, "please answer dialog X" or "please > kill dialog Y" that are an issue. > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Anders Kristensen >> Sent: Tuesday, July 21, 2009 12:22 >> To: Gonzalo Camarillo >> Cc: Henry Sinnreich; dispatch@ietf.org >> Subject: Re: [dispatch] Disaggregated Media in SIP >> >> I would agree with Paul and John. There's a well established >> way of handling multiple media streams in SIP - part of SIP >> since the beginning. Don't tamper with that. If someone wants >> to disaggregate the streams they should be the ones to pay >> for it - by dealing with the added complexity and the changes >> to the existing model. >> >> Plus I'd be very skeptical about claims that the alternative >> is simple. >> For example, how do you transfer an audio+video call that is >> actually two SIP dialogs? Now all of a sudden there are >> additional failure modes because the dialogs have to be >> transferred separately and can succeed or fail independently. >> >> Existing UAs may already support simultaneous dialogs. If >> they're independent calls then that's not at all the same thing. >> >> Thanks, >> Anders >> >> Gonzalo Camarillo wrote: >>> Hi John, >>> >>> many UAs already support multiple SIP dialogs in parallel. Adding a >>> header that instruct them to treat the media sessions >> related to those >>> dialogs as a single one is much easier than anything you have >>> described in your email. >>> >>> The point is that people are going to implement something like this >>> because it is fairly simple and it is needed. We can either >> design a >>> mechanism that meets their simplicity requirement or >> propose complex >>> mechanisms that, as usual, will not get implemented. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> Elwell, John wrote: >>>> Gonzalo, >>>> >>>> I have already expressed opinions similar to Paul on >> several occasions. >>>> Experience tells us we cannot rely on the remote UA supporting a >>>> particular feature. Taking REFER as an example, we tend to end up >>>> with a B2BUA terminating a REFER request, because: >>>> - the remote UA doesn't support REFER; >>>> - some UAs don't support REFER, so if the B2BUA sometimes needs to >>>> terminate REFER to accommodate those UAs, it might as well always >>>> terminate REFER; >>>> - some UAs don't accept REFER as a matter of policy. >>>> >>>> So B2BUAs tend to act as an anchor point and terminate REFER >>>> requests, behaving in a 3PCC-like manner. >>>> >>>> If the distributed form of disaggregated media goes ahead, I think >>>> that is what will happen in practice, i.e., a B2BUA will >> need to act >>>> as the anchor point. If UAs wanting to use disaggregated media are >>>> behind a B2BUA that concentrates the multiple dialogs into >> a single >>>> ongoing dialog towards the remote UA, that will work. It >> does indeed >>>> have the benefit that one local UA can drop out, leaving the other >>>> local UA(s) still in communication with the remote UA. >> Relying on the >>>> remote UA supporting distributed disaggregated media I fear will >>>> prevent the capability being used in many cases where it >> might be required. >>>> As part of specifying distributed disaggregated media, we >> will need >>>> to pay attention to all the interactions that can occur when both >>>> sides attempt to use disaggregated media, particular when the two >>>> sides simultaneously try to add or remove UAs. This sounds like a >>>> difficult problem, but I may be wrong. Having an anchor point >>>> (thereby making it centralised, in a way) would probably >> ease these problems. >>>> John >>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] >>>>> On Behalf Of Gonzalo Camarillo >>>>> Sent: 21 July 2009 09:05 >>>>> To: Paul Kyzivat >>>>> Cc: dispatch@ietf.org; Henry Sinnreich >>>>> Subject: Re: [dispatch] Disaggregated Media in SIP >>>>> >>>>> Hi Paul, >>>>> >>>>> it is good that we agree that some problems need both ends to >>>>> collaborate. Now, let's discuss whether or not that is >> the case with >>>>> *this* problem. >>>>> >>>>>> I still haven't seen anything showing why this approach >>>>> ends up being >>>>>> "better" than the "centralized" approach. (Note that I >>>>> don't agree with >>>>>> the term "centralized", because it isn't really more >>>>> centralized than >>>>>> the "distributed" approach is. This would become clearer if >>>>> we looked at >>>>>> all the communications necessary to establish a call with >>>>> disaggregated >>>>>> media, and the various topologies of devices that might >>>>> play in such >>>>>> scenarios.) >>>>> well, 3pcc is centralized because you have a (central) controller >>>>> that is in control of all SIP signalling. If that >> controller leaves >>>>> the session, the whole session disappears. An approach >> where several >>>>> devices have their own SIP dialog with the remote devices is not >>>>> centralized because you can remove any of them and the other >>>>> sessions will remain unaffected. >>>>> >>>>>> Perhaps we should back off from the signaling mechanisms >>>>> for the moment >>>>>> and consider the use cases of interest in more detail, and >>>>> the various >>>>>> sorts of communications between them that are necessary to >>>>> establish a >>>>>> call that involves them. >>>>> The arguments have been discussed several times. The >> thing is that >>>>> 3pcc is a complex mechanism that is not supported by most >> UAs. You >>>>> can argue about its complexity, but the fact that most UAs do not >>>>> support 3pcc is a fact. >>>>> >>>>> There are folks that are willing to implement support for a >>>>> correlation mechanism for dialogs but would not implement 3pcc >>>>> because (they think) it is too complicated. >>>>> >>>>> A second argument is that any device should be able to leave the >>>>> session at any point. If you want the 3pcc controller to >> leave the >>>>> session while the session remains established, you will >> need to use >>>>> a complex combination of REFER and Replaces that very few >> (if any) >>>>> UAs support. >>>>> >>>>> Therefore, the requirement here is that the mechanism >> should not be >>>>> so complicated that implementers do not actually want to >> implement >>>>> it >>>>> :o) ... unfortunately, as we all know too well, we have a >> history of >>>>> doing just that. >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>>>> _______________________________________________ >>>>> 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 gunnar.hellstrom@omnitor.se Tue Jul 21 22:35:58 2009 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 388463A69AE for ; Tue, 21 Jul 2009 22:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_40=-0.185, HELO_EQ_SE=0.35, 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 YROB5C2Qprbn for ; Tue, 21 Jul 2009 22:35:57 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id A919C3A690B for ; Tue, 21 Jul 2009 22:35:56 -0700 (PDT) Received: (qmail 93814 invoked from network); 22 Jul 2009 05:13:13 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2009 05:13:13 -0000 Received: (qmail 43217 invoked from network); 22 Jul 2009 05:13:12 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 22 Jul 2009 05:13:12 -0000 From: "Gunnar Hellstrom" To: Date: Wed, 22 Jul 2009 07:13:11 +0200 Message-ID: <010c01ca0a8b$1c1831c0$e800a8c0@GunnarH> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010D_01CA0A9B.DFA101C0" X-Mailer: Microsoft Office Outlook 11 thread-index: AcoKixkDahG/4rZYSmCMzHOKH3A/Yg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: [dispatch] Presentation aspects of real-time text sessions 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, 22 Jul 2009 05:35:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_010D_01CA0A9B.DFA101C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new draft on presentation of real-time text is available at = http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt It specifies details on how sessions with real-time text can be = presented, and how presentation protocol items can be used to control the = presentation. It also introduces some important rules to follow in order to maintain = the same contents of the conversation by the participants while they very = well may have selected different presentation layouts. New in this version are details on how far back erasure actions are = allowed, and a new indicator differing soft-return and hard-return. There is also = an effort to align it with RFC5198 "Unicode Format for Network Interchange" I have not found a suitable home for discussion of this draft in IETF, = and is therefore turning to Dispatch for advice. Info on the draft: -------------------------------------------------------------------------= --- --------------=20 Title : Presentation of Text Conversation in realtime and en-bloc form Author(s) : G. Hellstrom, et al. Filename : draft-hellstrom-textpreview-06.txt Pages : 17 Date : 2009-07-11 This specification defines methods for presentation of a text = conversation with focus on the real-time features. The aim is to give the = participants in a conversation a good opportunity to perceive the real-time flow of the conversation and also provide a display of the history of the = conversation that makes it easy to read. Both two-party and multi-party situations = are defined. A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se =20 =20 ------=_NextPart_000_010D_01CA0A9B.DFA101C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A new draft on = presentation=20 of real-time text is available at

http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-= 06.txt

It specifies = details on=20 how sessions with real-time text can be presented, and how presentation = protocol=20 items can be used to control the presentation. It also introduces some = important=20 rules to follow in order to maintain the same contents of the=20 conversation by the participants while they very well may have = selected=20 different presentation layouts.

New in this = version are=20 details on how far back erasure actions are allowed, and a new indicator = differing soft-return and hard-return. There is also an effort to align = it with=20 RFC5198 "Unicode Format for Network Interchange"

I have not found = a suitable=20 home for discussion of this draft in IETF, and is therefore turning = to=20 Dispatch for advice.

Info on the=20 draft:

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

Title : Presentation of Text Conversation in = realtime and=20 en-bloc form

Author(s) : G. Hellstrom, et al.

Filename : = draft-hellstrom-textpreview-06.txt

Pages : 17

Date : 2009-07-11

This specification defines methods for presentation of = a text=20 conversation with focus on the real-time features. The aim is to give = the=20 participants in a conversation a good opportunity to perceive the = real-time flow=20 of the conversation and also provide a display of the history of the=20 conversation that makes it easy to read. Both two-party and multi-party=20 situations are defined.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-= 06.txt

----------------------------------------------------------------= ---
Gunnar = Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
Tel: = +46708204288
www.omnitor.se
 
------=_NextPart_000_010D_01CA0A9B.DFA101C0-- From gonzalo.camarillo@ericsson.com Tue Jul 21 22:59:30 2009 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 5AFD73A6B26 for ; Tue, 21 Jul 2009 22:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_55=0.6, 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 x1OfSUd5C41A for ; Tue, 21 Jul 2009 22:59:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BD06F3A6AAD for ; Tue, 21 Jul 2009 22:59:16 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-aa-4a66aa874b81 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7C.8F.00514.78AA66A4; Wed, 22 Jul 2009 07:58:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 07:56:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 07:56:54 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 577E72461; Wed, 22 Jul 2009 08:56:54 +0300 (EEST) Message-ID: <4A66AA26.6010303@ericsson.com> Date: Wed, 22 Jul 2009 08:56:54 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anders Kristensen References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> <4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> In-Reply-To: <4A661564.9000008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 05:56:54.0646 (UTC) FILETIME=[37386960:01CA0A91] X-Brightmail-Tracker: AAAAAA== Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 05:59:30 -0000 Hi, > I would agree with Paul and John. There's a well established way of > handling multiple media streams in SIP - part of SIP since the > beginning. Don't tamper with that. yes, it exists in an imaginary world that some IETFers live in. If you check in the real world, no UAs support that type of functionality. If we IETF specs to become irrelevant, continuing living in such imaginary world and ignoring reality is the best way forward. > Plus I'd be very skeptical about claims that the alternative is simple. > For example, how do you transfer an audio+video call that is actually > two SIP dialogs? Now all of a sudden there are additional failure modes > because the dialogs have to be transferred separately and can succeed or > fail independently. We have mechanisms to deal with transfers of a single dialog. That is what you would do; exactly the same as in the 3pcc model: you transfer each dialog to its new location. > Existing UAs may already support simultaneous dialogs. If they're > independent calls then that's not at all the same thing. That is exactly my point. Existing UAs *already* support multiple dialogs. Presenting the video stream established by one dialog and the IM stream established by the other one as if they were a single session is *very* simple and, at the protocol level, it can also be implemented with a simple mechanism. All the alternatives given (e.g., 3pcc) are not currently supported and are way more complex. Cheers, Gonzalo From AUDET@nortel.com Tue Jul 21 23:13:31 2009 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 D3F173A6AAD for ; Tue, 21 Jul 2009 23:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 SNOJ03B5prxU for ; Tue, 21 Jul 2009 23:13:30 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4C4E83A685B for ; Tue, 21 Jul 2009 23:13:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6M6C4i10721; Wed, 22 Jul 2009 06:12:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jul 2009 01:11:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A66A239.4090806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: AcoKjIFC3bp2sfcMRe2EunS74rGxkgABYiKQ References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> From: "Francois Audet" To: "Anders Kristensen" Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 06:13:31 -0000 That is correct. I don't see separating audio and video for a single = call to be desireable (for example). In my mind, the term "disaggregated media" is a misnomer. It's really "loosely coupled control" that is useful. > -----Original Message----- > From: Anders Kristensen [mailto:ankriste@cisco.com]=20 > Sent: Tuesday, July 21, 2009 22:23 > To: Audet, Francois (SC100:3055) > Cc: Gonzalo Camarillo; Henry Sinnreich; dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 >=20 >=20 > Francois Audet wrote: > > Well, that particular example is already supported in SIP with the=20 > > REFER method. This is not an issue. >=20 > Are you saying that in this example a single REFER will work=20 > because the triggered INVITE will contain both audio and=20 > media streams? Maybe so.=20 > However, other aspects of transfer flows will be impacted.=20 > The Replaces header field can refer to just one dialog, for example. >=20 > Anders >=20 > >=20 > > It's other things, like, "please answer dialog X" or "please kill=20 > > dialog Y" that are an issue. > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Anders Kristensen > >> Sent: Tuesday, July 21, 2009 12:22 > >> To: Gonzalo Camarillo > >> Cc: Henry Sinnreich; dispatch@ietf.org > >> Subject: Re: [dispatch] Disaggregated Media in SIP > >> > >> I would agree with Paul and John. There's a well=20 > established way of=20 > >> handling multiple media streams in SIP - part of SIP since the=20 > >> beginning. Don't tamper with that. If someone wants to=20 > disaggregate=20 > >> the streams they should be the ones to pay for it - by=20 > dealing with=20 > >> the added complexity and the changes to the existing model. > >> > >> Plus I'd be very skeptical about claims that the alternative is=20 > >> simple. > >> For example, how do you transfer an audio+video call that=20 > is actually=20 > >> two SIP dialogs? Now all of a sudden there are additional failure=20 > >> modes because the dialogs have to be transferred=20 > separately and can=20 > >> succeed or fail independently. > >> > >> Existing UAs may already support simultaneous dialogs. If they're=20 > >> independent calls then that's not at all the same thing. > >> > >> Thanks, > >> Anders > >> > >> Gonzalo Camarillo wrote: > >>> Hi John, > >>> > >>> many UAs already support multiple SIP dialogs in=20 > parallel. Adding a=20 > >>> header that instruct them to treat the media sessions > >> related to those > >>> dialogs as a single one is much easier than anything you have=20 > >>> described in your email. > >>> > >>> The point is that people are going to implement something=20 > like this=20 > >>> because it is fairly simple and it is needed. We can either > >> design a > >>> mechanism that meets their simplicity requirement or > >> propose complex > >>> mechanisms that, as usual, will not get implemented. > >>> > >>> Cheers, > >>> > >>> Gonzalo > >>> > >>> Elwell, John wrote: > >>>> Gonzalo, > >>>> > >>>> I have already expressed opinions similar to Paul on > >> several occasions. > >>>> Experience tells us we cannot rely on the remote UA supporting a=20 > >>>> particular feature. Taking REFER as an example, we tend=20 > to end up=20 > >>>> with a B2BUA terminating a REFER request, because: > >>>> - the remote UA doesn't support REFER; > >>>> - some UAs don't support REFER, so if the B2BUA=20 > sometimes needs to=20 > >>>> terminate REFER to accommodate those UAs, it might as=20 > well always=20 > >>>> terminate REFER; > >>>> - some UAs don't accept REFER as a matter of policy. > >>>> > >>>> So B2BUAs tend to act as an anchor point and terminate REFER=20 > >>>> requests, behaving in a 3PCC-like manner. > >>>> > >>>> If the distributed form of disaggregated media goes=20 > ahead, I think=20 > >>>> that is what will happen in practice, i.e., a B2BUA will > >> need to act > >>>> as the anchor point. If UAs wanting to use disaggregated=20 > media are=20 > >>>> behind a B2BUA that concentrates the multiple dialogs into > >> a single > >>>> ongoing dialog towards the remote UA, that will work. It > >> does indeed > >>>> have the benefit that one local UA can drop out, leaving=20 > the other=20 > >>>> local UA(s) still in communication with the remote UA. > >> Relying on the > >>>> remote UA supporting distributed disaggregated media I fear will=20 > >>>> prevent the capability being used in many cases where it > >> might be required. > >>>> As part of specifying distributed disaggregated media, we > >> will need > >>>> to pay attention to all the interactions that can occur=20 > when both=20 > >>>> sides attempt to use disaggregated media, particular=20 > when the two=20 > >>>> sides simultaneously try to add or remove UAs. This=20 > sounds like a=20 > >>>> difficult problem, but I may be wrong. Having an anchor point=20 > >>>> (thereby making it centralised, in a way) would probably > >> ease these problems. > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] > >>>>> On Behalf Of Gonzalo Camarillo > >>>>> Sent: 21 July 2009 09:05 > >>>>> To: Paul Kyzivat > >>>>> Cc: dispatch@ietf.org; Henry Sinnreich > >>>>> Subject: Re: [dispatch] Disaggregated Media in SIP > >>>>> > >>>>> Hi Paul, > >>>>> > >>>>> it is good that we agree that some problems need both ends to=20 > >>>>> collaborate. Now, let's discuss whether or not that is > >> the case with > >>>>> *this* problem. > >>>>> > >>>>>> I still haven't seen anything showing why this approach > >>>>> ends up being > >>>>>> "better" than the "centralized" approach. (Note that I > >>>>> don't agree with > >>>>>> the term "centralized", because it isn't really more > >>>>> centralized than > >>>>>> the "distributed" approach is. This would become clearer if > >>>>> we looked at > >>>>>> all the communications necessary to establish a call with > >>>>> disaggregated > >>>>>> media, and the various topologies of devices that might > >>>>> play in such > >>>>>> scenarios.) > >>>>> well, 3pcc is centralized because you have a (central)=20 > controller=20 > >>>>> that is in control of all SIP signalling. If that > >> controller leaves > >>>>> the session, the whole session disappears. An approach > >> where several > >>>>> devices have their own SIP dialog with the remote=20 > devices is not=20 > >>>>> centralized because you can remove any of them and the other=20 > >>>>> sessions will remain unaffected. > >>>>> > >>>>>> Perhaps we should back off from the signaling mechanisms > >>>>> for the moment > >>>>>> and consider the use cases of interest in more detail, and > >>>>> the various > >>>>>> sorts of communications between them that are necessary to > >>>>> establish a > >>>>>> call that involves them. > >>>>> The arguments have been discussed several times. The > >> thing is that > >>>>> 3pcc is a complex mechanism that is not supported by most > >> UAs. You > >>>>> can argue about its complexity, but the fact that most=20 > UAs do not=20 > >>>>> support 3pcc is a fact. > >>>>> > >>>>> There are folks that are willing to implement support for a=20 > >>>>> correlation mechanism for dialogs but would not implement 3pcc=20 > >>>>> because (they think) it is too complicated. > >>>>> > >>>>> A second argument is that any device should be able to=20 > leave the=20 > >>>>> session at any point. If you want the 3pcc controller to > >> leave the > >>>>> session while the session remains established, you will > >> need to use > >>>>> a complex combination of REFER and Replaces that very few > >> (if any) > >>>>> UAs support. > >>>>> > >>>>> Therefore, the requirement here is that the mechanism > >> should not be > >>>>> so complicated that implementers do not actually want to > >> implement > >>>>> it > >>>>> :o) ... unfortunately, as we all know too well, we have a > >> history of > >>>>> doing just that. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Gonzalo > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > >=20 >=20 From gonzalo.camarillo@ericsson.com Tue Jul 21 23:39:17 2009 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 2EE5C3A6840 for ; Tue, 21 Jul 2009 23:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.04 X-Spam-Level: X-Spam-Status: No, score=-5.04 tagged_above=-999 required=5 tests=[AWL=1.209, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ghL037fF2Cap for ; Tue, 21 Jul 2009 23:39:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F20D63A68E2 for ; Tue, 21 Jul 2009 23:38:30 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-f9-4a66b008a28e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 24.D0.00514.800B66A4; Wed, 22 Jul 2009 08:22:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 08:21:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 08:21:39 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF6EF2461; Wed, 22 Jul 2009 09:21:39 +0300 (EEST) Message-ID: <4A66AFF3.7040500@ericsson.com> Date: Wed, 22 Jul 2009 09:21:39 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 06:21:40.0094 (UTC) FILETIME=[AC9DC9E0:01CA0A94] X-Brightmail-Tracker: AAAAAA== Cc: Anders Kristensen , Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 06:39:17 -0000 Hi, > That is correct. I don't see separating audio and video for a single call > to be desireable (for example). exactly. Regular UAs would continue establishing multi-stream sessions as usual (i.e., using a single dialog). You would only have multiple dialogs when multiple SIP-enabled devices are involved in the communication. > In my mind, the term "disaggregated media" is a misnomer. It's really > "loosely coupled control" that is useful. yes, that would be a valid term as well. Cheers, Gonzalo From michael@voip.co.uk Wed Jul 22 01:13:19 2009 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 B1F003A6851 for ; Wed, 22 Jul 2009 01:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SUB_OBFU_Q1=0.227] 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 pB0lqrcLuME2 for ; Wed, 22 Jul 2009 01:13:19 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 844DF3A68E9 for ; Wed, 22 Jul 2009 01:13:18 -0700 (PDT) Received: from source ([72.14.220.155]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKSmbJZsOLjOojGrkqWYUh3jXgbyHpnnqi@postini.com; Wed, 22 Jul 2009 01:13:19 PDT Received: by fg-out-1718.google.com with SMTP id e21so1141528fga.10 for ; Wed, 22 Jul 2009 01:10:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.27.7 with SMTP id a7mr531825fga.67.1248250214472; Wed, 22 Jul 2009 01:10:14 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 22 Jul 2009 09:10:14 +0100 Message-ID: From: Michael Procter To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 22 Jul 2009 08:13:19 -0000 Hi John, 2009/6/29 Elwell, John : > http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs-00.txt > > We would appreciate feedback as to whether this is helpful and going in the right direction, as well as detailed comments. I think you have identified some useful fundamental properties of caller/callee id in your requirements. My only query is about Req 6: "meeting similar requirements to those above" seems a little ambiguous. Did you intend for the calling user to receive the same level of assurance concerning the providence of the callee ID, or would you expect a lower level to be sufficient? Best regards, Michael From gunnar.hellstrom@omnitor.se Wed Jul 22 01:24:13 2009 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 2E2DA3A6851 for ; Wed, 22 Jul 2009 01:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_50=0.001, HELO_EQ_SE=0.35, 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 OnzUcbAPO7UP for ; Wed, 22 Jul 2009 01:24:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id ECC173A692D for ; Wed, 22 Jul 2009 01:23:43 -0700 (PDT) Received: (qmail 45698 invoked from network); 22 Jul 2009 07:55:46 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2009 07:55:46 -0000 Received: (qmail 87028 invoked from network); 22 Jul 2009 07:55:43 -0000 Received: from 136.240.13.217.in-addr.dgcsystems.net (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[217.13.240.136]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with SMTP for ; 22 Jul 2009 07:55:43 -0000 From: "Gunnar Hellstrom" To: Date: Wed, 22 Jul 2009 09:55:34 +0200 Message-ID: <012601ca0aa1$d07ce960$e800a8c0@GunnarH> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01CA0AB2.9405B960" X-Mailer: Microsoft Office Outlook 11 thread-index: AcoKkZeEzMXpJSDxRPKXcK5tiuEthg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: [dispatch] Real-time text interworking between PSTN and IP networks 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, 22 Jul 2009 08:24:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0127_01CA0AB2.9405B960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new draft is available at http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-01.txt When a feature is offered in one network, it is important to offer interoperability with other networks.=20 Even if real-time text in IP networks overshadow what was avialable in = PSTN in terms of functionality, it is still possible to arrange = interoperability between real-time text in IP networks with the different forms of text telephony that are available in PSTN networks ( e.g. TTY, EDT, V.21 = based, DTMF based etc ). Issues on many levels appear when such = interoperability shall be arranged. e.g. on routing, media negotiating, indications to = the users, handling the limitations in media simultaneity in PSTN in = contrast with the full simultaneity possible in IP etc.=20 The draft gives guidance on many of these topics and can be seen as an expansion on this topic from what was specified in RFC 5194.. In my view, it is a typical SIPPING topic, so therefore I turn to = Dispatch with the question of where to discuss it. -------------------------------------------------------------------------= --- --------------------- =20 Title : Real-time text interworking between PSTN and IP networks Author(s) : G. Hellstrom, et al. Filename : draft-hellstrom-txtgwy-01.txt Pages : 16 Date : 2009-07-13 IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is = supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice. This specification describes procedures for interworking between ToIP = and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time = during the call are included. Interworking of PSTN textphones that do not = support simultaneity of voice and text with IP User Agents that support = simultaneous voice and text is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-01.txt =20 ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se =20 =20 ------=_NextPart_000_0127_01CA0AB2.9405B960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A new draft is = available=20 at

http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-0= 1.txt

When a feature is = offered in=20 one network, it is important to offer interoperability with other = networks.=20

Even if real-time = text in IP=20 networks overshadow what was avialable in PSTN in terms of = functionality, it is=20 still possible to arrange interoperability between real-time text in IP = networks=20 with the different forms of text telephony that are available in = PSTN=20 networks ( e.g. TTY, EDT, V.21 based, DTMF based etc = ).  Issues=20 on many levels appear when such interoperability shall be arranged. = e.g. on=20 routing, media negotiating, indications to the users, handling the = limitations=20 in media simultaneity in PSTN in contrast with the full simultaneity = possible in=20 IP etc. 

The draft gives = guidance on=20 many of these topics and can be seen as an expansion on this topic from = what was=20 specified in RFC 5194..

In my view, it is = a typical=20 SIPPING topic, so therefore I turn to Dispatch with the question of = where to=20 discuss it.

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

Title : Real-time text interworking between PSTN = and IP=20 networks

Author(s) : G. Hellstrom, et al.

Filename : = draft-hellstrom-txtgwy-01.txt

Pages : 16

Date : 2009-07-13

IP networks can support real-time text = communication.=20 SIP-based

real- time text is called Text-over-IP or ToIP. = PSTN=20 networks support real-time text using textphones (or TTYs). When = real-time text=20 is supported by different networks, gateways are needed to provide=20 interoperability. Real-time text capable gateways may also support = real-time=20 voice.

This specification describes procedures for = interworking=20 between ToIP and PSTN textphones using a real-time text capable gateway = (RTT=20 gateway). It also describes ways to route calls to RTT gateways for = several call=20 scenarios.

Procedures that support the phased introduction of = RTT=20 gateways and procedures that support the invocation of text channels at = any time=20 during the call are included. Interworking of PSTN textphones that do = not=20 support simultaneity of voice and text with IP User Agents that support=20 simultaneous voice and text is also described.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-0= 1.txt

 
----------------------------------------------------------------= ---
Gunnar = Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se
Tel: = +46708204288
www.omnitor.se
 
------=_NextPart_000_0127_01CA0AB2.9405B960-- From john.elwell@siemens-enterprise.com Wed Jul 22 01:35:22 2009 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 5BBCF3A6847 for ; Wed, 22 Jul 2009 01:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 Yr4dr8OXdXAH for ; Wed, 22 Jul 2009 01:35:21 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C5E2E3A683A for ; Wed, 22 Jul 2009 01:35:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN600G6DD10YV@siemenscomms.co.uk> for dispatch@ietf.org; Wed, 22 Jul 2009 09:31:48 +0100 (BST) Date: Wed, 22 Jul 2009 09:31:43 +0100 From: "Elwell, John" In-reply-to: To: Michael Procter Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A36EA@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted Thread-Index: AcoKo9ntYxmxfHlJTyy0hvmBwwCkTAAArJug Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 22 Jul 2009 08:35:22 -0000 Michael, Thanks for your comment. The intention was indeed to have the same level of assurance. I am not sure how to reword it (without reproducing all the previous requirements and adapting them to the connected identity case). John > -----Original Message----- > From: Michael Procter [mailto:michael@voip.co.uk]=20 > Sent: 22 July 2009 09:10 > To: Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted >=20 > Hi John, >=20 > 2009/6/29 Elwell, John : > >=20 > http://www.ietf.org/internet-drafts/draft-elwell-dispatch-iden > tity-reqs-00.txt > > > > We would appreciate feedback as to whether this is helpful=20 > and going in the right direction, as well as detailed comments. >=20 > I think you have identified some useful fundamental properties of > caller/callee id in your requirements. My only query is about Req 6: > "meeting similar requirements to those above" seems a little > ambiguous. Did you intend for the calling user to receive the same > level of assurance concerning the providence of the callee ID, or > would you expect a lower level to be sufficient? >=20 > Best regards, >=20 > Michael >=20 From michael@voip.co.uk Wed Jul 22 02:05:25 2009 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 CA0653A6DA9 for ; Wed, 22 Jul 2009 02:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SUB_OBFU_Q1=0.227] 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 LTZsgL2GFKhe for ; Wed, 22 Jul 2009 02:05:25 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 04AA23A6DB0 for ; Wed, 22 Jul 2009 02:05:23 -0700 (PDT) Received: from source ([72.14.220.154]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKSmbWUxs9JhuPWXe3URcmgmfZTippX+gM@postini.com; Wed, 22 Jul 2009 02:05:25 PDT Received: by fg-out-1718.google.com with SMTP id e12so947978fga.19 for ; Wed, 22 Jul 2009 02:05:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.73.7 with SMTP id v7mr598631fga.46.1248253522298; Wed, 22 Jul 2009 02:05:22 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022A36EA@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A36EA@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 22 Jul 2009 10:05:22 +0100 Message-ID: From: Michael Procter To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 22 Jul 2009 09:05:25 -0000 2009/7/22 Elwell, John : > Michael, > > Thanks for your comment. The intention was indeed to have the same level > of assurance. I am not sure how to reword it (without reproducing all > the previous requirements and adapting them to the connected identity > case). Ah. I see your problem. Reproducing them is certainly one option, one that at least is explicit! How about: REQ6 - It MUST be possible for a calling user to receive connected user identification meeting corresponding requirements to those above for caller identification. But it may be just me reading more flexibility into 'similar' than I should. Michael From john.elwell@siemens-enterprise.com Wed Jul 22 02:31:52 2009 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 A4BBB3A6B4D for ; Wed, 22 Jul 2009 02:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 jVJOSLYbS7k7 for ; Wed, 22 Jul 2009 02:31:51 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B8A903A68DA for ; Wed, 22 Jul 2009 02:31:51 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN600K1AFQTLN@siemenscomms.co.uk> for dispatch@ietf.org; Wed, 22 Jul 2009 10:30:29 +0100 (BST) Date: Wed, 22 Jul 2009 10:30:21 +0100 From: "Elwell, John" In-reply-to: To: Michael Procter Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A37A1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted Thread-Index: AcoKq5ZqC//KThXXRtaK6al86iBthgAA1Y4w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A36EA@GBNTHT12009MSX.gb002.siemens.net> Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted 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, 22 Jul 2009 09:31:52 -0000 OK, if there is interest in a further rev of this, I will make that change. John=20 > -----Original Message----- > From: Michael Procter [mailto:michael@voip.co.uk]=20 > Sent: 22 July 2009 10:05 > To: Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted >=20 > 2009/7/22 Elwell, John : > > Michael, > > > > Thanks for your comment. The intention was indeed to have=20 > the same level > > of assurance. I am not sure how to reword it (without=20 > reproducing all > > the previous requirements and adapting them to the=20 > connected identity > > case). >=20 > Ah. I see your problem. Reproducing them is certainly one option, > one that at least is explicit! >=20 > How about: >=20 > REQ6 - It MUST be possible for a calling user to receive connected > user identification meeting corresponding requirements to=20 > those above for > caller identification. >=20 > But it may be just me reading more flexibility into 'similar'=20 > than I should. >=20 > Michael >=20 From pkyzivat@cisco.com Wed Jul 22 07:10:31 2009 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 7C93B3A68C5 for ; Wed, 22 Jul 2009 07:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 ssVWJZujKbtn for ; Wed, 22 Jul 2009 07:10:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A76003A67DA for ; Wed, 22 Jul 2009 07:10:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB+6ZkpAZnmf/2dsb2JhbAC5DIgjkGsFhA4 X-IronPort-AV: E=Sophos;i="4.43,247,1246838400"; d="scan'208";a="51386360" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2009 14:08:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6ME8sD5018425; Wed, 22 Jul 2009 10:08:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6ME8sWq008469; Wed, 22 Jul 2009 14:08:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:08:53 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:08:53 -0400 Message-ID: <4A671D75.6000907@cisco.com> Date: Wed, 22 Jul 2009 10:08:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> In-Reply-To: <4A66AFF3.7040500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 14:08:53.0572 (UTC) FILETIME=[F1DF1040:01CA0AD5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1842; t=1248271734; x=1249135734; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=NNXL8REtiHNyNBCcXMHD1TkKjxmWkQ8FZeMGXoHQCuw=; b=T/ncEkgowvLypLMb/h8yDWDKUO0YbRdaymQHtAiWJZtKddgGpm3WbCVHxP 5B9K8DZ9TWTcLg/CujsBU8emE1T6bw2TpoUE/4we7IHA9o1JZD8F7r3IT11d eRkX07G8nM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Anders Kristensen , dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 14:10:31 -0000 Gonzalo, I haven't seen any response to Anders' issue about what happens if both ends want to use disaggregated media. Nor have I seen any explanation of where the control resides that initiates and coordinates the inclusion of multiple media sources into call. *Something* must be capable of saying "I want device X to join call Y using media Z". That is still a centralized point of control even if it isn't directly in the resulting sip signaling flow. Either it is using some exotic form of REFER to cause this to happen, or else it is using some kind of private signaling. Also, if a multimedia call is received by a UAS, and the UAS needs to use disaggregated media to cope with the offered media types, how will that work? Will some of the media be refused initially, and then offered back in a new INVITE going in the reverse direction? There are a *lot* of details here that need to be worked out for this approach to be functional. OTOH, if the "centralized" approach is used then it all devolves to use of stuff we already have. Thanks, Paul Gonzalo Camarillo wrote: > Hi, > >> That is correct. I don't see separating audio and video for a single call >> to be desireable (for example). > > exactly. Regular UAs would continue establishing multi-stream sessions > as usual (i.e., using a single dialog). You would only have multiple > dialogs when multiple SIP-enabled devices are involved in the > communication. > >> In my mind, the term "disaggregated media" is a misnomer. It's really >> "loosely coupled control" that is useful. > > yes, that would be a valid term as well. > > Cheers, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Wed Jul 22 07:14:50 2009 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 AF35F3A68D3 for ; Wed, 22 Jul 2009 07:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 bgCjxcksbyyh for ; Wed, 22 Jul 2009 07:14:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0A09E3A686D for ; Wed, 22 Jul 2009 07:14:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMO7ZkpAZnme/2dsb2JhbAC5GYgjkGoFhA4 X-IronPort-AV: E=Sophos;i="4.43,247,1246838400"; d="scan'208";a="51339775" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2009 14:12:56 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6MECuar030808; Wed, 22 Jul 2009 10:12:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6MECrP5011265; Wed, 22 Jul 2009 14:12:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:12:53 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 10:12:52 -0400 Message-ID: <4A671E64.8050703@cisco.com> Date: Wed, 22 Jul 2009 10:12:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> <4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <4A66AA26.6010303@ericsson.com> In-Reply-To: <4A66AA26.6010303@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 14:12:53.0022 (UTC) FILETIME=[80983BE0:01CA0AD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1897; t=1248271976; x=1249135976; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=3LJSma6vPlTZc+cUY8zW5aJI5KS4Ga7nJCsIPHNsF70=; b=OqHfLF5MSQSplNHnOCv0KRQ5v/CL5wo8SipW+5gMfHp5Bi/VJv6QlRy5Zj iknEfa7J9HB7Y2LtTIyGAmVDVXvcxtq2Hm9jk4S5LFTt0eQv+/8d6JcVGm/a bVZ35ON7uz; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Anders Kristensen , Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 14:14:50 -0000 Gonzalo Camarillo wrote: > Hi, > >> I would agree with Paul and John. There's a well established way of >> handling multiple media streams in SIP - part of SIP since the >> beginning. Don't tamper with that. > > yes, it exists in an imaginary world that some IETFers live in. If you > check in the real world, no UAs support that type of functionality. If > we IETF specs to become irrelevant, continuing living in such imaginary > world and ignoring reality is the best way forward. I had this functionality working in about 2002. We didn't productize it, but it was functional. Thanks, Paul >> Plus I'd be very skeptical about claims that the alternative is >> simple. For example, how do you transfer an audio+video call that is >> actually two SIP dialogs? Now all of a sudden there are additional >> failure modes because the dialogs have to be transferred separately >> and can succeed or fail independently. > > We have mechanisms to deal with transfers of a single dialog. That is > what you would do; exactly the same as in the 3pcc model: you transfer > each dialog to its new location. > >> Existing UAs may already support simultaneous dialogs. If they're >> independent calls then that's not at all the same thing. > > That is exactly my point. Existing UAs *already* support multiple > dialogs. Presenting the video stream established by one dialog and the > IM stream established by the other one as if they were a single session > is *very* simple and, at the protocol level, it can also be implemented > with a simple mechanism. All the alternatives given (e.g., 3pcc) are not > currently supported and are way more complex. > > Cheers, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From AUDET@nortel.com Wed Jul 22 08:40:43 2009 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 D58EA3A6929 for ; Wed, 22 Jul 2009 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 EGg-E2hpqAss for ; Wed, 22 Jul 2009 08:40:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0A3783A6820 for ; Wed, 22 Jul 2009 08:40:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6MFFhr17161; Wed, 22 Jul 2009 15:15:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jul 2009 10:17:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A3B82@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A671D75.6000907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: AcoK1gZWFHK+oOVaQ7OI2spUzpepGgACU91g References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> <4A671D75.6000907@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Gonzalo Camarillo" Cc: Anders Kristensen , Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 15:40:43 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, July 22, 2009 07:09 > To: Gonzalo Camarillo > Cc: Audet, Francois (SC100:3055); Anders Kristensen; Henry=20 > Sinnreich; dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 > Gonzalo, >=20 > I haven't seen any response to Anders' issue about what=20 > happens if both ends want to use disaggregated media. >=20 > Nor have I seen any explanation of where the control resides=20 > that initiates and coordinates the inclusion of multiple=20 > media sources into call. *Something* must be capable of=20 > saying "I want device X to join call Y using media Z". That=20 > is still a centralized point of control even if it isn't=20 > directly in the resulting sip signaling flow. Either it is=20 > using some exotic form of REFER to cause this to happen, or=20 > else it is using some kind of private signaling. I don't think we need/want the "...using media Z" part. I truely believe that this makes it too complicated. Again, loose coupling. From gonzalo.camarillo@ericsson.com Wed Jul 22 08:56:37 2009 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 3636C3A6B66 for ; Wed, 22 Jul 2009 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 p01SSWAuEUlk for ; Wed, 22 Jul 2009 08:56:36 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2BF533A684D for ; Wed, 22 Jul 2009 08:56:32 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-45-4a67366ce82c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 88.6D.18827.C66376A4; Wed, 22 Jul 2009 17:55:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 17:54:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 17:54:17 +0200 Received: from [131.160.126.242] (rvi2-126-242.lmf.ericsson.se [131.160.126.242]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0CBBE2461; Wed, 22 Jul 2009 18:54:17 +0300 (EEST) Message-ID: <4A673628.2060009@ericsson.com> Date: Wed, 22 Jul 2009 18:54:16 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net> <4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <4A66AA26.6010303@ericsson.com> <4A671E64.8050703@cisco.com> In-Reply-To: <4A671E64.8050703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 15:54:17.0334 (UTC) FILETIME=[AB209160:01CA0AE4] X-Brightmail-Tracker: AAAAAA== Cc: Anders Kristensen , Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 15:56:37 -0000 Hi Paul, > I had this functionality working in about 2002. We didn't productize it, > but it was functional. yes, I also have a lot of proof-of-concept prototypes in my lab that implement stuff that never makes it into a product for different reasons ;o)... as a matter of fact, I can have a student implement a header that correlates two dialogs on top of a UA that already supports multiple dialogs in no time. However, this is not what we are discussing here. We are discussing specifications that will see actual deployment. Cheers, Gonzalo From pkyzivat@cisco.com Wed Jul 22 09:52:11 2009 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 4975F3A6B4C for ; Wed, 22 Jul 2009 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 Un1E2xGAAQof for ; Wed, 22 Jul 2009 09:52:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4B01E3A6A3D for ; Wed, 22 Jul 2009 09:52:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMzgZkpAZnmf/2dsb2JhbAC7Q4glkQ4FhA4 X-IronPort-AV: E=Sophos;i="4.43,247,1246838400"; d="scan'208";a="51409797" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2009 16:51:02 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6MGp29Y029888; Wed, 22 Jul 2009 12:51:02 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6MGp2hi022177; Wed, 22 Jul 2009 16:51:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 12:51:02 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 12:51:02 -0400 Message-ID: <4A674376.8020106@cisco.com> Date: Wed, 22 Jul 2009 12:51:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> <4A671D75.6000907@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B82@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F1A3B82@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 16:51:02.0254 (UTC) FILETIME=[989E20E0:01CA0AEC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1659; t=1248281462; x=1249145462; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Francois=20Audet=20; bh=cn/AxL9Hf8BQ1OnC3jgeeZhcnHsxUWx8uO7yZWMgN+E=; b=ABHfGjAqRcy9BtQ5D22XUgAbiZ+IYAsstRv5IKtbFto/rsi5fBR3EwqkSp 80DuVVbm9Gr2btpHRxBqlZ1D/eFauTahhM59xab7xtfi53mEGOtwc1Glw7TR mjWoEMvLty; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Anders Kristensen , Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 16:52:11 -0000 Francois Audet wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, July 22, 2009 07:09 >> To: Gonzalo Camarillo >> Cc: Audet, Francois (SC100:3055); Anders Kristensen; Henry >> Sinnreich; dispatch@ietf.org >> Subject: Re: [dispatch] Disaggregated Media in SIP >> >> Gonzalo, >> >> I haven't seen any response to Anders' issue about what >> happens if both ends want to use disaggregated media. >> >> Nor have I seen any explanation of where the control resides >> that initiates and coordinates the inclusion of multiple >> media sources into call. *Something* must be capable of >> saying "I want device X to join call Y using media Z". That >> is still a centralized point of control even if it isn't >> directly in the resulting sip signaling flow. Either it is >> using some exotic form of REFER to cause this to happen, or >> else it is using some kind of private signaling. > > I don't think we need/want the "...using media Z" part. Well, as I understand them, most or all of the use cases in the draft would require some sort of instruction to the secondary device to tell it what media to use, because it would otherwise use media that the use case assumes it will not use. > I truely believe that this makes it too complicated. All the more reason to ensure we agree on a goal set of use cases so we can be sure there is a mechanism sufficiently rich to support them without being unnecessarily complicated. Its no good to do something simple if it doesn't solve a problem. Thanks, Paul > Again, loose coupling. > From alan@sipstation.com Wed Jul 22 10:07:39 2009 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 D6A833A6B18 for ; Wed, 22 Jul 2009 10:07:39 -0700 (PDT) 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 s5wrC-cDTdHq for ; Wed, 22 Jul 2009 10:07:39 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 097553A6897 for ; Wed, 22 Jul 2009 10:07:39 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MTer0-0009XS-Nj for dispatch@ietf.org; Wed, 22 Jul 2009 16:39:43 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/teKURKwgFiFpQkST7ZzgjrIs4rRSuh3A= Message-ID: <4A6740CD.3070609@sipstation.com> Date: Wed, 22 Jul 2009 11:39:41 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Proposed Charter for CCUS - Call Control UUI for SIP 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, 22 Jul 2009 17:07:39 -0000 For discussion during DISPATCH next week. Comments most welcome. Thanks, Alan - - - - - - The Call Control UUI for SIP (CCUS) working group is chartered to define a SIP mechanism for transporting call control related user-to-user (UUI) information between User Agents. The ISDN User to User Information Service, defined by ITU-T Q.931, is extensively deployed in the PSTN today, supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction, and must survive proxy retargeting, redirection, and transfers. The mechanism must utilize a minimum of SIP extensions as it will need to be supported by many simple SIP user agents such as PSTN gateways. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI can be generated by a number of protocols that are not ISUP, and as such it is architecturally unreasonable to interwork these protocols at the SIP / ISUP gateway. That is, existing SIP-T approaches defined in RFC3372 do not meet the requirements. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones ==================== Dec 09 - Problem statement and requirements document to IESG (Informational) Mar 10 - SIP call control UUI specification to IESG (PS) From AUDET@nortel.com Wed Jul 22 10:34:37 2009 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 C32683A6B91 for ; Wed, 22 Jul 2009 10:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 Ad1hQRklLgjs for ; Wed, 22 Jul 2009 10:34:37 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BF8763A6A31 for ; Wed, 22 Jul 2009 10:34:36 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6MHVmr13959; Wed, 22 Jul 2009 17:31:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jul 2009 12:33:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A3F29@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A674376.8020106@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Disaggregated Media in SIP thread-index: AcoK7Kgk9f2pqVoVT4mxHKloOg2HagABclpw References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> <4A671D75.6000907@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A3B82@zrc2hxm0.corp.nortel.com> <4A674376.8020106@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: Anders Kristensen , Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 22 Jul 2009 17:35:40 -0000 The more I hear from the mailing list, the more I think we=20 might have more than one goal. So we may need multiple solutions.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, July 22, 2009 09:51 > To: Audet, Francois (SC100:3055) > Cc: Gonzalo Camarillo; Anders Kristensen; Henry Sinnreich;=20 > dispatch@ietf.org > Subject: Re: [dispatch] Disaggregated Media in SIP >=20 >=20 >=20 > Francois Audet wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, July 22, 2009 07:09 > >> To: Gonzalo Camarillo > >> Cc: Audet, Francois (SC100:3055); Anders Kristensen; Henry=20 > Sinnreich;=20 > >> dispatch@ietf.org > >> Subject: Re: [dispatch] Disaggregated Media in SIP > >> > >> Gonzalo, > >> > >> I haven't seen any response to Anders' issue about what happens if=20 > >> both ends want to use disaggregated media. > >> > >> Nor have I seen any explanation of where the control resides that=20 > >> initiates and coordinates the inclusion of multiple media sources=20 > >> into call. *Something* must be capable of saying "I want=20 > device X to=20 > >> join call Y using media Z". That is still a centralized point of=20 > >> control even if it isn't directly in the resulting sip signaling=20 > >> flow. Either it is using some exotic form of REFER to=20 > cause this to=20 > >> happen, or else it is using some kind of private signaling. > >=20 > > I don't think we need/want the "...using media Z" part. >=20 > Well, as I understand them, most or all of the use cases in=20 > the draft would require some sort of instruction to the=20 > secondary device to tell it what media to use, because it=20 > would otherwise use media that the use case assumes it will not use. >=20 > > I truely believe that this makes it too complicated. >=20 > All the more reason to ensure we agree on a goal set of use=20 > cases so we can be sure there is a mechanism sufficiently=20 > rich to support them without being unnecessarily complicated.=20 > Its no good to do something simple if it doesn't solve a problem. >=20 > Thanks, > Paul >=20 > > Again, loose coupling. > >=20 >=20 From mary.barnes@nortel.com Wed Jul 22 11:14:55 2009 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 AB34F3A699A for ; Wed, 22 Jul 2009 11:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 ovSoqEQ4rmJI for ; Wed, 22 Jul 2009 11:14:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C06323A6891 for ; Wed, 22 Jul 2009 11:14:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6MHPUV15679; Wed, 22 Jul 2009 17:25:30 GMT 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, 22 Jul 2009 12:27:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A3EEF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF-75 thread-index: Acn153kP1X5k/+9FT4+/LlrWl8aLvQVCSSmg From: "Mary Barnes" To: Subject: [dispatch] Agenda for IETF-75 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, 22 Jul 2009 18:14:55 -0000 Hi folks, The final agenda for IETF-75 for the DISPATCH WG session is available: http://www.ietf.org/proceedings/09jul/agenda/dispatch.html As mentioned previously, in order for the f2f meeting time to be effective, we should be having ongoing discussion of these topics prior to the meeting - at a minimum folks need to have thoroughly reviewed the materials for each topic. Alan has just posted an updated cc-uui proposal, please take a look at that. Additional feedback on Scott's 3rd party authorization proposal would be extremely useful. There is now a document for session recording, which has only received one set of comments.=20 So, please review the materials and provided feedback on the mailing list. Regards, Mary DISPATCH WG co-chair From spromano@unina.it Wed Jul 22 11:46:27 2009 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 EB1FE3A6861 for ; Wed, 22 Jul 2009 11:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 G2zQ1JYbyr4F for ; Wed, 22 Jul 2009 11:46:27 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id BBC683A69FF for ; Wed, 22 Jul 2009 11:46:22 -0700 (PDT) Received: from localhost (webmail.unina.it [192.132.34.212]) by smtp2.unina.it (8.14.0/8.14.0) with ESMTP id n6MIYCQt019304; Wed, 22 Jul 2009 20:34:16 +0200 Received: from 143.225.229.187 ([143.225.229.187]) by webmail.unina.it (Horde MIME library) with HTTP; Wed, 22 Jul 2009 20:34:12 +0200 Message-ID: <20090722203412.o5bd99obesogws40@webmail.unina.it> Date: Wed, 22 Jul 2009 20:34:12 +0200 From: spromano@unina.it To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1F1A3EEF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F1A3EEF@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.1/9605/Wed Jul 22 17:08:14 2009 on smtp2.unina.it X-Virus-Status: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] Agenda for IETF-75 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, 22 Jul 2009 18:46:28 -0000 Hi Mary and others, you might also be interested in having a look at the following draft =20 we submitted on july 6th and which was not advertised on the list: http://tools.ietf.org/html/draft-romano-dcon-recording-00 "Session Recording for Conferences using SMIL" Cheers, Simon Quoting Mary Barnes : > Hi folks, > > The final agenda for IETF-75 for the DISPATCH WG session is available: > http://www.ietf.org/proceedings/09jul/agenda/dispatch.html > > As mentioned previously, in order for the f2f meeting time to be > effective, we should be having ongoing discussion of these topics prior > to the meeting - at a minimum folks need to have thoroughly reviewed the > materials for each topic. Alan has just posted an updated cc-uui > proposal, please take a look at that. Additional feedback on Scott's 3rd > party authorization proposal would be extremely useful. There is now a > document for session recording, which has only received one set of > comments. > > So, please review the materials and provided feedback on the mailing > list. > > Regards, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From john.elwell@siemens-enterprise.com Thu Jul 23 00:34:00 2009 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 A63633A6765 for ; Thu, 23 Jul 2009 00:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 0hKglxvVo+OU for ; Thu, 23 Jul 2009 00:33:59 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6AF453A688C for ; Thu, 23 Jul 2009 00:33:58 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN800443351V7@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 23 Jul 2009 07:53:25 +0100 (BST) Date: Thu, 23 Jul 2009 07:53:23 +0100 From: "Elwell, John" In-reply-to: <4A6740CD.3070609@sipstation.com> To: Alan Johnston , dispatch@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] Proposed Charter for CCUS - Call Control UUI for SIP Thread-Index: AcoK7vp00sgslqoKRnae7VKxlmy8rQAcsWCw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A6740CD.3070609@sipstation.com> Subject: Re: [dispatch] Proposed Charter for CCUS - Call Control UUI for SIP 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, 23 Jul 2009 07:34:00 -0000 Alan, What is meant exactly by "must survive ... transfers". Surviving retargeting and redirection I am comfortable with, but transfers? Would it be worth enumerating the particular ISDN services that it is intended to work with? I believe it is just UUI1. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: 22 July 2009 17:40 > To: dispatch@ietf.org > Subject: [dispatch] Proposed Charter for CCUS - Call Control=20 > UUI for SIP >=20 > For discussion during DISPATCH next week. Comments most welcome. >=20 > Thanks, > Alan >=20 > - - - - - - >=20 > The Call Control UUI for SIP (CCUS) working group is chartered to=20 > define a SIP mechanism for transporting call control related=20 > user-to-user (UUI) information between User Agents. >=20 > The ISDN User to User Information Service, defined by ITU-T Q.931, is=20 > extensively deployed in the PSTN today, supporting such=20 > applications as=20 > contact centers, call centers, and automatic call=20 > distributors (ACDs). =20 > A major barrier to the movement of these applications to SIP=20 > is the lack=20 > of a standard mechanism to transport this information in SIP. >=20 > Call control UUI is user information conveyed between user=20 > agents during=20 > call control operations. As a result, the information must=20 > be conveyed=20 > with the INVITE transaction, and must survive proxy retargeting,=20 > redirection, and transfers. The mechanism must utilize a=20 > minimum of SIP=20 > extensions as it will need to be supported by many simple SIP user=20 > agents such as PSTN gateways. The mechanism must interwork with the=20 > existing ISDN service but should also be extensible for use by other=20 > applications and non-ISDN protocols. >=20 > While PSTN UUI is carried in ISUP (ISDN User Part), SIP call=20 > control UUI=20 > can be generated by a number of protocols that are not ISUP,=20 > and as such=20 > it is architecturally unreasonable to interwork these=20 > protocols at the=20 > SIP / ISUP gateway. That is, existing SIP-T approaches defined in=20 > RFC3372 do not meet the requirements. >=20 > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > considered=20 > by the working group since the UUI contents carry information=20 > that must=20 > be conveyed during session setup at the user agent - the information=20 > must be conveyed with the INVITE transaction. The=20 > information must be=20 > passed with the session setup request (INVITE), responses to that=20 > INVITE, or session termination requests. As a result, it is not=20 > possible to use INFO in these cases. >=20 > The group will produce: >=20 > - A problem statement and requirements document for=20 > implementing a SIP=20 > call control UUI mechanism >=20 > - A specification of the SIP extension to best meet those=20 > requirements. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Dec 09 - Problem statement and requirements document to IESG=20 > (Informational) > Mar 10 - SIP call control UUI specification to IESG (PS) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From Leon.Portman@nice.com Thu Jul 23 00:54:19 2009 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 0FA753A6817 for ; Thu, 23 Jul 2009 00:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 sTSnadbO+FfL for ; Thu, 23 Jul 2009 00:54:18 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id D15593A6765 for ; Thu, 23 Jul 2009 00:54:17 -0700 (PDT) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 23 Jul 2009 10:52:02 +0300 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 23 Jul 2009 10:52:02 +0300 From: Leon Portman To: "spromano@unina.it" , Mary Barnes Date: Thu, 23 Jul 2009 10:52:01 +0300 Thread-Topic: [dispatch] Agenda for IETF-75 Thread-Index: AcoK/LwdFAFPlYuDTuCjm4kFZJPIjAAbLB9A Message-ID: <07465C1D981ABC41A344374066AE1A2C37D5153CEF@TLVMBX01.nice.com> References: <1ECE0EB50388174790F9694F77522CCF1F1A3EEF@zrc2hxm0.corp.nortel.com> <20090722203412.o5bd99obesogws40@webmail.unina.it> In-Reply-To: <20090722203412.o5bd99obesogws40@webmail.unina.it> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Agenda for IETF-75 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, 23 Jul 2009 07:54:19 -0000 Simon, Hi It will be very interesting to see how we can combine both works: generic s= ession recording protocol and your work regarding conferencing recording. >From my point of view both these draft complement each other: SRP is more f= ocused on interaction between recording system and communication system an= d DCON recording is focused on how actually conference resource will be all= ocated and inserted to the call in order to be able to forward media to rec= ording - in the terms of SRP is how to implement conference based recording= client. Obviously there are also other important use cases for recording w= here conferencing is not valuable option because another component that alr= eady involved in the media path can do the forking: B2BUA, gateway, end poi= nts. Using SMIL for capturing metadata for the recording is also very interestin= g concept and well worth discussion. Regards Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of spromano@unina.it Sent: Wednesday, July 22, 2009 9:34 PM To: Mary Barnes Cc: dispatch@ietf.org Subject: Re: [dispatch] Agenda for IETF-75 Hi Mary and others, you might also be interested in having a look at the following draft =20 we submitted on july 6th and which was not advertised on the list: http://tools.ietf.org/html/draft-romano-dcon-recording-00 "Session Recording for Conferences using SMIL" Cheers, Simon Quoting Mary Barnes : > Hi folks, > > The final agenda for IETF-75 for the DISPATCH WG session is available: > http://www.ietf.org/proceedings/09jul/agenda/dispatch.html > > As mentioned previously, in order for the f2f meeting time to be > effective, we should be having ongoing discussion of these topics prior > to the meeting - at a minimum folks need to have thoroughly reviewed the > materials for each topic. Alan has just posted an updated cc-uui > proposal, please take a look at that. Additional feedback on Scott's 3rd > party authorization proposal would be extremely useful. There is now a > document for session recording, which has only received one set of > comments. > > So, please review the materials and provided feedback on the mailing > list. > > Regards, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Leon.Portman@nice.com Thu Jul 23 04:30:20 2009 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 6A37328C12F for ; Thu, 23 Jul 2009 04:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 ljnUfukhAIX4 for ; Thu, 23 Jul 2009 04:30:19 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 19FD928C11C for ; Thu, 23 Jul 2009 04:30:19 -0700 (PDT) Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 23 Jul 2009 14:24:40 +0300 Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 23 Jul 2009 14:24:40 +0300 From: Leon Portman To: "spromano@unina.it" Date: Thu, 23 Jul 2009 14:24:39 +0300 Thread-Topic: [dispatch] Agenda for IETF-75 Thread-Index: AcoLg4QUnX4fZqojSjeksVSWRIZYkwABHnVw Message-ID: <07465C1D981ABC41A344374066AE1A2C37D5153E68@TLVMBX01.nice.com> References: <1ECE0EB50388174790F9694F77522CCF1F1A3EEF@zrc2hxm0.corp.nortel.com> <20090722203412.o5bd99obesogws40@webmail.unina.it> <07465C1D981ABC41A344374066AE1A2C37D5153CEF@TLVMBX01.nice.com> <20090723125021.h3f0n0n5wg8kw08w@webmail.unina.it> In-Reply-To: <20090723125021.h3f0n0n5wg8kw08w@webmail.unina.it> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Agenda for IETF-75 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, 23 Jul 2009 11:30:20 -0000 Yes, of course. I will be only until Tuesday so Sunday, Monday and Tuesday = morning are all open. Regards and looking forward Leon -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: Thursday, July 23, 2009 1:50 PM To: Leon Portman Cc: Mary Barnes; dispatch@ietf.org Subject: RE: [dispatch] Agenda for IETF-75 Hi Leon, I totally agree with your proposal and I'm looking forward to working =20 together on the topic. What about discussing this f2f next week in =20 Stocholm? Cheers, Simon Quoting Leon Portman : > Simon, Hi > > It will be very interesting to see how we can combine both works: =20 > generic session recording protocol and your work regarding =20 > conferencing recording. > From my point of view both these draft complement each other: SRP is =20 > more focused on interaction between recording system and =20 > communication system and DCON recording is focused on how actually =20 > conference resource will be allocated and inserted to the call in =20 > order to be able to forward media to recording - in the terms of SRP =20 > is how to implement conference based recording client. Obviously =20 > there are also other important use cases for recording where =20 > conferencing is not valuable option because another component that =20 > already involved in the media path can do the forking: B2BUA, =20 > gateway, end points. > > Using SMIL for capturing metadata for the recording is also very =20 > interesting concept and well worth discussion. > > Regards > > Leon > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20 > On Behalf Of spromano@unina.it > Sent: Wednesday, July 22, 2009 9:34 PM > To: Mary Barnes > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Agenda for IETF-75 > > Hi Mary and others, > > you might also be interested in having a look at the following draft > we submitted on july 6th and which was not advertised on the list: > > http://tools.ietf.org/html/draft-romano-dcon-recording-00 > > "Session Recording for Conferences using SMIL" > > Cheers, > > Simon > > > Quoting Mary Barnes : > >> Hi folks, >> >> The final agenda for IETF-75 for the DISPATCH WG session is available: >> http://www.ietf.org/proceedings/09jul/agenda/dispatch.html >> >> As mentioned previously, in order for the f2f meeting time to be >> effective, we should be having ongoing discussion of these topics prior >> to the meeting - at a minimum folks need to have thoroughly reviewed the >> materials for each topic. Alan has just posted an updated cc-uui >> proposal, please take a look at that. Additional feedback on Scott's 3rd >> party authorization proposal would be extremely useful. There is now a >> document for session recording, which has only received one set of >> comments. >> >> So, please review the materials and provided feedback on the mailing >> list. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From gonzalo.camarillo@ericsson.com Thu Jul 23 04:31:22 2009 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 283EC28C11C for ; Thu, 23 Jul 2009 04:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.312 X-Spam-Level: X-Spam-Status: No, score=-5.312 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Ij-Gk-8iCYrX for ; Thu, 23 Jul 2009 04:31:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8D4823A6856 for ; Thu, 23 Jul 2009 04:31:16 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc4ae000004197-64-4a683ec4c187 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A9.D8.16791.4CE386A4; Thu, 23 Jul 2009 12:43:16 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:41:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:41:47 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0EF0B2461; Thu, 23 Jul 2009 13:41:47 +0300 (EEST) Message-ID: <4A683E6A.4040508@ericsson.com> Date: Thu, 23 Jul 2009 13:41:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> <4A671D75.6000907@cisco.com> In-Reply-To: <4A671D75.6000907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 10:41:47.0352 (UTC) FILETIME=[2DAE1D80:01CA0B82] X-Brightmail-Tracker: AAAAAA== Cc: Anders Kristensen , dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 23 Jul 2009 11:31:22 -0000 Hi Paul, > Nor have I seen any explanation of where the control resides that > initiates and coordinates the inclusion of multiple media sources > into call. *Something* must be capable of saying "I want device X to > join call Y using media Z". That is still a centralized point of > control even if it isn't directly in the resulting sip signaling > flow. Either it is using some exotic form of REFER to cause this to > happen, or else it is using some kind of private signaling. yes, you could use REFER as you suggest, although (as Francois also pointed out) I would remove the "using media Z" bit. When we designed REFER, we agreed not to include that type of stuff because applications typically know what to include based on the context in which the REFER is received. You could also use some type of private signalling if you want. There is nothing that precludes that. If you want to use your proprietary protocol for local coordination, you can do that. > Also, if a multimedia call is received by a UAS, and the UAS needs to > use disaggregated media to cope with the offered media types, how > will that work? Will some of the media be refused initially, and then > offered back in a new INVITE going in the reverse direction? Yes, this could be implemented like that. > There are a *lot* of details here that need to be worked out for this > approach to be functional. I would have loved to discuss all those details earlier (we submitted our first draft about this a long time ago) but folks did not want to even consider using something else than 3pcc. Once we agree that 3pcc is not the only way to do things, we can work out the details. Note that when we introduced SIP more than 10 years ago many people did not like the fact that media was simply loosely coupled with the signalling. They wanted a tighter coupling... it seems we will have to go through similar discussions once more ;o) You wrote in another message: > All the more reason to ensure we agree on a goal set of use cases so > we can be sure there is a mechanism sufficiently rich to support them > without being unnecessarily complicated. Its no good to do something > simple if it doesn't solve a problem. Yes, agreeing on use cases would be great. That's why the draft has a section with use cases. Fell free to propose new ones or send comments on the existing ones. Thanks, Gonzalo From xavier.marjou@gmail.com Thu Jul 23 05:43:12 2009 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 2F95A3A68EB for ; Thu, 23 Jul 2009 05:43:12 -0700 (PDT) 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 teJ8oE6gK3MP for ; Thu, 23 Jul 2009 05:43:11 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id CCF823A69E8 for ; Thu, 23 Jul 2009 05:43:10 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so265059eye.31 for ; Thu, 23 Jul 2009 05:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=H6vI8KJVzZduQehiM5ZZYUrUCNnlaT7L0dozTwVj3iA=; b=xJVeka6RsYLmu4QSRH32qfNSFlYtlSLaaAIFoI1BwDuAw0extBkIagzGZz6/nqaYTz pXHjn8X9/ns1g8N9c5c2eUsNXpz3H6fPoP92HlxNo0CwQjYcimXGFYuiE2XZP5t0pk1Z 5NHMkNp+7ENT5of0P1qXXbotbBagCmCXIgwuY= 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 :content-type:content-transfer-encoding; b=rTbCL7qz9RIK3f2nrzHhDNVTy7XkNQj7qNfkbaL5E0Nc/GRM2Fr65Na6yq2e7iOWSO l5dmSLL9vyRwv+y/NY4uMnFl59zuVTnd7wGQJ74HIz9oeXLgWjoMy8eWmgQp46FPklqL jNuoz8s7B1WPRwTdehrJmerW2F3EMMzC5OLCo= MIME-Version: 1.0 Received: by 10.216.15.85 with SMTP id e63mr573701wee.199.1248352831668; Thu, 23 Jul 2009 05:40:31 -0700 (PDT) In-Reply-To: <458913680907230539g625443fev5d6ac79916339d8c@mail.gmail.com> References: <458913680907030806u64369fb3jd2c8ce37cdf7e3cc@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1ED2AB60@zrc2hxm0.corp.nortel.com> <458913680907230539g625443fev5d6ac79916339d8c@mail.gmail.com> Date: Thu, 23 Jul 2009 14:40:31 +0200 Message-ID: <458913680907230540u61b5ae53yc668400d63094d73@mail.gmail.com> From: Xavier Marjou To: dispatch@ietf.org, Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] draft-shen-interaction-ind 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, 23 Jul 2009 12:43:12 -0000 Hi Mary, Sorry, I should have answered this mail earlier. On Sat, Jul 4, 2009 at 5:34 PM, Mary Barnes wrote: > Xavier, > Can you point the WG to past ML discussions (in any WG) for this document= ? > I don't recall nor could I find any email threads that indicate this docu= ment had > ever been on the radar for the SIPPING WG. I agree I haven't seen either any discussion on the topic before. > the usage of this "service indicator" is not clear to me, > perhaps because it's based on IMS functionality. Yes, such service indicator would indeed be useful in IMS networks, but it may also be of interest for other networks too. As I see it, this a way to exchange/manage information between services when hosted on different servers in the path of a SIP message. I would thus rather see such an activity -if any- in the scope of dispatch, and not in the scope of ecrit of atoca (maybe other examples should thus be provided). Cheers, Xavier > Regards, > Mary. > DISPATCH WG co-chair > > -----Original Message----- > From: xavier.marjou@gmail.com [mailto:xavier.marjou@gmail.com] On Behalf = Of Xavier Marjou > Sent: Friday, July 03, 2009 10:06 AM > To: dispatch@ietf.org; Barnes, Mary (RICH2:AR00) > Subject: draft-shen-interaction-ind > > Hi, > > As it seems there will be time for additional topics, I have a > suggestion:=A0I would be interested by a presentation of the following > draft: > http://tools.ietf.org/html/draft-shen-interaction-ind-05.txt > > > Cheers, > Xavier > > On Fri, Jun 26, 2009 at 12:51 AM, Mary Barnes wr= ote: >> >> Hi folks, >> >> We have uploaded a revised (tentative) agenda for IETF-75 for the >> DISPATCH WG session: >> http://www.ietf.org/proceedings/09jul/agenda/dispatch.html >> >> Due to popular demand, we have added a slot for Session Recording. >> Note, that the current agenda has us meeting on Thursday afternoon, >> but Cullen has asked for that to be changed to Monday. As always, the >> agenda is subject to change up until the meeting. >> >> As a reminder any new documents related to the agenda topics must be >> submitted by July 6th and any updates to current docs by July 13th. >> And, most importantly we really should be seeing traffic on the list >> on these topics before the meeting so we can have focused discussions >> with conclusions and a well defined way forward. >> >> Please send any comments on the proposed agenda to the list and/or >> Gonzalo and myself. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> _______________________________________________ >> 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 alan@sipstation.com Thu Jul 23 05:56:55 2009 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 C23303A6992 for ; Thu, 23 Jul 2009 05:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 6XRR2HyF19cz for ; Thu, 23 Jul 2009 05:56:54 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id C83E43A63EB for ; Thu, 23 Jul 2009 05:56:54 -0700 (PDT) Received: from 24-107-145-55.dhcp.stls.mo.charter.com ([24.107.145.55] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MTxpk-000KnE-5D; Thu, 23 Jul 2009 12:55:40 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.55 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+U31pMXotw3gVIF8uX6/mvOrExkarnvak= Message-ID: <4A685DC9.9080209@sipstation.com> Date: Thu, 23 Jul 2009 07:55:37 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Elwell, John" References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed Charter for CCUS - Call Control UUI for SIP 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, 23 Jul 2009 12:56:55 -0000 John, Thanks for your comments. Transfers means the ability to pass UUI in a Refer-To URI in a REFER. This requirement and the use cases are in: http://tools.ietf.org/html/draft-johnston-dispatch-sip-cc-uui which is the same set of requirements and use cases we discussed in SIPPING in the past. I'm not trying to add or change these requirements, just summarize them at a high level in the charter text. And yes, we should say that this is ISDN UUS Service 1. Thanks, Alan Elwell, John wrote: > Alan, > > What is meant exactly by "must survive ... transfers". Surviving > retargeting and redirection I am comfortable with, but transfers? > > Would it be worth enumerating the particular ISDN services that it is > intended to work with? I believe it is just UUI1. > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston >> Sent: 22 July 2009 17:40 >> To: dispatch@ietf.org >> Subject: [dispatch] Proposed Charter for CCUS - Call Control >> UUI for SIP >> >> For discussion during DISPATCH next week. Comments most welcome. >> >> Thanks, >> Alan >> >> - - - - - - >> >> The Call Control UUI for SIP (CCUS) working group is chartered to >> define a SIP mechanism for transporting call control related >> user-to-user (UUI) information between User Agents. >> >> The ISDN User to User Information Service, defined by ITU-T Q.931, is >> extensively deployed in the PSTN today, supporting such >> applications as >> contact centers, call centers, and automatic call >> distributors (ACDs). >> A major barrier to the movement of these applications to SIP >> is the lack >> of a standard mechanism to transport this information in SIP. >> >> Call control UUI is user information conveyed between user >> agents during >> call control operations. As a result, the information must >> be conveyed >> with the INVITE transaction, and must survive proxy retargeting, >> redirection, and transfers. The mechanism must utilize a >> minimum of SIP >> extensions as it will need to be supported by many simple SIP user >> agents such as PSTN gateways. The mechanism must interwork with the >> existing ISDN service but should also be extensible for use by other >> applications and non-ISDN protocols. >> >> While PSTN UUI is carried in ISUP (ISDN User Part), SIP call >> control UUI >> can be generated by a number of protocols that are not ISUP, >> and as such >> it is architecturally unreasonable to interwork these >> protocols at the >> SIP / ISUP gateway. That is, existing SIP-T approaches defined in >> RFC3372 do not meet the requirements. >> >> Mechanisms based on the SIP INFO method, RFC2976, will not be >> considered >> by the working group since the UUI contents carry information >> that must >> be conveyed during session setup at the user agent - the information >> must be conveyed with the INVITE transaction. The >> information must be >> passed with the session setup request (INVITE), responses to that >> INVITE, or session termination requests. As a result, it is not >> possible to use INFO in these cases. >> >> The group will produce: >> >> - A problem statement and requirements document for >> implementing a SIP >> call control UUI mechanism >> >> - A specification of the SIP extension to best meet those >> requirements. >> >> Goals and Milestones >> ==================== >> >> Dec 09 - Problem statement and requirements document to IESG >> (Informational) >> Mar 10 - SIP call control UUI specification to IESG (PS) >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > > From spromano@unina.it Thu Jul 23 06:10:37 2009 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 A2E1A3A6870 for ; Thu, 23 Jul 2009 06:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 uQ9hrpFpWEx0 for ; Thu, 23 Jul 2009 06:10:36 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id 5C6DE3A63EB for ; Thu, 23 Jul 2009 06:10:32 -0700 (PDT) Received: from localhost (webmail.unina.it [192.132.34.212]) by smtp1.unina.it (8.14.0/8.14.0) with ESMTP id n6NAoLnP021208; Thu, 23 Jul 2009 12:50:22 +0200 Received: from 143.225.229.187 ([143.225.229.187]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 23 Jul 2009 12:50:21 +0200 Message-ID: <20090723125021.h3f0n0n5wg8kw08w@webmail.unina.it> Date: Thu, 23 Jul 2009 12:50:21 +0200 From: spromano@unina.it To: Leon Portman References: <1ECE0EB50388174790F9694F77522CCF1F1A3EEF@zrc2hxm0.corp.nortel.com> <20090722203412.o5bd99obesogws40@webmail.unina.it> <07465C1D981ABC41A344374066AE1A2C37D5153CEF@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D5153CEF@TLVMBX01.nice.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94/9607/Thu Jul 23 04:49:05 2009 on smtp1.unina.it X-Virus-Status: Clean Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Agenda for IETF-75 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, 23 Jul 2009 13:10:37 -0000 Hi Leon, I totally agree with your proposal and I'm looking forward to working =20 together on the topic. What about discussing this f2f next week in =20 Stocholm? Cheers, Simon Quoting Leon Portman : > Simon, Hi > > It will be very interesting to see how we can combine both works: =20 > generic session recording protocol and your work regarding =20 > conferencing recording. > From my point of view both these draft complement each other: SRP is =20 > more focused on interaction between recording system and =20 > communication system and DCON recording is focused on how actually =20 > conference resource will be allocated and inserted to the call in =20 > order to be able to forward media to recording - in the terms of SRP =20 > is how to implement conference based recording client. Obviously =20 > there are also other important use cases for recording where =20 > conferencing is not valuable option because another component that =20 > already involved in the media path can do the forking: B2BUA, =20 > gateway, end points. > > Using SMIL for capturing metadata for the recording is also very =20 > interesting concept and well worth discussion. > > Regards > > Leon > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20 > On Behalf Of spromano@unina.it > Sent: Wednesday, July 22, 2009 9:34 PM > To: Mary Barnes > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Agenda for IETF-75 > > Hi Mary and others, > > you might also be interested in having a look at the following draft > we submitted on july 6th and which was not advertised on the list: > > http://tools.ietf.org/html/draft-romano-dcon-recording-00 > > "Session Recording for Conferences using SMIL" > > Cheers, > > Simon > > > Quoting Mary Barnes : > >> Hi folks, >> >> The final agenda for IETF-75 for the DISPATCH WG session is available: >> http://www.ietf.org/proceedings/09jul/agenda/dispatch.html >> >> As mentioned previously, in order for the f2f meeting time to be >> effective, we should be having ongoing discussion of these topics prior >> to the meeting - at a minimum folks need to have thoroughly reviewed the >> materials for each topic. Alan has just posted an updated cc-uui >> proposal, please take a look at that. Additional feedback on Scott's 3rd >> party authorization proposal would be extremely useful. There is now a >> document for session recording, which has only received one set of >> comments. >> >> So, please review the materials and provided feedback on the mailing >> list. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From gonzalo.camarillo@ericsson.com Thu Jul 23 06:17:55 2009 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 396633A69EE for ; Thu, 23 Jul 2009 06:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Q0yadFmFRmG3 for ; Thu, 23 Jul 2009 06:17:54 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 041523A6939 for ; Thu, 23 Jul 2009 06:17:53 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc4ae000004197-36-4a68629ca15d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D7.D3.16791.C92686A4; Thu, 23 Jul 2009 15:16:13 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:15:53 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:15:53 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C3F92450; Thu, 23 Jul 2009 16:15:53 +0300 (EEST) Message-ID: <4A686289.2070707@ericsson.com> Date: Thu, 23 Jul 2009 16:15:53 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5202A1.6090501@ericsson.com> <4A52902B.2030806@cisco.com> In-Reply-To: <4A52902B.2030806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 13:15:53.0834 (UTC) FILETIME=[B5034CA0:01CA0B97] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Preconditions and intermediaries 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, 23 Jul 2009 13:17:55 -0000 Hi Paul, yes, you are right. The draft assumes a particular setting (e.g., the UAS is the answerer, the UAC reserves the resources and informs the UAS, and the UAS starts using the new parameters). I can fix that and add all the other possible scenarios for completeness. However, before putting any more cycles on this, I would like to know whether or not people think this is important. If so, I can edit the draft so that we can progress it. On the other hand, if folks are not interested in this, I'd rather spend my cycles on something else. Thanks, Gonzalo Paul Kyzivat wrote: >> 2. Starting Using the Media Parameters Subject to Preconditions > ... >> However, the fact that the UAs can start using the new media >> parameters does not mean that they need to start using them >> immediately. When preconditions are used, the UAS decides when to >> start using them. > > Why do you say that? > > For one thing offerer and answerer have more significance than UAC and > UAS in any such decision. > > For another, QoS needs to be obtained by both ends before it can be used > by either end. The order in which it is obtained, and signaled that it > has been obtained, is indeterminate. > > When one end has been told that the other end has obtained it, and knows > that it has obtained it, then it can start using it. > > But that doesn't change the point about signaling the intent to start > using. > > Thanks, > Paul > From pkyzivat@cisco.com Thu Jul 23 06:37:45 2009 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 098A23A695E for ; Thu, 23 Jul 2009 06:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 SlyhAGDckv18 for ; Thu, 23 Jul 2009 06:37:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E24B13A67B3 for ; Thu, 23 Jul 2009 06:37:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFsEaEqrR7MV/2dsb2JhbAC4TYglkQwFhA0 X-IronPort-AV: E=Sophos;i="4.43,255,1246838400"; d="scan'208";a="39942764" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 23 Jul 2009 13:37:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6NDb3OP014691; Thu, 23 Jul 2009 06:37:03 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6NDb2EJ023492; Thu, 23 Jul 2009 13:37:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:37:02 -0400 Received: from [10.86.250.172] ([10.86.250.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:37:02 -0400 Message-ID: <4A68677D.9010703@cisco.com> Date: Thu, 23 Jul 2009 09:37:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> <4A671D75.6000907@cisco.com> <4A683E6A.4040508@ericsson.com> In-Reply-To: <4A683E6A.4040508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 13:37:02.0145 (UTC) FILETIME=[A8FC3310:01CA0B9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3201; t=1248356223; x=1249220223; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20; bh=oOXTsKK+BzDZZnA273W99GMaSwdciMvQ3hB1Ox0yC40=; b=MGNFOcXREuWM/pD6PmYejV/OPHoARKzGqQxGnKAMkXTSNymONzvDuPxkoE 8u+cwCDwD5oiMLgtCL2R7CVF8mFm9xsPHilqdmR3sj7uOwgfmvCkK5ivpHZE tdrGuS/4qlAX8yfjuqV/oPl11gaoB6WXdKcaLGH/pNchrDlRTgaqM=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Anders Kristensen , dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 23 Jul 2009 13:37:45 -0000 Gonzalo Camarillo wrote: > Hi Paul, > >> Nor have I seen any explanation of where the control resides that >> initiates and coordinates the inclusion of multiple media sources >> into call. *Something* must be capable of saying "I want device X to >> join call Y using media Z". That is still a centralized point of >> control even if it isn't directly in the resulting sip signaling >> flow. Either it is using some exotic form of REFER to cause this to >> happen, or else it is using some kind of private signaling. > > yes, you could use REFER as you suggest, although (as Francois also > pointed out) I would remove the "using media Z" bit. When we designed > REFER, we agreed not to include that type of stuff because applications > typically know what to include based on the context in which the REFER > is received. > > You could also use some type of private signalling if you want. There is > nothing that precludes that. If you want to use your proprietary > protocol for local coordination, you can do that. > >> Also, if a multimedia call is received by a UAS, and the UAS needs to >> use disaggregated media to cope with the offered media types, how >> will that work? Will some of the media be refused initially, and then >> offered back in a new INVITE going in the reverse direction? > > Yes, this could be implemented like that. > >> There are a *lot* of details here that need to be worked out for this >> approach to be functional. > > I would have loved to discuss all those details earlier (we submitted > our first draft about this a long time ago) but folks did not want to > even consider using something else than 3pcc. Once we agree that 3pcc is > not the only way to do things, we can work out the details. I find the *use cases* interesting and worthy of discussing independent of the mechanism used to achieve them. Either approach requires some coordination among the disaggregated devices. With the 3pcc approach there is the possibility of using sip to do the coordination, but its still worth investigation since that may not provide the dieal user experience. So I'm not really conceding that the proposed solution is necessary, or even desirable to address the use cases. But I do think that investigating the use cases is a good way to get beyond individual opinions on the subject. > Note that when we introduced SIP more than 10 years ago many people did > not like the fact that media was simply loosely coupled with the > signalling. They wanted a tighter coupling... it seems we will have to > go through similar discussions once more ;o) > > You wrote in another message: > >> All the more reason to ensure we agree on a goal set of use cases so >> we can be sure there is a mechanism sufficiently rich to support them >> without being unnecessarily complicated. Its no good to do something >> simple if it doesn't solve a problem. > > Yes, agreeing on use cases would be great. That's why the draft has a > section with use cases. Fell free to propose new ones or send comments > on the existing ones. I didn't comment because I liked them. Thanks, Paul From dworley@nortel.com Thu Jul 23 11:14:30 2009 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 AB7263A6BC6 for ; Thu, 23 Jul 2009 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 0gfGsBp4oyR6 for ; Thu, 23 Jul 2009 11:14:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 134F63A6C05 for ; Thu, 23 Jul 2009 11:13:47 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6NIDPM16974 for ; Thu, 23 Jul 2009 18:13:25 GMT Received: from [47.141.31.129] ([47.141.31.129]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 14:13:14 -0400 From: "Dale Worley" To: DISPATCH In-Reply-To: <4A6576B9.4020504@ericsson.com> References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 23 Jul 2009 14:13:14 -0400 Message-Id: <1248372794.4427.11.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 18:13:15.0001 (UTC) FILETIME=[3F2D5690:01CA0BC1] Subject: Re: [dispatch] Disaggregated Media in SIP 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, 23 Jul 2009 18:14:30 -0000 On Tue, 2009-07-21 at 11:05 +0300, Gonzalo Camarillo wrote: > well, 3pcc is centralized because you have a (central) controller that > is in control of all SIP signalling. If that controller leaves the > session, the whole session disappears. An approach where several devices > have their own SIP dialog with the remote devices is not centralized > because you can remove any of them and the other sessions will remain > unaffected. It's true that if the implementation is a single dialog, then the UA at each end must remain in the call. For a UA to replace itself with another UA would require a transfer-like process. The difficulty (under either implementation) is to transfer the "state" information (which media stream goes to which destination) from one controller to another. That need is obvious in the centralized approach, but it seems to me that it would also be needed in the decentralized approach. > The arguments have been discussed several times. The thing is that 3pcc > is a complex mechanism that is not supported by most UAs. You can argue > about its complexity, but the fact that most UAs do not support 3pcc is > a fact. This does not seem to be true to me. Phones that support MOH from an external server are doing 3pcc. In addition, we expect phones to support REFER and INVITE-with-Replaces. > A second argument is that any device should be able to leave the session > at any point. If you want the 3pcc controller to leave the session while > the session remains established, you will need to use a complex > combination of REFER and Replaces that very few (if any) UAs support. As a matter of course, we expect our customers to buy phones that support both of these. I suspect the use case that truly distinguishes these implementations is where there is a "controller" at one end, that is, a UA that understands the aggregation, but there is no controller at the other end. Dale From dworley@nortel.com Thu Jul 23 11:43:01 2009 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 BF33A28C12F; Thu, 23 Jul 2009 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 qlYqUIqzQ4Yi; Thu, 23 Jul 2009 11:43:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E452428C0DB; Thu, 23 Jul 2009 11:42:54 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6NIf6M24799; Thu, 23 Jul 2009 18:41:06 GMT Received: from [47.141.31.129] ([47.141.31.129]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 14:40:53 -0400 From: "Dale Worley" To: Victor Pascual Avila In-Reply-To: <618e24240907030640k2898f908s450626af73dad5f8@mail.gmail.com> References: <618e24240907030640k2898f908s450626af73dad5f8@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 23 Jul 2009 14:40:52 -0400 Message-Id: <1248374452.4427.14.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 18:40:53.0497 (UTC) FILETIME=[1BB7BE90:01CA0BC5] Cc: sip-ops@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] [sip-ops] I-D Action:draft-kuthan-dispatch-diagrevived-00.txt 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, 23 Jul 2009 18:43:01 -0000 On Fri, 2009-07-03 at 15:40 +0200, Victor Pascual Avila wrote: > A temporal URL for this Internet-Draft is: > http://www.ietf.org/proceedings/staging/draft-kuthan-dispatch-diagrevived-00.txt Now at http://www.ietf.org/id/draft-kuthan-dispatch-diagrevived-00.txt Dale From gonzalo.camarillo@ericsson.com Thu Jul 23 14:50:05 2009 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 68F513A6B03 for ; Thu, 23 Jul 2009 14:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 GOYKIUu2bmHY for ; Thu, 23 Jul 2009 14:50:04 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DAA293A67E6 for ; Thu, 23 Jul 2009 14:50:03 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-68-4a686a0d1fb5 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id A3.27.18827.D0A686A4; Thu, 23 Jul 2009 15:47:58 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:47:42 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:47:41 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 623772450; Thu, 23 Jul 2009 16:47:41 +0300 (EEST) Message-ID: <4A6869FD.2050604@ericsson.com> Date: Thu, 23 Jul 2009 16:47:41 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com><4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com><4A6576B9.4020504@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3425@GBNTHT12009MSX.gb002.siemens.net><4A65D27F.1060604@ericsson.com> <4A661564.9000008@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37AE@zrc2hxm0.corp.nortel.com> <4A66A239.4090806@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F1A37DC@zrc2hxm0.corp.nortel.com> <4A66AFF3.7040500@ericsson.com> <4A671D75.6000907@cisco.com> <4A683E6A.4040508@ericsson.com> <4A68677D.9010703@cisco.com> In-Reply-To: <4A68677D.9010703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 13:47:41.0702 (UTC) FILETIME=[2630DA60:01CA0B9C] X-Brightmail-Tracker: AAAAAA== Cc: Anders Kristensen , dispatch@ietf.org, Henry Sinnreich Subject: Re: [dispatch] Disaggregated Media in SIP 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, 23 Jul 2009 21:50:05 -0000 Hi Paul, yes, let's focus on the use cases and how they could be implemented. Cheers, Gonzalo Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: >> Hi Paul, >> >>> Nor have I seen any explanation of where the control resides that >>> initiates and coordinates the inclusion of multiple media sources >>> into call. *Something* must be capable of saying "I want device X to >>> join call Y using media Z". That is still a centralized point of >>> control even if it isn't directly in the resulting sip signaling >>> flow. Either it is using some exotic form of REFER to cause this to >>> happen, or else it is using some kind of private signaling. >> >> yes, you could use REFER as you suggest, although (as Francois also >> pointed out) I would remove the "using media Z" bit. When we designed >> REFER, we agreed not to include that type of stuff because applications >> typically know what to include based on the context in which the REFER >> is received. >> >> You could also use some type of private signalling if you want. There is >> nothing that precludes that. If you want to use your proprietary >> protocol for local coordination, you can do that. >> >>> Also, if a multimedia call is received by a UAS, and the UAS needs to >>> use disaggregated media to cope with the offered media types, how >>> will that work? Will some of the media be refused initially, and then >>> offered back in a new INVITE going in the reverse direction? >> >> Yes, this could be implemented like that. >> >>> There are a *lot* of details here that need to be worked out for this >>> approach to be functional. >> >> I would have loved to discuss all those details earlier (we submitted >> our first draft about this a long time ago) but folks did not want to >> even consider using something else than 3pcc. Once we agree that 3pcc is >> not the only way to do things, we can work out the details. > > I find the *use cases* interesting and worthy of discussing independent > of the mechanism used to achieve them. Either approach requires some > coordination among the disaggregated devices. With the 3pcc approach > there is the possibility of using sip to do the coordination, but its > still worth investigation since that may not provide the dieal user > experience. > > So I'm not really conceding that the proposed solution is necessary, or > even desirable to address the use cases. But I do think that > investigating the use cases is a good way to get beyond individual > opinions on the subject. > >> Note that when we introduced SIP more than 10 years ago many people did >> not like the fact that media was simply loosely coupled with the >> signalling. They wanted a tighter coupling... it seems we will have to >> go through similar discussions once more ;o) >> >> You wrote in another message: >> >>> All the more reason to ensure we agree on a goal set of use cases so >>> we can be sure there is a mechanism sufficiently rich to support them >>> without being unnecessarily complicated. Its no good to do something >>> simple if it doesn't solve a problem. >> >> Yes, agreeing on use cases would be great. That's why the draft has a >> section with use cases. Fell free to propose new ones or send comments >> on the existing ones. > > I didn't comment because I liked them. > > Thanks, > Paul From salvatore.loreto@ericsson.com Fri Jul 24 02:11:12 2009 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 7BC3C3A69EF for ; Fri, 24 Jul 2009 02:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 FmLMWbB+ze4p for ; Fri, 24 Jul 2009 02:11:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3D59A3A67FE for ; Fri, 24 Jul 2009 02:11:11 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-0a-4a697aae7bdd Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7B.87.00514.EAA796A4; Fri, 24 Jul 2009 11:11:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 11:11:03 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 11:11:03 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2788C245F; Fri, 24 Jul 2009 12:11:03 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E650321A07; Fri, 24 Jul 2009 12:11:02 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 695CA219CC; Fri, 24 Jul 2009 12:11:02 +0300 (EEST) Message-ID: <4A697AA5.4020603@ericsson.com> Date: Fri, 24 Jul 2009 12:11:01 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Dale Worley References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <1248372794.4427.11.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1248372794.4427.11.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Jul 2009 09:11:03.0346 (UTC) FILETIME=[AB367920:01CA0C3E] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Disaggregated Media in SIP 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, 24 Jul 2009 09:11:12 -0000 Dale Worley wrote: > On Tue, 2009-07-21 at 11:05 +0300, Gonzalo Camarillo wrote: > >> well, 3pcc is centralized because you have a (central) controller that >> is in control of all SIP signalling. If that controller leaves the >> session, the whole session disappears. An approach where several devices >> have their own SIP dialog with the remote devices is not centralized >> because you can remove any of them and the other sessions will remain >> unaffected. >> > > It's true that if the implementation is a single dialog, then the UA at > each end must remain in the call. For a UA to replace itself with > another UA would require a transfer-like process. > > The difficulty (under either implementation) is to transfer the "state" > information (which media stream goes to which destination) from one > controller to another. That need is obvious in the centralized > approach, but it seems to me that it would also be needed in the > decentralized approach. > the need or not to transfer the "state" really depends on how the decentralized approach will be designed. for example: In a "loosely coupled control" approach, as Francois is proposing, you don't have any "state" information that need to be transferred from one to another because you don't have a real controller. Another possibility would be to have a "fully distributed approach", where the "information state" does not reside in one single UA, but is in somehow spread among all the UAs involved in the disaggregate media. /Sal From pkyzivat@cisco.com Fri Jul 24 06:04:01 2009 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 2CCF23A6CC7 for ; Fri, 24 Jul 2009 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 50eQbCrvXosq for ; Fri, 24 Jul 2009 06:04:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F3F8B3A6CEA for ; Fri, 24 Jul 2009 06:03:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAORNaUqrR7MV/2dsb2JhbAC6JYglkGUFhA0 X-IronPort-AV: E=Sophos;i="4.43,264,1246838400"; d="scan'208";a="218678632" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Jul 2009 13:02:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6OD2sX1016419; Fri, 24 Jul 2009 06:02:54 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6OD2rGF019809; Fri, 24 Jul 2009 13:02:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 09:02:54 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 09:02:53 -0400 Message-ID: <4A69B0FD.20308@cisco.com> Date: Fri, 24 Jul 2009 09:02:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Salvatore Loreto References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <1248372794.4427.11.camel@victoria-pingtel-com.us.nortel.com> <4A697AA5.4020603@ericsson.com> In-Reply-To: <4A697AA5.4020603@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2009 13:02:53.0726 (UTC) FILETIME=[0E7203E0:01CA0C5F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2906; t=1248440574; x=1249304574; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20; bh=Vt6IGkxqG/iUcXqzmucQOrJ5XJdKoqV2LV/L0A7EcF4=; b=RJdA0Ylwg/scnFcWcuSu2ypxvVTKQuVWQmUBTVgjt80z1Ybtv8E/E/07lD Hq6N+PqITJTbe1zpFHzJwfj4a2noYRgTrur5uYR0y3dNrU4r7m5/uUgGwiTw 90EzsvZNcrCFC2+TnDlKGwmPQIZaC8T2MRVzOkiRFWQMGKHKDjUtA=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: DISPATCH Subject: Re: [dispatch] Disaggregated Media in SIP 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, 24 Jul 2009 13:04:56 -0000 Salvatore Loreto wrote: > Dale Worley wrote: >> On Tue, 2009-07-21 at 11:05 +0300, Gonzalo Camarillo wrote: >> >>> well, 3pcc is centralized because you have a (central) controller >>> that is in control of all SIP signalling. If that controller leaves >>> the session, the whole session disappears. An approach where several >>> devices have their own SIP dialog with the remote devices is not >>> centralized because you can remove any of them and the other sessions >>> will remain unaffected. >>> >> >> It's true that if the implementation is a single dialog, then the UA at >> each end must remain in the call. For a UA to replace itself with >> another UA would require a transfer-like process. >> >> The difficulty (under either implementation) is to transfer the "state" >> information (which media stream goes to which destination) from one >> controller to another. That need is obvious in the centralized >> approach, but it seems to me that it would also be needed in the >> decentralized approach. >> > the need or not to transfer the "state" really depends on how the > decentralized approach will be designed. > > for example: > In a "loosely coupled control" approach, as Francois is proposing, you > don't have any "state" information that > need to be transferred from one to another because you don't have a real > controller. I don't understand that. Suppose Alice calls Bob using her voice phone. Then she arranges for her laptop to join the call with Bob to add voice. (Bob has a video phone.) Then Bob decides to do a consultative transfer of the call to Charlie. Because Bob's phone is a video phone, its UI presumably treats this as a single call, even if there are actually two calls behind the scenes. So Bob first puts the call with Alice on hold. It already has to know to do this on two separate calls. Then it calls Charlie, who also has a video phone. So there is an audio+video call from Bob to Charlie. Then Bob asks to complete the transfer. What does it do? Normally it would send a REFER to Charlie's phone, asking it to do an INVITE/Replaces to Alice. But there are two calls to Alice. The "state" of the call, that it is distributed across two dialogs, is important info that needs to be transferred to Charlie given this implementation approach. With the "centralized" approach that state resides in Alice's realm and is of no concern to either Bob or Charlie. Thanks, Paul > Another possibility would be to have a "fully distributed approach", > where the "information state" does not reside > in one single UA, but is in somehow spread among all the UAs involved in > the disaggregate media. > > > /Sal > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From victor.pascual.avila@gmail.com Fri Jul 24 07:34:49 2009 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 483603A6B54; Fri, 24 Jul 2009 07:34:49 -0700 (PDT) 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 vd-BGFxVPNKw; Fri, 24 Jul 2009 07:34:48 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 224353A6778; Fri, 24 Jul 2009 07:34:47 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so449139eye.31 for ; Fri, 24 Jul 2009 07:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DFtDPW4g+taIwbnadW1leJ+zKVYoy+JkGwPaPLUXdh4=; b=KKlZRkSzvSKUim4/YYqHzmELcjgqQINpiszKxpAk2y6sT82IDBU8KGBufVxlRGr3eV tI3R5hCBZ+pWnTYoK0p8YbOtS+YYi6m9Yt/6DmTTqkfZHzfsaLxLxaRavTr64thhBx1J wsDLZAPtf5v7BS++j6cn94J/j130nNaqIk7vI= 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:content-transfer-encoding; b=na5S6BudtU8/UrUMkzlLyVifRBgn6AgS9SIwhF9963Dnq+0ZlcRvfXz/FZUNK6hu99 mCi+jOABhg2YZjwdIFhYqf11QmIutoEMyrxh2m1b9g2WRyHQnje3uWojTaa0rQAbUnlb LYI2FmaXR57Dq2pMmZE9dfRB5IGHgFSoBb4iE= MIME-Version: 1.0 Received: by 10.216.86.193 with SMTP id w43mr8146wee.17.1248446086138; Fri, 24 Jul 2009 07:34:46 -0700 (PDT) In-Reply-To: <1248374452.4427.14.camel@victoria-pingtel-com.us.nortel.com> References: <618e24240907030640k2898f908s450626af73dad5f8@mail.gmail.com> <1248374452.4427.14.camel@victoria-pingtel-com.us.nortel.com> Date: Fri, 24 Jul 2009 16:34:46 +0200 Message-ID: <618e24240907240734o78c758eds1578a27e9811ab00@mail.gmail.com> From: Victor Pascual Avila To: Dale Worley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-ops@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] [sip-ops] I-D Action:draft-kuthan-dispatch-diagrevived-00.txt 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, 24 Jul 2009 14:34:49 -0000 On Thu, Jul 23, 2009 at 8:40 PM, Dale Worley wrote: > On Fri, 2009-07-03 at 15:40 +0200, Victor Pascual Avila wrote: >> A temporal URL for this Internet-Draft is: >> http://www.ietf.org/proceedings/staging/draft-kuthan-dispatch-diagrevive= d-00.txt > > Now at http://www.ietf.org/id/draft-kuthan-dispatch-diagrevived-00.txt Thanks for the update, Dale. We would appreciate feedback as to whether this is helpful and going in the right direction, as well as detailed comments-- there are some open issues (Appendix B) that we would like to get discussed (Topology Hiding, Amount of troubleshooting information, Selective logging and B2BUA traversal). Cheers, --=20 Victor Pascual =C3=81vila From alan@sipstation.com Fri Jul 24 11:29:01 2009 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 42DA23A6880 for ; Fri, 24 Jul 2009 11:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 TewPkSYNUdYw for ; Fri, 24 Jul 2009 11:29:00 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 236C83A6813 for ; Fri, 24 Jul 2009 11:29:00 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MUPVs-000Hft-6y for dispatch@ietf.org; Fri, 24 Jul 2009 18:29:00 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/5L0yIbhUGL892TowWu6czi7oY2xWtIKk= Message-ID: <4A69FD6A.4020205@sipstation.com> Date: Fri, 24 Jul 2009 13:28:58 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 24 Jul 2009 18:29:01 -0000 Here are my comments on this draft. Overall, I think this draft is an excellent start at the requirements for this important topic. I look forward to future discussions of charter text so we can get started on the work. Section 2: " Another, related IETF draft is draft-wing-sipping-srtp-key [I-D.wing-sipping-srtp-key], which describes an approach for providing SRTP session keys to a recorder-type server. That draft focuses on the mechanism to provide the SRTP session key, rather than the mechanism to invoke and sustain recording sessions themselves." draft-wing-sipping-srtp-key actually has a lot of discussion, including call flows showing how recording sessions can be established. Also, this document has four recording modes discussed, which I think should be discussed in this document. Two are mentioned without really explaining them, and two others are implied by various requirements. Section 3: " Recording Session: The session created between an RC and RS for the purpose of recording a Recorded Session. The Recorded Session may itself be based on SIP, but it is a separate session from the Recording Session. Recorded Session: A session created between a UAC and UAS that is recorded by the RC and RS systems." These two terms only differ by their tense, yet I think one refers to a signaling session and the other refers to a media session. If so, better terms and definitions are needed. If not, we need a term for the actual recorded media. Also, there are (at least) two sessions here - the one between the UAs and the Recording Session - in a few places I suspect the two are being confused. " Dynamic Recording: Dynamic recording is a mode of recording where the recording sessions are established on an as needed basis. The length of these sessions is typically same as the length of the actual media sessions. Persistent Recording: Persistent recording is a mode of recording where the recording sessions are established at system start-up and kept-alive from that point on. The length of these sessions is independent from the length of the actual recorded media sessions. Persistent recording sessions avoid issues such as media clipping that can occur due to delays in recording session establishment." These terms need more explanation as I can think of multiple things they might mean. For example, when you say "session" do you mean a signaling session or media session? When you talk about avoiding media clipping, do you mean that media is always sent by the RC to the RS regardless of whether there is any media? Figures could use Figure numbers and labels. Also, it would be worth showing which is the RC and which is the RS in them. Section 5 " o REQ-001 The mechanism MUST support the ability to perform persistent (always-on) or dynamic (on-demand) Recording Sessions." I'm not sure that the Persistent and Dynamic Recording as defined above correspond to the Always On and On Demand modes defined in http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4. " o REQ-002 The mechanism MUST support the ability to perform persistent Recording Sessions, such that the connection and attributes of media in the Recording Session are not dynamically signaled for each Recorded Session before it can be recorded. Call details and metadata will still be signaled, but can be post- correlated to the recorded media. There will still need to be a means of correlating the recorded media connection/packets to the Recorded Session, however this may be on a permanent filter-type basis, such as based on a SIP AoR of an agent that is always recorded, or based on identifiers in the recorded media itself." Without fully understanding Persistent Recording, I can't evaluate this requirement. " o REQ-009 The mechanism MUST support the ability to deliver mixed media streams to the RS. The RS MAY be informed about the composition of the mixed streams through session metadata. Note: A mixed media stream is where several recorded sessions are carried in a single recording session. A mixed media stream is typically produced by a mixer function." I'm not clear what mixed media means here - does it mean a mix of media types - synchronized audio and video from the same session, or do you mean multiple media streams from different sessions? The note seems to indicate that this relates only to a conference call where multiple sources (SSRCs) have been combined into a single RTP session. " o REQ-013 The mechanism MUST support the ability to inject tones into the Recorded Session either from the RS or from the RC." Recorded Session seems to be defined as the media between the RC and RS. Is that where the injected tones should be? Or should then be mixed in the media between the two UAs? " o REQ-021 The mechanism MUST support the ability for the RC to only perform media replication to the RS, without needing to decode or mix audio/video/etc., and without needing to be an RTP agent. This will allow the RC to replicate media at layers below RTP. Clearly, such an RC mode would not be able to provide transcoding, or media injection from the RS back into the Recorded Session." Does this mean that you think that RTP is unsuitable for transporting media between the RS and RC? Clearly it isn't for IM, but I would think that many of the functions of RTP are needed for audio and video media. To understand this requirement will take more discussion. Thanks, Alan From dean.willis@softarmor.com Sat Jul 25 01:58:13 2009 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 BE35628C16F for ; Sat, 25 Jul 2009 01:58:13 -0700 (PDT) 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 cJ4pwzsZ8vrx for ; Sat, 25 Jul 2009 01:58:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E66733A6A93 for ; Sat, 25 Jul 2009 01:58:12 -0700 (PDT) Received: from [78.64.69.187] (host-78-64-69-187.homerun.telia.com [78.64.69.187]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6P8w98u019448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Jul 2009 03:58:12 -0500 Message-ID: <4A6AC91F.6030804@softarmor.com> Date: Sat, 25 Jul 2009 03:58:07 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Alan Johnston References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> In-Reply-To: <4A685DC9.9080209@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 25 Jul 2009 08:58:13 -0000 Alan Johnston wrote: > John, > > Thanks for your comments. Transfers means the ability to pass UUI in a > Refer-To URI in a REFER. So, IF we had a way to pass user-to-user parameters in a request URI, then we would not need a specialized mechanism for UUI. We have an effort underway to learn how to pass parameters, but people keep getting confused about why we need it. So here's a question: Can we solve the UUI case using History Info? If so, then we're basically done; we just need to register a standard parameter for UUI. If not, then I argue that History-Info is not an adequate method for parameter preservation end-to-end, and we need to revisit that solution. In absolutely no case should we be developing yet another application-specific SIP extension header for CC-UUI. The application is NOT part of the signaling. -- Dean From drage@alcatel-lucent.com Sat Jul 25 02:37:38 2009 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 ED02D28C1DC for ; Sat, 25 Jul 2009 02:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 US06oRZuOMuu for ; Sat, 25 Jul 2009 02:37:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id EFB1528C100 for ; Sat, 25 Jul 2009 02:37:37 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6P9bbCH015814 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 25 Jul 2009 11:37:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 25 Jul 2009 11:37:37 +0200 From: "DRAGE, Keith (Keith)" To: Dean Willis , Alan Johnston Date: Sat, 25 Jul 2009 11:37:43 +0200 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoNBg8bV8RbrPf1RK6yNTFINUlF3QABJp7w Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> In-Reply-To: <4A6AC91F.6030804@softarmor.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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 25 Jul 2009 09:37:39 -0000 At the higher level I think the semantics of this line of reasoning are bro= ken. Surely, the overall requirement is that in certain forms of transfer, the U= UI that went to the original called user should be delivered to the transfe= rred user. Like a number of headers, this is information that the calling u= ser put in the package because he wanted them delivered to the final destin= ation. That has nothing to do with recording the Request-URI of the calling user, = which is what I believe the semantics of the History-Info relate to. That i= s because it has nothing to do with the Request-URI in the first place. Sur= ely we place URI parameters in the Request-URI because they are something t= o do with the URI therein contained. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Saturday, July 25, 2009 9:58 AM > To: Alan Johnston > Cc: dispatch@ietf.org > Subject: [dispatch] CCUS and History-Info (was Proposed=20 > Charter for CCUS - Call Control UUI for SIP) >=20 > Alan Johnston wrote: > > John, > >=20 > > Thanks for your comments. Transfers means the ability to=20 > pass UUI in=20 > > a Refer-To URI in a REFER. >=20 > So, IF we had a way to pass user-to-user parameters in a=20 > request URI, then we would not need a specialized mechanism for UUI. >=20 > We have an effort underway to learn how to pass parameters,=20 > but people keep getting confused about why we need it. >=20 > So here's a question: Can we solve the UUI case using History=20 > Info? If so, then we're basically done; we just need to=20 > register a standard parameter for UUI. If not, then I argue=20 > that History-Info is not an adequate method for parameter=20 > preservation end-to-end, and we need to revisit that solution. >=20 > In absolutely no case should we be developing yet another=20 > application-specific SIP extension header for CC-UUI. The=20 > application is NOT part of the signaling. >=20 > -- > Dean >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From alan@sipstation.com Sat Jul 25 07:46:54 2009 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 3AD0D3A68D6 for ; Sat, 25 Jul 2009 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 n6nZ07OKL3kN for ; Sat, 25 Jul 2009 07:46:53 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 579DB3A69B3 for ; Sat, 25 Jul 2009 07:46:53 -0700 (PDT) Received: from 24-107-145-15.dhcp.stls.mo.charter.com ([24.107.145.15] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MUiV5-000K5R-Pl; Sat, 25 Jul 2009 14:45:28 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.145.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/GOF/a9oBLb1pRN+ZrJ3zQWFjhTBEQOYM= Message-ID: <4A6B1A84.2060505@sipstation.com> Date: Sat, 25 Jul 2009 09:45:24 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dean Willis References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> In-Reply-To: <4A6AC91F.6030804@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 25 Jul 2009 14:46:54 -0000 Dean, Thanks for your comments. We did consider URI parameters as a mechanism. If we used this approach, we would still need SIP extensions for those URI parameters and a new SIP option tag to indicate support for it. As such, we'd still need a mechanism to be standardized. I think in DISPATCH we are supposed to be discussing scope and charter text, and I think the current charter text is mechanism agnostic, so this approach would still be covered, correct? In terms of History-Info, I don't think we've considered that before. There were two problems with the URI parameters. One was the retargeting problem but the other is semantics. Last time I read RFC 3261, the Request-URI contained information about the destination resource, and sometimes information about the next hop to that resource. To put user-to-user data about the originator in the request into the Request-URI seems like a big change to SIP semantics that we'd need to think carefully about before diving into. We would definitely need a SIP option tag to say that we are reversing the meaning of Request-URI. As for History-Info, it doesn't feel very right - how is UUI history about the call? If anything, it is future information about the call. Also, wouldn't every proxy that might retarget in the path have to support it, or the UUI would be lost? If so, we'd need to use Proxy-Require: history which is both ugly and not permitted by RFC 4244. Anyway, I look forward to more mechanism discussions in the future, but for now lets focus on the charter discussions. Thanks, Alan Dean Willis wrote: > Alan Johnston wrote: > >> John, >> >> Thanks for your comments. Transfers means the ability to pass UUI in a >> Refer-To URI in a REFER. >> > > So, IF we had a way to pass user-to-user parameters in a request URI, > then we would not need a specialized mechanism for UUI. > > We have an effort underway to learn how to pass parameters, but people > keep getting confused about why we need it. > > So here's a question: Can we solve the UUI case using History Info? If > so, then we're basically done; we just need to register a standard > parameter for UUI. If not, then I argue that History-Info is not an > adequate method for parameter preservation end-to-end, and we need to > revisit that solution. > > In absolutely no case should we be developing yet another > application-specific SIP extension header for CC-UUI. The application is > NOT part of the signaling. > > -- > Dean > > > From HKaplan@acmepacket.com Sat Jul 25 13:27:45 2009 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 A91523A6949 for ; Sat, 25 Jul 2009 13:27:45 -0700 (PDT) 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=[AWL=0.000, 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 4WETkR9jKjQQ for ; Sat, 25 Jul 2009 13:27:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BCC653A6B69 for ; Sat, 25 Jul 2009 13:27:44 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 25 Jul 2009 16:27:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 25 Jul 2009 16:27:43 -0400 From: Hadriel Kaplan To: Alan Johnston , Dean Willis Date: Sat, 25 Jul 2009 16:27:42 -0400 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoNNs/skJ0vOWKORXKHnVa/+eTobwALJ6Vw Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> In-Reply-To: <4A6B1A84.2060505@sipstation.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@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 25 Jul 2009 20:27:45 -0000 I think the retargeting and middlebox support issues are not really germane= as it pertains to H-I. H-I records the req-uri's even through retargeting= , so the UUI would be available to the UAS. And it would survive even if P= roxies don't support H-I, because the first UAC can insert the first H-I of= the req-uri, which would simply be mandated for UUI-supporting UAC's if we= went that way.=20 But the real problem is the semantics as you say - to me a request URI is i= nformation about the targeted resource or how to reach it, not information = about the source resource. Since H-I is just a list of req-uri's, it's not= the right place. Really the technically *right* place would be in MIME, afaict - it's opaque= application data just like geoloc, right? But pragmatically, the issues/p= roblems with doing it in MIME were already covered and debated in sipping, = and iirc consensus was: put it in a header. ISTM that we always complain about lack of running code, and here we have a= case where there is running code from multiple vendors, and it's not funda= mentally broken/un-sound. It ain't broken, why do we need to fix it? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Alan Johnston > Sent: Saturday, July 25, 2009 10:45 AM >=20 > In terms of History-Info, I don't think we've considered that before. > There were two problems with the URI parameters. One was the > retargeting problem but the other is semantics. Last time I read RFC > 3261, the Request-URI contained information about the destination > resource, and sometimes information about the next hop to that > resource. To put user-to-user data about the originator in the request > into the Request-URI seems like a big change to SIP semantics that we'd > need to think carefully about before diving into. We would definitely > need a SIP option tag to say that we are reversing the meaning of > Request-URI. >=20 > As for History-Info, it doesn't feel very right - how is UUI history > about the call? If anything, it is future information about the call. > Also, wouldn't every proxy that might retarget in the path have to > support it, or the UUI would be lost? If so, we'd need to use > Proxy-Require: history which is both ugly and not permitted by RFC 4244. >=20 > Anyway, I look forward to more mechanism discussions in the future, but > for now lets focus on the charter discussions. From drage@alcatel-lucent.com Sat Jul 25 16:01:49 2009 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 D597F3A696C for ; Sat, 25 Jul 2009 16:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 7DZa8WMz0TET for ; Sat, 25 Jul 2009 16:01:48 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 0EF633A6BB1 for ; Sat, 25 Jul 2009 16:01:47 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6PN1JBJ031833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 26 Jul 2009 01:01:19 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 26 Jul 2009 01:01:19 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Sun, 26 Jul 2009 01:01:19 +0200 Thread-Topic: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt Thread-Index: Acn8N8CR3o6MhHXQRNq+YYy2s+dgIARIihAA Message-ID: References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com> <4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com> In-Reply-To: <4A4E96B1.1080005@cisco.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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 25 Jul 2009 23:01:49 -0000 Just to respond to this bit of the message: > > Not quite. We are not making the assumption that both are=20 > gateways,=20 > > although that is possible. Most likely, one element is SIP enabled. > > However, it is not a fully intelligent SIP endpoint - the basic=20 > > software and application (probably many years old) is=20 > unchanged but a=20 > > SIP interface (SIP trunk) has been added. As such, the SIP=20 > stack does=20 > > not know anything about the UUI as it is implementing=20 > exactly the ISDN=20 > > UUI service - the information is just pushed up the stack=20 > to another=20 > > application, and this application knows nothing about SIP. =20 > It still=20 > > thinks it is using an ISDN trunk. >=20 > Then in the way I meant the question, both ends *are* gateways. >=20 > But then if someone wishes to build native sip gear to plug=20 > into this environment, then it will still have to understand=20 > this isdn encoding.=20 > Perhaps that is the cruel truth, unless all the equipment is=20 > replaced at once.=20 I've said this before and I'll say it again. The bit being delivered to the= end UE is not "isdn encoding". If it was ISDN encoding, then the ISDN / SI= P gateway would be able to interpret it and map it into SIP. Rather it is s= ome application sitting above the ISDN call control layer in the calling te= rminal, which is wishing to communicate with its peer application running i= n the destination SIP UA, or gateway. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Saturday, July 04, 2009 12:39 AM > To: Alan Johnston > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D=20 > Action:draft-johnston-sipping-cc-uui-08.txt >=20 > Hi Alan, >=20 > responses inline. I've trimmed out the parts that don't=20 > require more discussion. >=20 > Thanks, > Paul >=20 > Alan Johnston wrote: > > Paul, > >=20 > > Thanks for your comments. See mine below. > >=20 > > Thanks, > > Alan > >=20 > > Paul Kyzivat wrote: > >> Hi Alan, > >> > >> I took a quick look at this doc and the requirements doc=20 > as well. I=20 > >> have a few thoughts: > >> > >> From section 1: > >> > >>> In the future, where both endpoints are intelligent=20 > SIP user agents, > >>> it may be possible for them to understand and=20 > interpret the UUI data. > >>> There may be some cases where the UUI information is=20 > relevant to SIP. > >>> In this case, it might be worthwhile attempting to map=20 > UUI data to an > >>> appropriate SIP header field or to standardize a new=20 > header field. > >>> However, the requirements and use cases for this are=20 > different enough > >>> from those described in this document that these two situations > >>> should be examined separately. This document looks only at the > >>> requirements and mechanisms for replicating the=20 > existing, widely used > >>> and deployed ISDN UUI service. > >> > >> This *still* troubles me! > >> Is the assumption here that *both* the UAC and UAS are=20 > gateways, so=20 > >> that this mechanism is solely for the tunneling of Q.931 and Q.763=20 > >> UUI message over SIP? > >> > >> I get the impression that an important use case is where at least > >> *one* end (probably the UAS) is a SIP device. In that case it will=20 > >> already be *necessary* for it to understand and interpret UUI data. > >> And where there is redundancy between SIP data and the UUI=20 > data, it=20 > >> will need to resolve the discrepancy. > >=20 > > Not quite. We are not making the assumption that both are=20 > gateways,=20 > > although that is possible. Most likely, one element is SIP enabled. > > However, it is not a fully intelligent SIP endpoint - the basic=20 > > software and application (probably many years old) is=20 > unchanged but a=20 > > SIP interface (SIP trunk) has been added. As such, the SIP=20 > stack does=20 > > not know anything about the UUI as it is implementing=20 > exactly the ISDN=20 > > UUI service - the information is just pushed up the stack=20 > to another=20 > > application, and this application knows nothing about SIP. =20 > It still=20 > > thinks it is using an ISDN trunk. >=20 > Then in the way I meant the question, both ends *are* gateways. >=20 > But then if someone wishes to build native sip gear to plug=20 > into this environment, then it will still have to understand=20 > this isdn encoding.=20 > Perhaps that is the cruel truth, unless all the equipment is=20 > replaced at once. >=20 > >>> 5. Syntax for UUI Header Field > >> ... > >>> UUI =3D "User-to-User" HCOLON uui-data=20 > *(SEMI uui-param) > >>> uui-data =3D token > >>> uui-param =3D enc-param | cont-param | purp-param=20 > | generic-param > >>> enc-param =3D "encoding=3D" ("hex" | token) > >>> cont-param =3D "content=3D" ("isdn-uui" | token) > >>> purp-param =3D "purpose=3D" ("isdn-interwork" | token) > >> > >> At the very least, I would request that this be expanded a=20 > little bit=20 > >> for future flexibility, by permitting the uui-data to be either a=20 > >> token or a string. While the encoding you have chosen works as a=20 > >> token, other encodings may need the additional flexibility=20 > of a string. > >> > >> uui-data =3D token | quoted-string > >=20 > > OK, I guess I'm OK with that. For the isdn-interwork=20 > purpose, we'll=20 > > require the token, but other applications could utilize the=20 > quoted string. >=20 > I would hope that when the token encoding is sufficient, then=20 > either form would be accepted. Or it would perhaps be ok to=20 > specify for a particular encoding (hex) that the token=20 > encoding must be used. I don't see how the purpose has=20 > anything to do with it. >=20 > >>> 6.3. Registration of SIP Option Tag > >> > >> This section registers the new option tag. But I find=20 > almost nothing=20 > >> that defines the semantics of the option. (Section 5 does=20 > include the > >> following: > >> > >>> A UA that supports this feature and the "uui" option=20 > tag MUST support > >>> the call flows in [johnston-dispatch-sip-cc-uui]... > >> > >> but that is pretty thin from a normative perspective. > >> > >> Of particular note, does support for the option tag mean=20 > support for=20 > >> the particular encoding, content, and purpose included in this=20 > >> document? Or does it only mean support for the header and=20 > params in=20 > >> the abstract? (That wouldn't be very useful.) > >=20 > > Yes, this needs clarification. I'd suggest we define the=20 > option tag=20 > > to be uui-isdn which means it understands the header field and the=20 > > isdn-interwork purpose, and the call flows, including escaping into=20 > > redirection and Refer-To URIs. >=20 > I'd like to hear some other opinions on whether to have tag=20 > per param for tag, or a tag for the combination of param=20 > values. I think I'm ok with what you propose. >=20 > >> I don't see how it can mean support for some other yet to=20 > be defined=20 > >> values for those. Yet if it only means support for the=20 > current ones,=20 > >> then how will one indicate support for future ones? > >> > >> The only way out of this that I can see is to have=20 > separate options,=20 > >> either for particular values of each parameter, or for particular=20 > >> combinations of values of all the parameters. > >=20 > > New applications using this header field would have the option of=20 > > defining a new SIP option tag which would mean support for=20 > the header=20 > > field and their new purpose. > >=20 > >> So you might have options uui-purpose-isdn-interwork,=20 > >> uui-content-isdn, and uui-encoding-hex. Or you might just=20 > have option=20 > >> uui-isdn-interwork that means the combination. > >=20 > > I think the latter. I see it as a hierarchy - the application or=20 > > purpose is the top one. Each purpose has a number of=20 > contents that it=20 > > supports. Each content has a number of encoding schemes it=20 > supports. >=20 > I guess I'm ok with that, pending nailing down the definition=20 > of "purpose". >=20 > >> I also am not finding much explanation of the semantics of the=20 > >> content and purpose parameters. I can only extrapolate=20 > from a single=20 > >> example of each, which I'm having trouble doing. > >> > >> I'm guessing that 'content' must refer to the precise=20 > syntax of the=20 > >> contained data, after decoding. So presumably it must map=20 > onto some=20 > >> particular spec. For isdn-uui, would that be [Q931] or=20 > [Q763]? If so,=20 > >> shouldn't it refer to something specific in that document? > >=20 > > Not really. In this case, isdn-uui effectively means "opaque data"=20 > > which is how ISDN defines the UUI - it is completely undefined,=20 > > necessarily so by the strict layering used in the ISDN application. >=20 > I don't believe you! >=20 > If that is the case, then the UAC and UAS must have a private=20 > side agreement about what the isdn-uui content means. Is that=20 > really what you mean? >=20 > You already state that the first byte is a protocol=20 > discriminator. There must also be something, somewhere, that=20 > specifies the mapping from a particular value for that byte=20 > to a particular protocol/format. If there is, then that=20 > should be part of the definition of this content. >=20 > >> 'purpose' is even less clear to me. Does it refer to why=20 > it is being=20 > >> included? Or what is to be done with it? If received by a=20 > UA that is=20 > >> not an ISDN gateway, how can it decide if this is=20 > something it should=20 > >> be trying to process? Is it still ISDN interworking if neither the=20 > >> UAC nor UAS is connected to an ISDN network? > >=20 > > The purpose is the application using the UUI. Others have=20 > expressed=20 > > an interest in carrying other data in the header field, in=20 > which case=20 > > a new purpose would be defined. I'll see if I can think of=20 > an example one. >=20 > So are you saying that a particular call center application=20 > might constitute a distinct "purpose"? >=20 > > Basically, if two UAs both support the header but have different=20 > > applications generating and consuming the UUI, it will not=20 > work. This=20 > > is not a SIP failure, and there is nothing SIP can do about=20 > it. But=20 > > this purpose header field allows the UAs to detect this condition. >=20 > In that case, perhaps "isdn-interwork" isn't really a single=20 > purpose at all, unless any two pieces of equipment that=20 > support that purpose can then interwork without knowing any=20 > more about each other. >=20 > >> Suppose I was developing a sophisticated UA that=20 > potentially might be=20 > >> usable by a call center operator. How should=20 > purpose=3Disdn-interwork=20 > >> affect the operation of this device? > >=20 > > To make it work in today's contact center applications, supporting=20 > > isdn-interwork would likely make it work in an application,=20 > provided=20 > > the appropriate call center application also ran on it. =20 > Some contact=20 > > centers do not use ISDN UUI, instead they use all kinds of really,=20 > > really ugly CTI protocols running in parallel. >=20 > Yes, I know! :-( >=20 > > This is a way of moving > > those to the ISDN model, and from there to a more=20 > intelligent endpoint=20 > > SIP model. > >=20 > >> Thanks, > >> Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From Leon.Portman@nice.com Sat Jul 25 19:10:13 2009 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 1F7933A69E6 for ; Sat, 25 Jul 2009 19:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 Gw2cQx50vsEk for ; Sat, 25 Jul 2009 19:10:12 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 4DC2A3A6A0A for ; Sat, 25 Jul 2009 19:10:11 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Sun, 26 Jul 2009 05:10:09 +0300 From: Leon Portman To: Alan Johnston , "dispatch@ietf.org" Date: Sun, 26 Jul 2009 05:10:08 +0300 Thread-Topic: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppw Message-ID: <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> References: <4A69FD6A.4020205@sipstation.com> In-Reply-To: <4A69FD6A.4020205@sipstation.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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: Sun, 26 Jul 2009 02:10:13 -0000 Alan, Hi Thanks for the comments. Please see below my answers Regards Leon -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Alan Johnston Sent: Friday, July 24, 2009 9:29 PM To: dispatch@ietf.org Subject: [dispatch] Comments on draft-jain-dispatch-session-recording-proto= col-req-00 Here are my comments on this draft. Overall, I think this draft is an excellent start at the requirements=20 for this important topic. I look forward to future discussions of=20 charter text so we can get started on the work. Section 2: " Another, related IETF draft is draft-wing-sipping-srtp-key [I-D.wing-sipping-srtp-key], which describes an approach for providing SRTP session keys to a recorder-type server. That draft focuses on the mechanism to provide the SRTP session key, rather than the mechanism to invoke and sustain recording sessions themselves." draft-wing-sipping-srtp-key actually has a lot of discussion, including=20 call flows showing how recording sessions can be established. Also,=20 this document has four recording modes discussed, which I think should=20 be discussed in this document. Two are mentioned without really=20 explaining them, and two others are implied by various requirements. [LeonP] Yes, for the protocol draft, we will need to combine all of the app= roaches and make sure that we covered all use cases Section 3: " Recording Session: The session created between an RC and RS for the purpose of recording a Recorded Session. The Recorded Session may itself be based on SIP, but it is a separate session from the Recording Session. Recorded Session: A session created between a UAC and UAS that is recorded by the RC and RS systems." These two terms only differ by their tense, yet I think one refers to a=20 signaling session and the other refers to a media session. If so,=20 better terms and definitions are needed. If not, we need a term for the=20 actual recorded media. Also, there are (at least) two sessions here -=20 the one between the UAs and the Recording Session - in a few places I=20 suspect the two are being confused.=20 [LeonP] Actually Recording Session relates to both SIP and Media that is fo= rked to the recording server and Recorded Session is actually the original = conversation between two UAs. These two are exactly the two sessions that y= ou are describing. " Dynamic Recording: Dynamic recording is a mode of recording where the recording sessions are established on an as needed basis. The length of these sessions is typically same as the length of the actual media sessions. Persistent Recording: Persistent recording is a mode of recording where the recording sessions are established at system start-up and kept-alive from that point on. The length of these sessions is independent from the length of the actual recorded media sessions. Persistent recording sessions avoid issues such as media clipping that can occur due to delays in recording session establishment." These terms need more explanation as I can think of multiple things they=20 might mean. For example, when you say "session" do you mean a signaling=20 session or media session? When you talk about avoiding media clipping,=20 do you mean that media is always sent by the RC to the RS regardless of=20 whether there is any media?=20 [LeonP] Yes, by session we mean both legs: signaling and media. And in Pers= istent Recording mode, the Recording SIP session supposed to stay connected= even there is not actual connected sessions for the specific recorded UA.= =20 Figures could use Figure numbers and labels. Also, it would be worth=20 showing which is the RC and which is the RS in them. Section 5 " o REQ-001 The mechanism MUST support the ability to perform persistent (always-on) or dynamic (on-demand) Recording Sessions." I'm not sure that the Persistent and Dynamic Recording as defined above=20 correspond to the Always On and On Demand modes defined in=20 http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4. [LeonP] It is different in the way that the Recording Session is establishe= d only once during initialization (or login events) and then only media is = forwarded per each call in order to minimize the clipping. " o REQ-002 The mechanism MUST support the ability to perform persistent Recording Sessions, such that the connection and attributes of media in the Recording Session are not dynamically signaled for each Recorded Session before it can be recorded. Call details and metadata will still be signaled, but can be post- correlated to the recorded media. There will still need to be a means of correlating the recorded media connection/packets to the Recorded Session, however this may be on a permanent filter-type basis, such as based on a SIP AoR of an agent that is always recorded, or based on identifiers in the recorded media itself." Without fully understanding Persistent Recording, I can't evaluate this=20 requirement.=20 " o REQ-009 The mechanism MUST support the ability to deliver mixed media streams to the RS. The RS MAY be informed about the composition of the mixed streams through session metadata. Note: A mixed media stream is where several recorded sessions are carried in a single recording session. A mixed media stream is typically produced by a mixer function." I'm not clear what mixed media means here - does it mean a mix of media=20 types - synchronized audio and video from the same session, or do you=20 mean multiple media streams from different sessions? The note seems to=20 indicate that this relates only to a conference call where multiple=20 sources (SSRCs) have been combined into a single RTP session. [LeonP] It is specific trading floor environment requirements where multip= le handset and speakers for specific turrets will be mixed on the turret le= vel for recording by one recording channel. " o REQ-013 The mechanism MUST support the ability to inject tones into the Recorded Session either from the RS or from the RC." Recorded Session seems to be defined as the media between the RC and=20 RS. Is that where the injected tones should be? Or should then be=20 mixed in the media between the two UAs? [LeonP] we have multiple options here. Preferable solution that one of the = UAs will inject them (triggered by policy or parameters in SRP), but there = are also configuration where RS will be required to create them and send ba= ck to RC (like talking clock for example) " o REQ-021 The mechanism MUST support the ability for the RC to only perform media replication to the RS, without needing to decode or mix audio/video/etc., and without needing to be an RTP agent. This will allow the RC to replicate media at layers below RTP. Clearly, such an RC mode would not be able to provide transcoding, or media injection from the RS back into the Recorded Session." Does this mean that you think that RTP is unsuitable for transporting=20 media between the RS and RC? Clearly it isn't for IM, but I would think=20 that many of the functions of RTP are needed for audio and video media. =20 To understand this requirement will take more discussion. [LeonP] Actually it was Hadriel requirement. I believe it only means that R= C does not required to implement RTP stack, it can just fork RTP packets on= the network level (by hardware) Thanks, Alan _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gonzalo.camarillo@ericsson.com Sun Jul 26 04:22:12 2009 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 BAB663A69E5 for ; Sun, 26 Jul 2009 04:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.233 X-Spam-Level: X-Spam-Status: No, score=-5.233 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 shf8RvUIHhcL for ; Sun, 26 Jul 2009 04:22:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B3B013A68C1 for ; Sun, 26 Jul 2009 04:22:11 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-30-4a6c3c632a7c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F4.A2.00514.36C3C6A4; Sun, 26 Jul 2009 13:22:11 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Jul 2009 13:22:11 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Jul 2009 13:22:10 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9119C245F; Sun, 26 Jul 2009 14:22:10 +0300 (EEST) Message-ID: <4A6C3C62.6050006@ericsson.com> Date: Sun, 26 Jul 2009 14:22:10 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A6450D6.90904@ericsson.com> <4A646F12.8070000@cisco.com> In-Reply-To: <4A646F12.8070000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2009 11:22:11.0121 (UTC) FILETIME=[51992A10:01CA0DE3] X-Brightmail-Tracker: AAAAAA== Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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: Sun, 26 Jul 2009 11:22:12 -0000 Hi, > I guess the one way I could buy into your "distributed" approach is to > simply model it as a conference, where the focus is at one "end". But I > think we discussed that once. that is how it is modeled when only one of the ends is distributed. What we discussed was that the semantics of join were intended for conferences and that even though this was very similar, it was not the same thing... but the model is valid. Cheers, Gonzalo From AUDET@nortel.com Mon Jul 27 00:12:57 2009 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 A89BD3A69A0 for ; Mon, 27 Jul 2009 00:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 VD2Siz01yC7w for ; Mon, 27 Jul 2009 00:12:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 965A43A698F for ; Mon, 27 Jul 2009 00:12:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6R7B4k09420; Mon, 27 Jul 2009 07:11:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 02:12:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F2A647E@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) thread-index: AcoNNs/skJ0vOWKORXKHnVa/+eTobwALJ6VwAEmLugA= References: <4A6740CD.3070609@sipstation.com><0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net><4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com><4A6B1A84.2060505@sipstation.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Alan Johnston" , "Dean Willis" Cc: dispatch@ietf.org Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 07:12:57 -0000 I agree with both Alan and Hadriel.=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Saturday, July 25, 2009 13:28 > To: Alan Johnston; Dean Willis > Cc: dispatch@ietf.org > Subject: Re: [dispatch] CCUS and History-Info (was Proposed=20 > Charter for CCUS - Call Control UUI for SIP) >=20 >=20 > I think the retargeting and middlebox support issues are not=20 > really germane as it pertains to H-I. H-I records the=20 > req-uri's even through retargeting, so the UUI would be=20 > available to the UAS. And it would survive even if Proxies=20 > don't support H-I, because the first UAC can insert the first=20 > H-I of the req-uri, which would simply be mandated for=20 > UUI-supporting UAC's if we went that way.=20 >=20 > But the real problem is the semantics as you say - to me a=20 > request URI is information about the targeted resource or how=20 > to reach it, not information about the source resource. =20 > Since H-I is just a list of req-uri's, it's not the right place. >=20 > Really the technically *right* place would be in MIME, afaict=20 > - it's opaque application data just like geoloc, right? But=20 > pragmatically, the issues/problems with doing it in MIME were=20 > already covered and debated in sipping, and iirc consensus=20 > was: put it in a header. >=20 > ISTM that we always complain about lack of running code, and=20 > here we have a case where there is running code from multiple=20 > vendors, and it's not fundamentally broken/un-sound. It=20 > ain't broken, why do we need to fix it? >=20 > -hadriel >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On=20 > > Behalf Of Alan Johnston > > Sent: Saturday, July 25, 2009 10:45 AM > >=20 > > In terms of History-Info, I don't think we've considered=20 > that before. > > There were two problems with the URI parameters. One was the=20 > > retargeting problem but the other is semantics. Last time=20 > I read RFC=20 > > 3261, the Request-URI contained information about the destination=20 > > resource, and sometimes information about the next hop to that=20 > > resource. To put user-to-user data about the originator in the=20 > > request into the Request-URI seems like a big change to SIP=20 > semantics=20 > > that we'd need to think carefully about before diving into.=20 > We would=20 > > definitely need a SIP option tag to say that we are reversing the=20 > > meaning of Request-URI. > >=20 > > As for History-Info, it doesn't feel very right - how is=20 > UUI history=20 > > about the call? If anything, it is future information=20 > about the call. > > Also, wouldn't every proxy that might retarget in the path have to=20 > > support it, or the UUI would be lost? If so, we'd need to use > > Proxy-Require: history which is both ugly and not permitted=20 > by RFC 4244. > >=20 > > Anyway, I look forward to more mechanism discussions in the future,=20 > > but for now lets focus on the charter discussions. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From alan@sipstation.com Mon Jul 27 01:07:48 2009 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 3258D3A6C0D for ; Mon, 27 Jul 2009 01:07:48 -0700 (PDT) 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 Z6hMjmAPw7UW for ; Mon, 27 Jul 2009 01:07:46 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id AEB673A6BF8 for ; Mon, 27 Jul 2009 01:07:46 -0700 (PDT) Received: from dhcp-1367.meeting.ietf.org ([130.129.19.103]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MVLFL-0002ZR-3d; Mon, 27 Jul 2009 08:07:47 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.19.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19PlqHSPJ3uFP3lcyPGLY6kEgtqi39gzBA= Message-ID: <4A6D6050.7060803@sipstation.com> Date: Mon, 27 Jul 2009 03:07:44 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Leon Portman References: <4A69FD6A.4020205@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 27 Jul 2009 08:07:48 -0000 Leon, Thanks for your replies - see a few comments below. Thanks, Alan Leon Portman wrote: > Alan, Hi > > Thanks for the comments. > > Please see below my answers > > Regards > > Leon > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: Friday, July 24, 2009 9:29 PM > To: dispatch@ietf.org > Subject: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 > > Here are my comments on this draft. > > Overall, I think this draft is an excellent start at the requirements > for this important topic. I look forward to future discussions of > charter text so we can get started on the work. > > Section 2: > > " Another, related IETF draft is draft-wing-sipping-srtp-key > [I-D.wing-sipping-srtp-key], which describes an approach for > providing SRTP session keys to a recorder-type server. That draft > focuses on the mechanism to provide the SRTP session key, rather than > the mechanism to invoke and sustain recording sessions themselves." > > draft-wing-sipping-srtp-key actually has a lot of discussion, including > call flows showing how recording sessions can be established. Also, > this document has four recording modes discussed, which I think should > be discussed in this document. Two are mentioned without really > explaining them, and two others are implied by various requirements. > > [LeonP] Yes, for the protocol draft, we will need to combine all of the approaches and make sure that we covered all use cases > > Section 3: > > " Recording Session: The session created between an RC and RS for the > purpose of recording a Recorded Session. The Recorded Session may > itself be based on SIP, but it is a separate session from the > Recording Session. > > Recorded Session: A session created between a UAC and UAS that is > recorded by the RC and RS systems." > > > These two terms only differ by their tense, yet I think one refers to a > signaling session and the other refers to a media session. If so, > better terms and definitions are needed. If not, we need a term for the > actual recorded media. Also, there are (at least) two sessions here - > the one between the UAs and the Recording Session - in a few places I > suspect the two are being confused. > > [LeonP] Actually Recording Session relates to both SIP and Media that is forked to the recording server and Recorded Session is actually the original conversation between two UAs. These two are exactly the two sessions that you are describing. > OK - I didn't get that from the definitions, so you probably want to reword these and maybe reference a figure. > " Dynamic Recording: Dynamic recording is a mode of recording where the > recording sessions are established on an as needed basis. The length > of these sessions is typically same as the length of the actual media > sessions. > > Persistent Recording: Persistent recording is a mode of recording > where the recording sessions are established at system start-up and > kept-alive from that point on. The length of these sessions is > independent from the length of the actual recorded media sessions. > Persistent recording sessions avoid issues such as media clipping > that can occur due to delays in recording session establishment." > > These terms need more explanation as I can think of multiple things they > might mean. For example, when you say "session" do you mean a signaling > session or media session? When you talk about avoiding media clipping, > do you mean that media is always sent by the RC to the RS regardless of > whether there is any media? > > [LeonP] Yes, by session we mean both legs: signaling and media. And in Persistent Recording mode, the Recording SIP session supposed to stay connected even there is not actual connected sessions for the specific recorded UA. > OK, you need to reword these definitions to this is very clear. > Figures could use Figure numbers and labels. Also, it would be worth > showing which is the RC and which is the RS in them. > > Section 5 > > " o REQ-001 The mechanism MUST support the ability to perform > persistent (always-on) or dynamic (on-demand) Recording Sessions." > > I'm not sure that the Persistent and Dynamic Recording as defined above > correspond to the Always On and On Demand modes defined in > http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4. > > [LeonP] It is different in the way that the Recording Session is established only once during initialization (or login events) and then only media is forwarded per each call in order to minimize the clipping. > That's what I thought you meant, and this is different from the definitions in my draft. We should try to get these definitions sorted out this week. > " o REQ-002 The mechanism MUST support the ability to perform > persistent Recording Sessions, such that the connection and > attributes of media in the Recording Session are not dynamically > signaled for each Recorded Session before it can be recorded. Call > details and metadata will still be signaled, but can be post- > correlated to the recorded media. There will still need to be a > means of correlating the recorded media connection/packets to the > Recorded Session, however this may be on a permanent filter-type > basis, such as based on a SIP AoR of an agent that is always > recorded, or based on identifiers in the recorded media itself." > > > Without fully understanding Persistent Recording, I can't evaluate this > requirement. > > " o REQ-009 The mechanism MUST support the ability to deliver mixed > media streams to the RS. The RS MAY be informed about the > composition of the mixed streams through session metadata. > > Note: A mixed media stream is where several recorded sessions are > carried in a single recording session. A mixed media stream is > typically produced by a mixer function." > > > I'm not clear what mixed media means here - does it mean a mix of media > types - synchronized audio and video from the same session, or do you > mean multiple media streams from different sessions? The note seems to > indicate that this relates only to a conference call where multiple > sources (SSRCs) have been combined into a single RTP session. > > [LeonP] It is specific trading floor environment requirements where multiple handset and speakers for specific turrets will be mixed on the turret level for recording by one recording channel. > OK - since this mixing is done by the endpoint (turret), this is an example of where the UA is acting as the RC, right? This use case should be described in the document. > > " o REQ-013 The mechanism MUST support the ability to inject tones into > the Recorded Session either from the RS or from the RC." > > Recorded Session seems to be defined as the media between the RC and > RS. Is that where the injected tones should be? Or should then be > mixed in the media between the two UAs? > [LeonP] we have multiple options here. Preferable solution that one of the UAs will inject them (triggered by policy or parameters in SRP), but there are also configuration where RS will be required to create them and send back to RC (like talking clock for example) > So, we are talking about the RS sending media to the RC which must be inserted into the media session between the two UAs? This use case needs to be discussed elsewhere outside of this requirement. > " o REQ-021 The mechanism MUST support the ability for the RC to only > perform media replication to the RS, without needing to decode or mix > audio/video/etc., and without needing to be an RTP agent. This will > allow the RC to replicate media at layers below RTP. Clearly, such > an RC mode would not be able to provide transcoding, or media > injection from the RS back into the Recorded Session." > > Does this mean that you think that RTP is unsuitable for transporting > media between the RS and RC? Clearly it isn't for IM, but I would think > that many of the functions of RTP are needed for audio and video media. > To understand this requirement will take more discussion. > > [LeonP] Actually it was Hadriel requirement. I believe it only means that RC does not required to implement RTP stack, it can just fork RTP packets on the network level (by hardware) > Yes, I think I get that when I reread the requirement. This is a very important requirement that has a huge impact on the scalability of the system. > Thanks, > Alan > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From dean.willis@softarmor.com Mon Jul 27 01:42:31 2009 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 E78CB28C248 for ; Mon, 27 Jul 2009 01:42:31 -0700 (PDT) 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 n8sunflLW3We for ; Mon, 27 Jul 2009 01:42:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B343D28C245 for ; Mon, 27 Jul 2009 01:42:30 -0700 (PDT) Received: from [78.64.69.187] (host-78-64-69-187.homerun.telia.com [78.64.69.187]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6R8gR6R011478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 03:42:30 -0500 Message-ID: <4A6D6870.9090702@softarmor.com> Date: Mon, 27 Jul 2009 03:42:24 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Alan Johnston References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> In-Reply-To: <4A6B1A84.2060505@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 08:42:32 -0000 Alan Johnston wrote: > Dean, > > Thanks for your comments. > > We did consider URI parameters as a mechanism. If we used this > approach, we would still need SIP extensions for those URI parameters > and a new SIP option tag to indicate support for it. As such, we'd > still need a mechanism to be standardized. I think in DISPATCH we are > supposed to be discussing scope and charter text, and I think the > current charter text is mechanism agnostic, so this approach would still > be covered, correct? Part of what DISPATCH has to do is decide whether the problem requires substantive new specification to perform, and if so, to shape the charter of that work. My belief is that if SIP provides a mechanism for user-to-user parameter passing as an inherent mechanism, then call-control UUI should use that mechanism. This means that there is no need for a SIP-extending working group to be formed to complete that work. Instead, it would be appropriate to document the parameter names and values using an individual draft. So I think my comments are very appropriate to the charter discussion in DISPATCH. I'm saying that we do NOT need to charter a working group for this work as I understand it. More strongly said, since History-Info is our currently agreed mechanism for meeting the SIPCORE charter deliverable of UAC to UAS parameter passing, and since ISDN call control proposes a new method of UAC to UAS parameter passing, then THIS PROPSOED WORK IS IN DIRECT CONFLICT WITH CHARTERED WORK IN SIPCORE. Now, it is arguable that we don't really have an effective mechanism for parameter passing using History-Info. If so, then the charter we should be talking about is for a generic UAC to UAS parameter passing mechanism, which call-control UUI could then utilize. This work could be done in SIPCORE (in fact, I believe that's the place for it, as we're talking about a very central and universal aspect of SIP), or in a new working group. That conversation we can certainly have in DISPATCH. > > In terms of History-Info, I don't think we've considered that before. > There were two problems with the URI parameters. One was the > retargeting problem but the other is semantics. Last time I read RFC > 3261, the Request-URI contained information about the destination > resource, and sometimes information about the next hop to that > resource. To put user-to-user data about the originator in the request > into the Request-URI seems like a big change to SIP semantics that we'd > need to think carefully about before diving into. We would definitely > need a SIP option tag to say that we are reversing the meaning of > Request-URI. ... > As for History-Info, it doesn't feel very right - how is UUI history > about the call? If anything, it is future information about the call. > Also, wouldn't every proxy that might retarget in the path have to > support it, or the UUI would be lost? If so, we'd need to use > Proxy-Require: history which is both ugly and not permitted by RFC 4244. We currently have SIPCORE working group consensus on History-Info being the mechanism for delivery of user-supplied data from UAC to UAS, that having been the goal of the original UA Loose route work. This is not a "reversal of request-URI semantics"; rather it is the original intent of the SIP Request URI, which is modeled on the HTTP request URI. The HTTP request URI is HTTP's normal mechanism for the delivery of application data from UAC to UAS. HTTP server applications don't have ready access to new HTTP headers (one would have to rewrite Apache for every such protocol extension), but they do have easy access to the request URI. There's nothing special about ISDN call control data in its interaction with SIP. It does NOT interact with the SIP state machine in any way. Extending SIP explicitly to support it is a serious violation of protocol layering. Admittedly, SIP is full of such cross-layer issues, but why do we insist on adding more? Call Control UUI is a "poster child", or in other words a perfect use case, for UAC to UAS parameter passing. If our UAC to UAS parameter-passing mechanism doesn't work for it, then we need to back up and take another look at the parameter-passing mechanism rather than continue to extend SIP with application-specific usages that should be outside of its scope. -- Dean From dean.willis@softarmor.com Mon Jul 27 01:50:06 2009 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 27CBD28C249 for ; Mon, 27 Jul 2009 01:50:06 -0700 (PDT) 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 fC3ozIl72SGl for ; Mon, 27 Jul 2009 01:50:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5F69628C266 for ; Mon, 27 Jul 2009 01:48:48 -0700 (PDT) Received: from [78.64.69.187] (host-78-64-69-187.homerun.telia.com [78.64.69.187]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6R8mhcR011554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 03:48:46 -0500 Message-ID: <4A6D69E9.4030200@softarmor.com> Date: Mon, 27 Jul 2009 03:48:41 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 08:50:06 -0000 Hadriel Kaplan wrote: > I think the retargeting and middlebox support issues are not really > But the real problem is the semantics as you say - to me a request > URI is information about the targeted resource or how to reach it, > not information about the source resource. Since H-I is just a list > of req-uri's, it's not the right place. I disagree. SIP is based on HTTP The Request URI encodes the request being made by the UAC to the UAS. The CCUUI data is not germane to SIP, it's just stuff being passed along the chain from UAC to UAS. Now, it might be reasonable to universally declare that SIP is, in fact, NOT HTTP, and that it uses a different parameter passing mechanism. If so, then what we would probably want to do is define a new header field, perhaps "User-Parameters:", that is reserved for user-to-user data consumed by applications. I'd be okay with that. > Really the technically *right* place would be in MIME, afaict - it's > opaque application data just like geoloc, right? But pragmatically, > the issues/problems with doing it in MIME were already covered and > debated in sipping, and iirc consensus was: put it in a header. > > ISTM that we always complain about lack of running code, and here we > have a case where there is running code from multiple vendors, and > it's not fundamentally broken/un-sound. It ain't broken, why do we > need to fix it? The same reason we shoud object to all layer-violation hacks: because it is architecturally unsound, inconsistent with the current SIP design approach, and leads to further unnecessary complexity in an already too-complex protocol. -- Dean From alan@sipstation.com Mon Jul 27 02:02:29 2009 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 D182528C246 for ; Mon, 27 Jul 2009 02:02:29 -0700 (PDT) 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 OMqad1xNbw8g for ; Mon, 27 Jul 2009 02:02:29 -0700 (PDT) Received: from outbound-mail-357.bluehost.com (outbound-mail-357.bluehost.com [66.147.249.251]) by core3.amsl.com (Postfix) with SMTP id 08A4128C237 for ; Mon, 27 Jul 2009 02:02:29 -0700 (PDT) Received: (qmail 2851 invoked by uid 0); 27 Jul 2009 09:02:30 -0000 Received: from unknown (HELO host350.hostmonster.com) (66.147.240.150) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 27 Jul 2009 09:02:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sipstation.com; h=Received:References:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Mailer:Mime-Version:Subject:Date:Cc:X-Identified-User; b=BkuHQv3+4iOvrz4xKmDBc7ZkaZF8UI5xlpIlJrghHUcNllBUwR1NFmXwsBnz/qOraoK3jRAhFbF7RADQ9on5lky4b+YL8oGaSCE7Pbc5ApD7LJEKknU4gf5gQew/YUhS; Received: from dhcp-13b6.meeting.ietf.org ([130.129.19.182]) by host350.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1MVM6H-0001cm-J9; Mon, 27 Jul 2009 03:02:30 -0600 References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> Message-Id: <6FC29B49-B4CE-4155-A67C-DD94C87CC3FC@sipstation.com> From: Alan Johnston To: Dean Willis In-Reply-To: <4A6D69E9.4030200@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Mon, 27 Jul 2009 11:02:26 +0200 X-Identified-User: {2451:host350.hostmonster.com:aeternus:sipstation.com} {sentby:smtp auth 130.129.19.182 authed with alan+sipstation.com} Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 09:02:29 -0000 Dean, So basically, you want a different name for the header field? Otherwise the semantics seem identical to what is proposed. Thanks, Alan On Jul 27, 2009, at 10:48 AM, Dean Willis wrote: > Hadriel Kaplan wrote: > >> I think the retargeting and middlebox support issues are not really >> But the real problem is the semantics as you say - to me a request >> URI is information about the targeted resource or how to reach it, >> not information about the source resource. Since H-I is just a list >> of req-uri's, it's not the right place. > > I disagree. SIP is based on HTTP The Request URI encodes the request > being made by the UAC to the UAS. The CCUUI data is not germane to > SIP, > it's just stuff being passed along the chain from UAC to UAS. > > Now, it might be reasonable to universally declare that SIP is, in > fact, > NOT HTTP, and that it uses a different parameter passing mechanism. If > so, then what we would probably want to do is define a new header > field, > perhaps "User-Parameters:", that is reserved for user-to-user data > consumed by applications. I'd be okay with that. > > >> Really the technically *right* place would be in MIME, afaict - it's >> opaque application data just like geoloc, right? But pragmatically, >> the issues/problems with doing it in MIME were already covered and >> debated in sipping, and iirc consensus was: put it in a header. >> >> ISTM that we always complain about lack of running code, and here we >> have a case where there is running code from multiple vendors, and >> it's not fundamentally broken/un-sound. It ain't broken, why do we >> need to fix it? > > The same reason we shoud object to all layer-violation hacks: > because it is architecturally unsound, inconsistent with the current > SIP > design approach, and leads to further unnecessary complexity in an > already too-complex protocol. > > > -- > Dean From HKaplan@acmepacket.com Mon Jul 27 02:34:36 2009 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 A7EC128C251 for ; Mon, 27 Jul 2009 02:34:36 -0700 (PDT) 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=[AWL=0.000, 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 Qw0Rvjepk5pX for ; Mon, 27 Jul 2009 02:34:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BFFA328C23C for ; Mon, 27 Jul 2009 02:34:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 27 Jul 2009 05:34:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 27 Jul 2009 05:34:32 -0400 From: Hadriel Kaplan To: Dean Willis Date: Mon, 27 Jul 2009 05:34:30 -0400 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoOlxwqrzxZcmDfRMWQZSr8w9C0LwAA224g Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> In-Reply-To: <4A6D69E9.4030200@softarmor.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@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 09:34:36 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, July 27, 2009 4:49 AM > To: Hadriel Kaplan >=20 > I disagree. SIP is based on HTTP The Request URI encodes the request > being made by the UAC to the UAS.=20 Then you might as well argue the request-URI should encode MIME bodies. Th= e UUI is not a part of the resource being addressed in any way, and thus no= t a part of a Uniform Resource Identifier. =20 > Now, it might be reasonable to universally declare that SIP is, in fact, > NOT HTTP, and that it uses a different parameter passing mechanism.=20 Well, I'll probably be flamed, but afaict it is not HTTP in most every impo= rtant way. It does a LOT of things differently. That ship has sailed. It= is far closer to email (with some weird combo of SMTP and POP3), if anythi= ng.=20 > If > so, then what we would probably want to do is define a new header field, > perhaps "User-Parameters:", that is reserved for user-to-user data > consumed by applications. I'd be okay with that. That was actually how I interpreted the semantic notion of the User-to-User= header. -hadriel From pkyzivat@cisco.com Mon Jul 27 06:13:53 2009 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 9CF493A6C75 for ; Mon, 27 Jul 2009 06:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 K9EiRrZsi-uL for ; Mon, 27 Jul 2009 06:13:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0A8A83A6826 for ; Mon, 27 Jul 2009 06:13:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdEbUqrR7PD/2dsb2JhbAC5QIgojXcFhA0 X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="219523948" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2009 13:13:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6RDDrTx006135; Mon, 27 Jul 2009 06:13:53 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6RDDopG007653; Mon, 27 Jul 2009 13:13:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:13:51 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:13:51 -0400 Message-ID: <4A6DA80F.2070003@cisco.com> Date: Mon, 27 Jul 2009 09:13:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com> <4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 13:13:51.0561 (UTC) FILETIME=[15C8EB90:01CA0EBC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11912; t=1248700433; x=1249564433; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20I-D=20Action=3Adraft-johns ton-sipping-cc-uui-08.txt |Sender:=20; bh=U0IuG/7FU2tMZpDPbMIWZpFuDhnPyJR46SOpuUDi0KE=; b=QnCTnOcYz85IcNMNpWPI9XNp+KSdmuYwJGQFeQqEuDABbQTj66c7S9O4K2 xMCZLKclNfz09xN1o3Rbk8w4C6CO10AYxAtpAHrNQrvQS0+1r2hrPYXsHJlq SebmGY3oNA; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 27 Jul 2009 13:13:53 -0000 Keith, If this is *not* ISDN encoding, then where is the indication of what encoding is being used? Are you saying that this is a private agreement between the UAC and UAS, neither signaled nor negotiated? How can that possibly work? I thought the first byte of the value was a registered format indicator. Thanks, Paul DRAGE, Keith (Keith) wrote: > Just to respond to this bit of the message: > >>> Not quite. We are not making the assumption that both are >> gateways, >>> although that is possible. Most likely, one element is SIP enabled. >>> However, it is not a fully intelligent SIP endpoint - the basic >>> software and application (probably many years old) is >> unchanged but a >>> SIP interface (SIP trunk) has been added. As such, the SIP >> stack does >>> not know anything about the UUI as it is implementing >> exactly the ISDN >>> UUI service - the information is just pushed up the stack >> to another >>> application, and this application knows nothing about SIP. >> It still >>> thinks it is using an ISDN trunk. >> Then in the way I meant the question, both ends *are* gateways. >> >> But then if someone wishes to build native sip gear to plug >> into this environment, then it will still have to understand >> this isdn encoding. >> Perhaps that is the cruel truth, unless all the equipment is >> replaced at once. > > I've said this before and I'll say it again. The bit being delivered to the end UE is not "isdn encoding". If it was ISDN encoding, then the ISDN / SIP gateway would be able to interpret it and map it into SIP. Rather it is some application sitting above the ISDN call control layer in the calling terminal, which is wishing to communicate with its peer application running in the destination SIP UA, or gateway. > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Saturday, July 04, 2009 12:39 AM >> To: Alan Johnston >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-johnston-sipping-cc-uui-08.txt >> >> Hi Alan, >> >> responses inline. I've trimmed out the parts that don't >> require more discussion. >> >> Thanks, >> Paul >> >> Alan Johnston wrote: >>> Paul, >>> >>> Thanks for your comments. See mine below. >>> >>> Thanks, >>> Alan >>> >>> Paul Kyzivat wrote: >>>> Hi Alan, >>>> >>>> I took a quick look at this doc and the requirements doc >> as well. I >>>> have a few thoughts: >>>> >>>> From section 1: >>>> >>>>> In the future, where both endpoints are intelligent >> SIP user agents, >>>>> it may be possible for them to understand and >> interpret the UUI data. >>>>> There may be some cases where the UUI information is >> relevant to SIP. >>>>> In this case, it might be worthwhile attempting to map >> UUI data to an >>>>> appropriate SIP header field or to standardize a new >> header field. >>>>> However, the requirements and use cases for this are >> different enough >>>>> from those described in this document that these two situations >>>>> should be examined separately. This document looks only at the >>>>> requirements and mechanisms for replicating the >> existing, widely used >>>>> and deployed ISDN UUI service. >>>> This *still* troubles me! >>>> Is the assumption here that *both* the UAC and UAS are >> gateways, so >>>> that this mechanism is solely for the tunneling of Q.931 and Q.763 >>>> UUI message over SIP? >>>> >>>> I get the impression that an important use case is where at least >>>> *one* end (probably the UAS) is a SIP device. In that case it will >>>> already be *necessary* for it to understand and interpret UUI data. >>>> And where there is redundancy between SIP data and the UUI >> data, it >>>> will need to resolve the discrepancy. >>> Not quite. We are not making the assumption that both are >> gateways, >>> although that is possible. Most likely, one element is SIP enabled. >>> However, it is not a fully intelligent SIP endpoint - the basic >>> software and application (probably many years old) is >> unchanged but a >>> SIP interface (SIP trunk) has been added. As such, the SIP >> stack does >>> not know anything about the UUI as it is implementing >> exactly the ISDN >>> UUI service - the information is just pushed up the stack >> to another >>> application, and this application knows nothing about SIP. >> It still >>> thinks it is using an ISDN trunk. >> Then in the way I meant the question, both ends *are* gateways. >> >> But then if someone wishes to build native sip gear to plug >> into this environment, then it will still have to understand >> this isdn encoding. >> Perhaps that is the cruel truth, unless all the equipment is >> replaced at once. >> >>>>> 5. Syntax for UUI Header Field >>>> ... >>>>> UUI = "User-to-User" HCOLON uui-data >> *(SEMI uui-param) >>>>> uui-data = token >>>>> uui-param = enc-param | cont-param | purp-param >> | generic-param >>>>> enc-param = "encoding=" ("hex" | token) >>>>> cont-param = "content=" ("isdn-uui" | token) >>>>> purp-param = "purpose=" ("isdn-interwork" | token) >>>> At the very least, I would request that this be expanded a >> little bit >>>> for future flexibility, by permitting the uui-data to be either a >>>> token or a string. While the encoding you have chosen works as a >>>> token, other encodings may need the additional flexibility >> of a string. >>>> uui-data = token | quoted-string >>> OK, I guess I'm OK with that. For the isdn-interwork >> purpose, we'll >>> require the token, but other applications could utilize the >> quoted string. >> >> I would hope that when the token encoding is sufficient, then >> either form would be accepted. Or it would perhaps be ok to >> specify for a particular encoding (hex) that the token >> encoding must be used. I don't see how the purpose has >> anything to do with it. >> >>>>> 6.3. Registration of SIP Option Tag >>>> This section registers the new option tag. But I find >> almost nothing >>>> that defines the semantics of the option. (Section 5 does >> include the >>>> following: >>>> >>>>> A UA that supports this feature and the "uui" option >> tag MUST support >>>>> the call flows in [johnston-dispatch-sip-cc-uui]... >>>> but that is pretty thin from a normative perspective. >>>> >>>> Of particular note, does support for the option tag mean >> support for >>>> the particular encoding, content, and purpose included in this >>>> document? Or does it only mean support for the header and >> params in >>>> the abstract? (That wouldn't be very useful.) >>> Yes, this needs clarification. I'd suggest we define the >> option tag >>> to be uui-isdn which means it understands the header field and the >>> isdn-interwork purpose, and the call flows, including escaping into >>> redirection and Refer-To URIs. >> I'd like to hear some other opinions on whether to have tag >> per param for tag, or a tag for the combination of param >> values. I think I'm ok with what you propose. >> >>>> I don't see how it can mean support for some other yet to >> be defined >>>> values for those. Yet if it only means support for the >> current ones, >>>> then how will one indicate support for future ones? >>>> >>>> The only way out of this that I can see is to have >> separate options, >>>> either for particular values of each parameter, or for particular >>>> combinations of values of all the parameters. >>> New applications using this header field would have the option of >>> defining a new SIP option tag which would mean support for >> the header >>> field and their new purpose. >>> >>>> So you might have options uui-purpose-isdn-interwork, >>>> uui-content-isdn, and uui-encoding-hex. Or you might just >> have option >>>> uui-isdn-interwork that means the combination. >>> I think the latter. I see it as a hierarchy - the application or >>> purpose is the top one. Each purpose has a number of >> contents that it >>> supports. Each content has a number of encoding schemes it >> supports. >> >> I guess I'm ok with that, pending nailing down the definition >> of "purpose". >> >>>> I also am not finding much explanation of the semantics of the >>>> content and purpose parameters. I can only extrapolate >> from a single >>>> example of each, which I'm having trouble doing. >>>> >>>> I'm guessing that 'content' must refer to the precise >> syntax of the >>>> contained data, after decoding. So presumably it must map >> onto some >>>> particular spec. For isdn-uui, would that be [Q931] or >> [Q763]? If so, >>>> shouldn't it refer to something specific in that document? >>> Not really. In this case, isdn-uui effectively means "opaque data" >>> which is how ISDN defines the UUI - it is completely undefined, >>> necessarily so by the strict layering used in the ISDN application. >> I don't believe you! >> >> If that is the case, then the UAC and UAS must have a private >> side agreement about what the isdn-uui content means. Is that >> really what you mean? >> >> You already state that the first byte is a protocol >> discriminator. There must also be something, somewhere, that >> specifies the mapping from a particular value for that byte >> to a particular protocol/format. If there is, then that >> should be part of the definition of this content. >> >>>> 'purpose' is even less clear to me. Does it refer to why >> it is being >>>> included? Or what is to be done with it? If received by a >> UA that is >>>> not an ISDN gateway, how can it decide if this is >> something it should >>>> be trying to process? Is it still ISDN interworking if neither the >>>> UAC nor UAS is connected to an ISDN network? >>> The purpose is the application using the UUI. Others have >> expressed >>> an interest in carrying other data in the header field, in >> which case >>> a new purpose would be defined. I'll see if I can think of >> an example one. >> >> So are you saying that a particular call center application >> might constitute a distinct "purpose"? >> >>> Basically, if two UAs both support the header but have different >>> applications generating and consuming the UUI, it will not >> work. This >>> is not a SIP failure, and there is nothing SIP can do about >> it. But >>> this purpose header field allows the UAs to detect this condition. >> In that case, perhaps "isdn-interwork" isn't really a single >> purpose at all, unless any two pieces of equipment that >> support that purpose can then interwork without knowing any >> more about each other. >> >>>> Suppose I was developing a sophisticated UA that >> potentially might be >>>> usable by a call center operator. How should >> purpose=isdn-interwork >>>> affect the operation of this device? >>> To make it work in today's contact center applications, supporting >>> isdn-interwork would likely make it work in an application, >> provided >>> the appropriate call center application also ran on it. >> Some contact >>> centers do not use ISDN UUI, instead they use all kinds of really, >>> really ugly CTI protocols running in parallel. >> Yes, I know! :-( >> >>> This is a way of moving >>> those to the ISDN model, and from there to a more >> intelligent endpoint >>> SIP model. >>> >>>> Thanks, >>>> Paul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From pkyzivat@cisco.com Mon Jul 27 06:23:04 2009 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 2EC1528C1A2 for ; Mon, 27 Jul 2009 06:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 E+2c4xhlIrXW for ; Mon, 27 Jul 2009 06:23:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5D0A428C208 for ; Mon, 27 Jul 2009 06:23:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE5HbUpAZnmf/2dsb2JhbAC5SogojXwFhA0 X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="189878680" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 27 Jul 2009 13:23:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6RDN4kI006275; Mon, 27 Jul 2009 09:23:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RDN3hG025776; Mon, 27 Jul 2009 13:23:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:23:03 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:23:03 -0400 Message-ID: <4A6DAA38.8010709@cisco.com> Date: Mon, 27 Jul 2009 09:23:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A6450D6.90904@ericsson.com> <4A646F12.8070000@cisco.com> <4A6C3C62.6050006@ericsson.com> In-Reply-To: <4A6C3C62.6050006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 13:23:03.0462 (UTC) FILETIME=[5EBE5460:01CA0EBD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=855; t=1248700984; x=1249564984; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=2xqP04eY8cCg6fDZ2Yv720tn9LAVEZC87wjfjbjDt4M=; b=iJchzHElo6M6PJSDk/hKRnmSwSm9fUNYk2mykAg4kY6JMgwOJOSPE2Q0CD 73wVQTfGhI6I+0dW8lr+Nwh+S0aqmmd5MG8cU778eBw3a2Hefw0HKo2zjQIc lVsWK6l3C1; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 27 Jul 2009 13:23:04 -0000 Gonzalo Camarillo wrote: > Hi, > >> I guess the one way I could buy into your "distributed" approach is to >> simply model it as a conference, where the focus is at one "end". But >> I think we discussed that once. > > that is how it is modeled when only one of the ends is distributed. What > we discussed was that the semantics of join were intended for > conferences and that even though this was very similar, it was not the > same thing... but the model is valid. If the model is valid, then I think the mechanisms that go with it should be valid too. The conferencing mechanism could be used for either the "distributed" or "centralized" approach. Then there needs to be a focus somewhere, and the difference between the approaches is where it resides - at your own end, or at the "other" end. Thanks, Paul From pkyzivat@cisco.com Mon Jul 27 06:33:19 2009 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 45BA93A6C78 for ; Mon, 27 Jul 2009 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 f1jR4Uworl36 for ; Mon, 27 Jul 2009 06:33:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3BC253A6C77 for ; Mon, 27 Jul 2009 06:33:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALJJbUpAZnmf/2dsb2JhbAC5ZYgojX0FhA0 X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="219532927" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2009 13:33:18 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6RDXIMs011411; Mon, 27 Jul 2009 09:33:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RDXILL029412; Mon, 27 Jul 2009 13:33:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:33:18 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:33:17 -0400 Message-ID: <4A6DAC9D.7040903@cisco.com> Date: Mon, 27 Jul 2009 09:33:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alan Johnston References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <6FC29B49-B4CE-4155-A67C-DD94C87CC3FC@sipstation.com> In-Reply-To: <6FC29B49-B4CE-4155-A67C-DD94C87CC3FC@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 13:33:17.0906 (UTC) FILETIME=[CCFB0B20:01CA0EBE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2465; t=1248701598; x=1249565598; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20CCUS=20and=20History-Info= 20(was=20Proposed=20Charter=20for=20CCUS=0A=20-=20Call=20Con trol=20UUI=20for=20SIP) |Sender:=20 |To:=20Alan=20Johnston=20; bh=q3a1nd5oWp15wbtQ3tKCQe1GHqnyVPHV6iL9GLZiVLw=; b=t199/IvuGpQuELlyCa9nMtGRDU9UCb4IBZf0U/9wVyaIBX1f3GPPWhIgVE 2/TtE7K7e7/Tv8XbuH5CVzjU9BZ1vnxy/tMWnzxwJbZ3bobaWN+9GezgtMvs 5QhfU2NmGi; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 13:33:19 -0000 Alan Johnston wrote: > Dean, > > So basically, you want a different name for the header field? Otherwise > the semantics seem identical to what is proposed. There at least needs to be some interoperable way to specify the format of the data being passed. We have that with MIME, but when using a header the mechanism needs to be reinvented, along with a way to say "I don't understand that". Thanks, Paul > Thanks, > Alan > > > > On Jul 27, 2009, at 10:48 AM, Dean Willis > wrote: > >> Hadriel Kaplan wrote: >> >>> I think the retargeting and middlebox support issues are not really >>> But the real problem is the semantics as you say - to me a request >>> URI is information about the targeted resource or how to reach it, >>> not information about the source resource. Since H-I is just a list >>> of req-uri's, it's not the right place. >> >> I disagree. SIP is based on HTTP The Request URI encodes the request >> being made by the UAC to the UAS. The CCUUI data is not germane to SIP, >> it's just stuff being passed along the chain from UAC to UAS. >> >> Now, it might be reasonable to universally declare that SIP is, in fact, >> NOT HTTP, and that it uses a different parameter passing mechanism. If >> so, then what we would probably want to do is define a new header field, >> perhaps "User-Parameters:", that is reserved for user-to-user data >> consumed by applications. I'd be okay with that. >> >> >>> Really the technically *right* place would be in MIME, afaict - it's >>> opaque application data just like geoloc, right? But pragmatically, >>> the issues/problems with doing it in MIME were already covered and >>> debated in sipping, and iirc consensus was: put it in a header. >>> >>> ISTM that we always complain about lack of running code, and here we >>> have a case where there is running code from multiple vendors, and >>> it's not fundamentally broken/un-sound. It ain't broken, why do we >>> need to fix it? >> >> The same reason we shoud object to all layer-violation hacks: >> because it is architecturally unsound, inconsistent with the current SIP >> design approach, and leads to further unnecessary complexity in an >> already too-complex protocol. >> >> >> -- >> Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From drage@alcatel-lucent.com Mon Jul 27 07:13:06 2009 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 E73B328C188 for ; Mon, 27 Jul 2009 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-1.322, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 VfJIVPsKeqzJ for ; Mon, 27 Jul 2009 07:13:05 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 27B9628C125 for ; Mon, 27 Jul 2009 07:13:04 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6RECbkG006709 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jul 2009 16:12:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 27 Jul 2009 16:12:37 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Mon, 27 Jul 2009 16:12:33 +0200 Thread-Topic: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt Thread-Index: AcoOvC0iLaMwaNy4TXe6RE8IhBnyqQACBEVg Message-ID: References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com> <4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com> <4A6DA80F.2070003@cisco.com> In-Reply-To: <4A6DA80F.2070003@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 27 Jul 2009 14:13:07 -0000 1st octet of the payload. Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, July 27, 2009 2:14 PM > To: DRAGE, Keith (Keith) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D=20 > Action:draft-johnston-sipping-cc-uui-08.txt >=20 > Keith, >=20 > If this is *not* ISDN encoding, then where is the indication=20 > of what encoding is being used? Are you saying that this is a=20 > private agreement between the UAC and UAS, neither signaled=20 > nor negotiated? How can that possibly work? >=20 > I thought the first byte of the value was a registered format=20 > indicator. >=20 > Thanks, > Paul >=20 > DRAGE, Keith (Keith) wrote: > > Just to respond to this bit of the message: > >=20 > >>> Not quite. We are not making the assumption that both are > >> gateways, > >>> although that is possible. Most likely, one element is=20 > SIP enabled. > >>> However, it is not a fully intelligent SIP endpoint - the basic=20 > >>> software and application (probably many years old) is > >> unchanged but a > >>> SIP interface (SIP trunk) has been added. As such, the SIP > >> stack does > >>> not know anything about the UUI as it is implementing > >> exactly the ISDN > >>> UUI service - the information is just pushed up the stack > >> to another > >>> application, and this application knows nothing about SIP. =20 > >> It still > >>> thinks it is using an ISDN trunk. > >> Then in the way I meant the question, both ends *are* gateways. > >> > >> But then if someone wishes to build native sip gear to=20 > plug into this=20 > >> environment, then it will still have to understand this isdn=20 > >> encoding. > >> Perhaps that is the cruel truth, unless all the equipment=20 > is replaced=20 > >> at once. > >=20 > > I've said this before and I'll say it again. The bit being=20 > delivered to the end UE is not "isdn encoding". If it was=20 > ISDN encoding, then the ISDN / SIP gateway would be able to=20 > interpret it and map it into SIP. Rather it is some=20 > application sitting above the ISDN call control layer in the=20 > calling terminal, which is wishing to communicate with its=20 > peer application running in the destination SIP UA, or gateway. > >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Saturday, July 04, 2009 12:39 AM > >> To: Alan Johnston > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] I-D > >> Action:draft-johnston-sipping-cc-uui-08.txt > >> > >> Hi Alan, > >> > >> responses inline. I've trimmed out the parts that don't=20 > require more=20 > >> discussion. > >> > >> Thanks, > >> Paul > >> > >> Alan Johnston wrote: > >>> Paul, > >>> > >>> Thanks for your comments. See mine below. > >>> > >>> Thanks, > >>> Alan > >>> > >>> Paul Kyzivat wrote: > >>>> Hi Alan, > >>>> > >>>> I took a quick look at this doc and the requirements doc > >> as well. I > >>>> have a few thoughts: > >>>> > >>>> From section 1: > >>>> > >>>>> In the future, where both endpoints are intelligent > >> SIP user agents, > >>>>> it may be possible for them to understand and > >> interpret the UUI data. > >>>>> There may be some cases where the UUI information is > >> relevant to SIP. > >>>>> In this case, it might be worthwhile attempting to map > >> UUI data to an > >>>>> appropriate SIP header field or to standardize a new > >> header field. > >>>>> However, the requirements and use cases for this are > >> different enough > >>>>> from those described in this document that these two=20 > situations > >>>>> should be examined separately. This document looks=20 > only at the > >>>>> requirements and mechanisms for replicating the > >> existing, widely used > >>>>> and deployed ISDN UUI service. > >>>> This *still* troubles me! > >>>> Is the assumption here that *both* the UAC and UAS are > >> gateways, so > >>>> that this mechanism is solely for the tunneling of Q.931=20 > and Q.763=20 > >>>> UUI message over SIP? > >>>> > >>>> I get the impression that an important use case is where at least > >>>> *one* end (probably the UAS) is a SIP device. In that=20 > case it will=20 > >>>> already be *necessary* for it to understand and=20 > interpret UUI data. > >>>> And where there is redundancy between SIP data and the UUI > >> data, it > >>>> will need to resolve the discrepancy. > >>> Not quite. We are not making the assumption that both are > >> gateways, > >>> although that is possible. Most likely, one element is=20 > SIP enabled. > >>> However, it is not a fully intelligent SIP endpoint - the basic=20 > >>> software and application (probably many years old) is > >> unchanged but a > >>> SIP interface (SIP trunk) has been added. As such, the SIP > >> stack does > >>> not know anything about the UUI as it is implementing > >> exactly the ISDN > >>> UUI service - the information is just pushed up the stack > >> to another > >>> application, and this application knows nothing about SIP. =20 > >> It still > >>> thinks it is using an ISDN trunk. > >> Then in the way I meant the question, both ends *are* gateways. > >> > >> But then if someone wishes to build native sip gear to=20 > plug into this=20 > >> environment, then it will still have to understand this isdn=20 > >> encoding. > >> Perhaps that is the cruel truth, unless all the equipment=20 > is replaced=20 > >> at once. > >> > >>>>> 5. Syntax for UUI Header Field > >>>> ... > >>>>> UUI =3D "User-to-User" HCOLON uui-data=20 > >> *(SEMI uui-param) > >>>>> uui-data =3D token > >>>>> uui-param =3D enc-param | cont-param | purp-param=20 > >> | generic-param > >>>>> enc-param =3D "encoding=3D" ("hex" | token) > >>>>> cont-param =3D "content=3D" ("isdn-uui" | token) > >>>>> purp-param =3D "purpose=3D" ("isdn-interwork" | token) > >>>> At the very least, I would request that this be expanded a > >> little bit > >>>> for future flexibility, by permitting the uui-data to be=20 > either a=20 > >>>> token or a string. While the encoding you have chosen works as a=20 > >>>> token, other encodings may need the additional flexibility > >> of a string. > >>>> uui-data =3D token | quoted-string > >>> OK, I guess I'm OK with that. For the isdn-interwork > >> purpose, we'll > >>> require the token, but other applications could utilize the > >> quoted string. > >> > >> I would hope that when the token encoding is sufficient,=20 > then either=20 > >> form would be accepted. Or it would perhaps be ok to specify for a=20 > >> particular encoding (hex) that the token encoding must be used. I=20 > >> don't see how the purpose has anything to do with it. > >> > >>>>> 6.3. Registration of SIP Option Tag > >>>> This section registers the new option tag. But I find > >> almost nothing > >>>> that defines the semantics of the option. (Section 5 does > >> include the > >>>> following: > >>>> > >>>>> A UA that supports this feature and the "uui" option > >> tag MUST support > >>>>> the call flows in [johnston-dispatch-sip-cc-uui]... > >>>> but that is pretty thin from a normative perspective. > >>>> > >>>> Of particular note, does support for the option tag mean > >> support for > >>>> the particular encoding, content, and purpose included in this=20 > >>>> document? Or does it only mean support for the header and > >> params in > >>>> the abstract? (That wouldn't be very useful.) > >>> Yes, this needs clarification. I'd suggest we define the > >> option tag > >>> to be uui-isdn which means it understands the header=20 > field and the=20 > >>> isdn-interwork purpose, and the call flows, including=20 > escaping into=20 > >>> redirection and Refer-To URIs. > >> I'd like to hear some other opinions on whether to have=20 > tag per param=20 > >> for tag, or a tag for the combination of param values. I=20 > think I'm ok=20 > >> with what you propose. > >> > >>>> I don't see how it can mean support for some other yet to > >> be defined > >>>> values for those. Yet if it only means support for the > >> current ones, > >>>> then how will one indicate support for future ones? > >>>> > >>>> The only way out of this that I can see is to have > >> separate options, > >>>> either for particular values of each parameter, or for=20 > particular=20 > >>>> combinations of values of all the parameters. > >>> New applications using this header field would have the option of=20 > >>> defining a new SIP option tag which would mean support for > >> the header > >>> field and their new purpose. > >>> > >>>> So you might have options uui-purpose-isdn-interwork,=20 > >>>> uui-content-isdn, and uui-encoding-hex. Or you might just > >> have option > >>>> uui-isdn-interwork that means the combination. > >>> I think the latter. I see it as a hierarchy - the application or=20 > >>> purpose is the top one. Each purpose has a number of > >> contents that it > >>> supports. Each content has a number of encoding schemes it > >> supports. > >> > >> I guess I'm ok with that, pending nailing down the definition of=20 > >> "purpose". > >> > >>>> I also am not finding much explanation of the semantics of the=20 > >>>> content and purpose parameters. I can only extrapolate > >> from a single > >>>> example of each, which I'm having trouble doing. > >>>> > >>>> I'm guessing that 'content' must refer to the precise > >> syntax of the > >>>> contained data, after decoding. So presumably it must map > >> onto some > >>>> particular spec. For isdn-uui, would that be [Q931] or > >> [Q763]? If so, > >>>> shouldn't it refer to something specific in that document? > >>> Not really. In this case, isdn-uui effectively means=20 > "opaque data"=20 > >>> which is how ISDN defines the UUI - it is completely undefined,=20 > >>> necessarily so by the strict layering used in the ISDN=20 > application. > >> I don't believe you! > >> > >> If that is the case, then the UAC and UAS must have a private side=20 > >> agreement about what the isdn-uui content means. Is that=20 > really what=20 > >> you mean? > >> > >> You already state that the first byte is a protocol discriminator.=20 > >> There must also be something, somewhere, that specifies=20 > the mapping=20 > >> from a particular value for that byte to a particular=20 > >> protocol/format. If there is, then that should be part of the=20 > >> definition of this content. > >> > >>>> 'purpose' is even less clear to me. Does it refer to why > >> it is being > >>>> included? Or what is to be done with it? If received by a > >> UA that is > >>>> not an ISDN gateway, how can it decide if this is > >> something it should > >>>> be trying to process? Is it still ISDN interworking if=20 > neither the=20 > >>>> UAC nor UAS is connected to an ISDN network? > >>> The purpose is the application using the UUI. Others have > >> expressed > >>> an interest in carrying other data in the header field, in > >> which case > >>> a new purpose would be defined. I'll see if I can think of > >> an example one. > >> > >> So are you saying that a particular call center application might=20 > >> constitute a distinct "purpose"? > >> > >>> Basically, if two UAs both support the header but have different=20 > >>> applications generating and consuming the UUI, it will not > >> work. This > >>> is not a SIP failure, and there is nothing SIP can do about > >> it. But > >>> this purpose header field allows the UAs to detect this condition. > >> In that case, perhaps "isdn-interwork" isn't really a=20 > single purpose=20 > >> at all, unless any two pieces of equipment that support=20 > that purpose=20 > >> can then interwork without knowing any more about each other. > >> > >>>> Suppose I was developing a sophisticated UA that > >> potentially might be > >>>> usable by a call center operator. How should > >> purpose=3Disdn-interwork > >>>> affect the operation of this device? > >>> To make it work in today's contact center applications,=20 > supporting=20 > >>> isdn-interwork would likely make it work in an application, > >> provided > >>> the appropriate call center application also ran on it. =20 > >> Some contact > >>> centers do not use ISDN UUI, instead they use all kinds=20 > of really,=20 > >>> really ugly CTI protocols running in parallel. > >> Yes, I know! :-( > >> > >>> This is a way of moving > >>> those to the ISDN model, and from there to a more > >> intelligent endpoint > >>> SIP model. > >>> > >>>> Thanks, > >>>> Paul > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > = From alan@sipstation.com Mon Jul 27 07:43:40 2009 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 744AB28C146 for ; Mon, 27 Jul 2009 07:43:40 -0700 (PDT) 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 milq-ilqUrAg for ; Mon, 27 Jul 2009 07:43:37 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D63783A6A63 for ; Mon, 27 Jul 2009 07:43:36 -0700 (PDT) Received: from dhcp-1367.meeting.ietf.org ([130.129.19.103]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MVRQ8-000PSz-2j; Mon, 27 Jul 2009 14:43:20 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.19.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18WRB//O2G1KEli1wuhodRVxohVN6Ec87I= Message-ID: <4A6DBD04.7070801@sipstation.com> Date: Mon, 27 Jul 2009 09:43:16 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <6FC29B49-B4CE-4155-A67C-DD94C87CC3FC@sipstation.com> <4A6DAC9D.7040903@cisco.com> In-Reply-To: <4A6DAC9D.7040903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 14:43:40 -0000 Paul Kyzivat wrote: > > > Alan Johnston wrote: >> Dean, >> >> So basically, you want a different name for the header field? >> Otherwise the semantics seem identical to what is proposed. > > There at least needs to be some interoperable way to specify the > format of the data being passed. We have that with MIME, but when > using a header the mechanism needs to be reinvented, along with a way > to say "I don't understand that". This is an excellent point. The latest version of the mechanism draft has a way of specifying the purpose (application) and encoding, based on this need. The requirements currently say that a UAC has to be able to discover if a UAS supports the UUI *mechanism*. The obvious way to do this is a SIP option tag. But do we need a requirement for a UAC to discover if a UAS supports a particular purpose/application? If the same UUI is encoded in different ways, do we need a way to say "you need to be able to support *one* of the data objects? Thanks, Alan > > Thanks, > Paul > >> Thanks, >> Alan >> >> >> >> On Jul 27, 2009, at 10:48 AM, Dean Willis >> wrote: >> >>> Hadriel Kaplan wrote: >>> >>>> I think the retargeting and middlebox support issues are not really >>>> But the real problem is the semantics as you say - to me a request >>>> URI is information about the targeted resource or how to reach it, >>>> not information about the source resource. Since H-I is just a list >>>> of req-uri's, it's not the right place. >>> >>> I disagree. SIP is based on HTTP The Request URI encodes the request >>> being made by the UAC to the UAS. The CCUUI data is not germane to SIP, >>> it's just stuff being passed along the chain from UAC to UAS. >>> >>> Now, it might be reasonable to universally declare that SIP is, in >>> fact, >>> NOT HTTP, and that it uses a different parameter passing mechanism. If >>> so, then what we would probably want to do is define a new header >>> field, >>> perhaps "User-Parameters:", that is reserved for user-to-user data >>> consumed by applications. I'd be okay with that. >>> >>> >>>> Really the technically *right* place would be in MIME, afaict - it's >>>> opaque application data just like geoloc, right? But pragmatically, >>>> the issues/problems with doing it in MIME were already covered and >>>> debated in sipping, and iirc consensus was: put it in a header. >>>> >>>> ISTM that we always complain about lack of running code, and here we >>>> have a case where there is running code from multiple vendors, and >>>> it's not fundamentally broken/un-sound. It ain't broken, why do we >>>> need to fix it? >>> >>> The same reason we shoud object to all layer-violation hacks: >>> because it is architecturally unsound, inconsistent with the current >>> SIP >>> design approach, and leads to further unnecessary complexity in an >>> already too-complex protocol. >>> >>> >>> -- >>> Dean >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From Even.roni@huawei.com Mon Jul 27 08:00:33 2009 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 8FB723A6BC9 for ; Mon, 27 Jul 2009 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 xiW7lwgU5YSa for ; Mon, 27 Jul 2009 08:00:32 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B0E4028C266 for ; Mon, 27 Jul 2009 08:00:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNG00HV24CEIO@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 27 Jul 2009 23:00:14 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNG00JFL4CE5Y@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 27 Jul 2009 23:00:14 +0800 (CST) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNG00FLO4C7JM@szxml01-in.huawei.com>; Mon, 27 Jul 2009 23:00:14 +0800 (CST) Date: Mon, 27 Jul 2009 17:58:26 +0300 From: Roni Even In-reply-to: <4A6D6050.7060803@sipstation.com> To: 'Alan Johnston' , 'Leon Portman' Message-id: <000601ca0eca$b66b52f0$2341f8d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcoOkWkcgAT2JLBdTUue6BVMNm53rwAOP6og References: <4A69FD6A.4020205@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> <4A6D6050.7060803@sipstation.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 27 Jul 2009 15:00:33 -0000 Hi, I am not sure how REQ-021 will work if you want to address packet loss and control using RTCP. I suggest you look at the Topologies RFC 5117 for directions Roni Even > > > " o REQ-021 The mechanism MUST support the ability for the RC to > only > > perform media replication to the RS, without needing to decode or > mix > > audio/video/etc., and without needing to be an RTP agent. This > will > > allow the RC to replicate media at layers below RTP. Clearly, > such > > an RC mode would not be able to provide transcoding, or media > > injection from the RS back into the Recorded Session." > > > > Does this mean that you think that RTP is unsuitable for transporting > > media between the RS and RC? Clearly it isn't for IM, but I would > think > > that many of the functions of RTP are needed for audio and video > media. > > To understand this requirement will take more discussion. > > > > [LeonP] Actually it was Hadriel requirement. I believe it only means > that RC does not required to implement RTP stack, it can just fork RTP > packets on the network level (by hardware) > > > > Yes, I think I get that when I reread the requirement. This is a very > important requirement that has a huge impact on the scalability of the > system. > > > Thanks, > > Alan > > _______________________________________________ > > 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 drage@alcatel-lucent.com Mon Jul 27 08:08:12 2009 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 84F053A6B49 for ; Mon, 27 Jul 2009 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.406 X-Spam-Level: X-Spam-Status: No, score=-5.406 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 dOX5Q1JeFdmn for ; Mon, 27 Jul 2009 08:08:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 53FE23A6AE8 for ; Mon, 27 Jul 2009 08:08:11 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6RF7KDA006971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jul 2009 17:07:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 27 Jul 2009 17:07:20 +0200 From: "DRAGE, Keith (Keith)" To: Alan Johnston , Paul Kyzivat Date: Mon, 27 Jul 2009 17:07:17 +0200 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoOyL65XtaJ8E1tRGedP7l/F+PthwAAqbrQ Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <6FC29B49-B4CE-4155-A67C-DD94C87CC3FC@sipstation.com> <4A6DAC9D.7040903@cisco.com> <4A6DBD04.7070801@sipstation.com> In-Reply-To: <4A6DBD04.7070801@sipstation.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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 15:08:12 -0000 And just to note that this needs to map into the equivalent ISDN features. These are implicit, where I am saying: "if the place where this is delivere= d to cannot understand it, then throw it away", and explicit, where I am saying: "if the place where this is delivered cann= ot understand it, then fail the call". It doesn't need anything else, and there is no discovery mechanism in the I= SDN (apart from by making calls containing UUI explicit and seeing what fai= ls). regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: Monday, July 27, 2009 3:43 PM > To: Paul Kyzivat > Cc: dispatch@ietf.org; Hadriel Kaplan > Subject: Re: [dispatch] CCUS and History-Info (was Proposed=20 > Charter for CCUS - Call Control UUI for SIP) >=20 > Paul Kyzivat wrote: > > > > > > Alan Johnston wrote: > >> Dean, > >> > >> So basically, you want a different name for the header field? =20 > >> Otherwise the semantics seem identical to what is proposed. > > > > There at least needs to be some interoperable way to specify the=20 > > format of the data being passed. We have that with MIME, but when=20 > > using a header the mechanism needs to be reinvented, along=20 > with a way=20 > > to say "I don't understand that". > This is an excellent point. >=20 > The latest version of the mechanism draft has a way of=20 > specifying the purpose (application) and encoding, based on this need. >=20 > The requirements currently say that a UAC has to be able to=20 > discover if=20 > a UAS supports the UUI *mechanism*. The obvious way to do=20 > this is a=20 > SIP option tag. But do we need a requirement for a UAC to=20 > discover if a UAS supports a particular purpose/application? =20 > If the same UUI is encoded in different ways, do we need a=20 > way to say "you need to be able to support *one* of the data objects? >=20 > Thanks, > Alan >=20 >=20 > > > > Thanks, > > Paul > > > >> Thanks, > >> Alan > >> > >> > >> > >> On Jul 27, 2009, at 10:48 AM, Dean Willis=20 > > >> wrote: > >> > >>> Hadriel Kaplan wrote: > >>> > >>>> I think the retargeting and middlebox support issues are=20 > not really=20 > >>>> But the real problem is the semantics as you say - to me=20 > a request=20 > >>>> URI is information about the targeted resource or how to=20 > reach it,=20 > >>>> not information about the source resource. Since H-I is just a=20 > >>>> list of req-uri's, it's not the right place. > >>> > >>> I disagree. SIP is based on HTTP The Request URI encodes=20 > the request=20 > >>> being made by the UAC to the UAS. The CCUUI data is not=20 > germane to=20 > >>> SIP, it's just stuff being passed along the chain from UAC to UAS. > >>> > >>> Now, it might be reasonable to universally declare that=20 > SIP is, in=20 > >>> fact, NOT HTTP, and that it uses a different parameter passing=20 > >>> mechanism. If so, then what we would probably want to do=20 > is define a=20 > >>> new header field, perhaps "User-Parameters:", that is=20 > reserved for=20 > >>> user-to-user data consumed by applications. I'd be okay with that. > >>> > >>> > >>>> Really the technically *right* place would be in MIME, afaict -=20 > >>>> it's opaque application data just like geoloc, right? But=20 > >>>> pragmatically, the issues/problems with doing it in MIME were=20 > >>>> already covered and debated in sipping, and iirc=20 > consensus was: put it in a header. > >>>> > >>>> ISTM that we always complain about lack of running code,=20 > and here=20 > >>>> we have a case where there is running code from multiple=20 > vendors,=20 > >>>> and it's not fundamentally broken/un-sound. It ain't=20 > broken, why=20 > >>>> do we need to fix it? > >>> > >>> The same reason we shoud object to all layer-violation hacks: > >>> because it is architecturally unsound, inconsistent with=20 > the current=20 > >>> SIP design approach, and leads to further unnecessary=20 > complexity in=20 > >>> an already too-complex protocol. > >>> > >>> > >>> -- > >>> Dean > >> _______________________________________________ > >> 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 pkyzivat@cisco.com Mon Jul 27 08:09:54 2009 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 F272A3A6C49 for ; Mon, 27 Jul 2009 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 YFikQnKMYA8x for ; Mon, 27 Jul 2009 08:09:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EAF803A6B23 for ; Mon, 27 Jul 2009 08:09:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGNgbUpAZnmf/2dsb2JhbAC6W4gojhQFhA0 X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="51942431" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2009 15:09:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6RF9p2m001886; Mon, 27 Jul 2009 11:09:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RF9pbJ004841; Mon, 27 Jul 2009 15:09:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:09:51 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:09:50 -0400 Message-ID: <4A6DC33F.7050108@cisco.com> Date: Mon, 27 Jul 2009 11:09:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com> <4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com> <4A6DA80F.2070003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 15:09:50.0994 (UTC) FILETIME=[49EE1F20:01CA0ECC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13220; t=1248707391; x=1249571391; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20I-D=20Action=3Adraft-johns ton-sipping-cc-uui-08.txt |Sender:=20 |To:=20=22DRAGE,=20Keith=20(Keith)=22=20; bh=wLMy2MXsuJ0fdOjM2uB7JhMJig9+874T7iVD3jJRJ04=; b=qNjO7Gx0p720YU/dZg/pMHLwp+wVbCprHSRp4PNXb1qxVjoMTsysEK30+2 DtsD/54jeIFrSSdQ1WD4GR4tyR8tmN49Xtu1hveLwf/jXko+/DiczNl492Ja vSU6MXs3e/; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 27 Jul 2009 15:09:54 -0000 DRAGE, Keith (Keith) wrote: > 1st octet of the payload. Fine. But what does the first octet of the payload *mean*? Aren't the encodings corresponding to particular values of that octet defined somewhere? If so, how many of the 256 possible values are defined, and who controls how new values can be defined? I'm pretty sure it isn't IETF or IANA. Thanks, Paul > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, July 27, 2009 2:14 PM >> To: DRAGE, Keith (Keith) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-johnston-sipping-cc-uui-08.txt >> >> Keith, >> >> If this is *not* ISDN encoding, then where is the indication >> of what encoding is being used? Are you saying that this is a >> private agreement between the UAC and UAS, neither signaled >> nor negotiated? How can that possibly work? >> >> I thought the first byte of the value was a registered format >> indicator. >> >> Thanks, >> Paul >> >> DRAGE, Keith (Keith) wrote: >>> Just to respond to this bit of the message: >>> >>>>> Not quite. We are not making the assumption that both are >>>> gateways, >>>>> although that is possible. Most likely, one element is >> SIP enabled. >>>>> However, it is not a fully intelligent SIP endpoint - the basic >>>>> software and application (probably many years old) is >>>> unchanged but a >>>>> SIP interface (SIP trunk) has been added. As such, the SIP >>>> stack does >>>>> not know anything about the UUI as it is implementing >>>> exactly the ISDN >>>>> UUI service - the information is just pushed up the stack >>>> to another >>>>> application, and this application knows nothing about SIP. >>>> It still >>>>> thinks it is using an ISDN trunk. >>>> Then in the way I meant the question, both ends *are* gateways. >>>> >>>> But then if someone wishes to build native sip gear to >> plug into this >>>> environment, then it will still have to understand this isdn >>>> encoding. >>>> Perhaps that is the cruel truth, unless all the equipment >> is replaced >>>> at once. >>> I've said this before and I'll say it again. The bit being >> delivered to the end UE is not "isdn encoding". If it was >> ISDN encoding, then the ISDN / SIP gateway would be able to >> interpret it and map it into SIP. Rather it is some >> application sitting above the ISDN call control layer in the >> calling terminal, which is wishing to communicate with its >> peer application running in the destination SIP UA, or gateway. >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Saturday, July 04, 2009 12:39 AM >>>> To: Alan Johnston >>>> Cc: dispatch@ietf.org >>>> Subject: Re: [dispatch] I-D >>>> Action:draft-johnston-sipping-cc-uui-08.txt >>>> >>>> Hi Alan, >>>> >>>> responses inline. I've trimmed out the parts that don't >> require more >>>> discussion. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Alan Johnston wrote: >>>>> Paul, >>>>> >>>>> Thanks for your comments. See mine below. >>>>> >>>>> Thanks, >>>>> Alan >>>>> >>>>> Paul Kyzivat wrote: >>>>>> Hi Alan, >>>>>> >>>>>> I took a quick look at this doc and the requirements doc >>>> as well. I >>>>>> have a few thoughts: >>>>>> >>>>>> From section 1: >>>>>> >>>>>>> In the future, where both endpoints are intelligent >>>> SIP user agents, >>>>>>> it may be possible for them to understand and >>>> interpret the UUI data. >>>>>>> There may be some cases where the UUI information is >>>> relevant to SIP. >>>>>>> In this case, it might be worthwhile attempting to map >>>> UUI data to an >>>>>>> appropriate SIP header field or to standardize a new >>>> header field. >>>>>>> However, the requirements and use cases for this are >>>> different enough >>>>>>> from those described in this document that these two >> situations >>>>>>> should be examined separately. This document looks >> only at the >>>>>>> requirements and mechanisms for replicating the >>>> existing, widely used >>>>>>> and deployed ISDN UUI service. >>>>>> This *still* troubles me! >>>>>> Is the assumption here that *both* the UAC and UAS are >>>> gateways, so >>>>>> that this mechanism is solely for the tunneling of Q.931 >> and Q.763 >>>>>> UUI message over SIP? >>>>>> >>>>>> I get the impression that an important use case is where at least >>>>>> *one* end (probably the UAS) is a SIP device. In that >> case it will >>>>>> already be *necessary* for it to understand and >> interpret UUI data. >>>>>> And where there is redundancy between SIP data and the UUI >>>> data, it >>>>>> will need to resolve the discrepancy. >>>>> Not quite. We are not making the assumption that both are >>>> gateways, >>>>> although that is possible. Most likely, one element is >> SIP enabled. >>>>> However, it is not a fully intelligent SIP endpoint - the basic >>>>> software and application (probably many years old) is >>>> unchanged but a >>>>> SIP interface (SIP trunk) has been added. As such, the SIP >>>> stack does >>>>> not know anything about the UUI as it is implementing >>>> exactly the ISDN >>>>> UUI service - the information is just pushed up the stack >>>> to another >>>>> application, and this application knows nothing about SIP. >>>> It still >>>>> thinks it is using an ISDN trunk. >>>> Then in the way I meant the question, both ends *are* gateways. >>>> >>>> But then if someone wishes to build native sip gear to >> plug into this >>>> environment, then it will still have to understand this isdn >>>> encoding. >>>> Perhaps that is the cruel truth, unless all the equipment >> is replaced >>>> at once. >>>> >>>>>>> 5. Syntax for UUI Header Field >>>>>> ... >>>>>>> UUI = "User-to-User" HCOLON uui-data >>>> *(SEMI uui-param) >>>>>>> uui-data = token >>>>>>> uui-param = enc-param | cont-param | purp-param >>>> | generic-param >>>>>>> enc-param = "encoding=" ("hex" | token) >>>>>>> cont-param = "content=" ("isdn-uui" | token) >>>>>>> purp-param = "purpose=" ("isdn-interwork" | token) >>>>>> At the very least, I would request that this be expanded a >>>> little bit >>>>>> for future flexibility, by permitting the uui-data to be >> either a >>>>>> token or a string. While the encoding you have chosen works as a >>>>>> token, other encodings may need the additional flexibility >>>> of a string. >>>>>> uui-data = token | quoted-string >>>>> OK, I guess I'm OK with that. For the isdn-interwork >>>> purpose, we'll >>>>> require the token, but other applications could utilize the >>>> quoted string. >>>> >>>> I would hope that when the token encoding is sufficient, >> then either >>>> form would be accepted. Or it would perhaps be ok to specify for a >>>> particular encoding (hex) that the token encoding must be used. I >>>> don't see how the purpose has anything to do with it. >>>> >>>>>>> 6.3. Registration of SIP Option Tag >>>>>> This section registers the new option tag. But I find >>>> almost nothing >>>>>> that defines the semantics of the option. (Section 5 does >>>> include the >>>>>> following: >>>>>> >>>>>>> A UA that supports this feature and the "uui" option >>>> tag MUST support >>>>>>> the call flows in [johnston-dispatch-sip-cc-uui]... >>>>>> but that is pretty thin from a normative perspective. >>>>>> >>>>>> Of particular note, does support for the option tag mean >>>> support for >>>>>> the particular encoding, content, and purpose included in this >>>>>> document? Or does it only mean support for the header and >>>> params in >>>>>> the abstract? (That wouldn't be very useful.) >>>>> Yes, this needs clarification. I'd suggest we define the >>>> option tag >>>>> to be uui-isdn which means it understands the header >> field and the >>>>> isdn-interwork purpose, and the call flows, including >> escaping into >>>>> redirection and Refer-To URIs. >>>> I'd like to hear some other opinions on whether to have >> tag per param >>>> for tag, or a tag for the combination of param values. I >> think I'm ok >>>> with what you propose. >>>> >>>>>> I don't see how it can mean support for some other yet to >>>> be defined >>>>>> values for those. Yet if it only means support for the >>>> current ones, >>>>>> then how will one indicate support for future ones? >>>>>> >>>>>> The only way out of this that I can see is to have >>>> separate options, >>>>>> either for particular values of each parameter, or for >> particular >>>>>> combinations of values of all the parameters. >>>>> New applications using this header field would have the option of >>>>> defining a new SIP option tag which would mean support for >>>> the header >>>>> field and their new purpose. >>>>> >>>>>> So you might have options uui-purpose-isdn-interwork, >>>>>> uui-content-isdn, and uui-encoding-hex. Or you might just >>>> have option >>>>>> uui-isdn-interwork that means the combination. >>>>> I think the latter. I see it as a hierarchy - the application or >>>>> purpose is the top one. Each purpose has a number of >>>> contents that it >>>>> supports. Each content has a number of encoding schemes it >>>> supports. >>>> >>>> I guess I'm ok with that, pending nailing down the definition of >>>> "purpose". >>>> >>>>>> I also am not finding much explanation of the semantics of the >>>>>> content and purpose parameters. I can only extrapolate >>>> from a single >>>>>> example of each, which I'm having trouble doing. >>>>>> >>>>>> I'm guessing that 'content' must refer to the precise >>>> syntax of the >>>>>> contained data, after decoding. So presumably it must map >>>> onto some >>>>>> particular spec. For isdn-uui, would that be [Q931] or >>>> [Q763]? If so, >>>>>> shouldn't it refer to something specific in that document? >>>>> Not really. In this case, isdn-uui effectively means >> "opaque data" >>>>> which is how ISDN defines the UUI - it is completely undefined, >>>>> necessarily so by the strict layering used in the ISDN >> application. >>>> I don't believe you! >>>> >>>> If that is the case, then the UAC and UAS must have a private side >>>> agreement about what the isdn-uui content means. Is that >> really what >>>> you mean? >>>> >>>> You already state that the first byte is a protocol discriminator. >>>> There must also be something, somewhere, that specifies >> the mapping >>>> from a particular value for that byte to a particular >>>> protocol/format. If there is, then that should be part of the >>>> definition of this content. >>>> >>>>>> 'purpose' is even less clear to me. Does it refer to why >>>> it is being >>>>>> included? Or what is to be done with it? If received by a >>>> UA that is >>>>>> not an ISDN gateway, how can it decide if this is >>>> something it should >>>>>> be trying to process? Is it still ISDN interworking if >> neither the >>>>>> UAC nor UAS is connected to an ISDN network? >>>>> The purpose is the application using the UUI. Others have >>>> expressed >>>>> an interest in carrying other data in the header field, in >>>> which case >>>>> a new purpose would be defined. I'll see if I can think of >>>> an example one. >>>> >>>> So are you saying that a particular call center application might >>>> constitute a distinct "purpose"? >>>> >>>>> Basically, if two UAs both support the header but have different >>>>> applications generating and consuming the UUI, it will not >>>> work. This >>>>> is not a SIP failure, and there is nothing SIP can do about >>>> it. But >>>>> this purpose header field allows the UAs to detect this condition. >>>> In that case, perhaps "isdn-interwork" isn't really a >> single purpose >>>> at all, unless any two pieces of equipment that support >> that purpose >>>> can then interwork without knowing any more about each other. >>>> >>>>>> Suppose I was developing a sophisticated UA that >>>> potentially might be >>>>>> usable by a call center operator. How should >>>> purpose=isdn-interwork >>>>>> affect the operation of this device? >>>>> To make it work in today's contact center applications, >> supporting >>>>> isdn-interwork would likely make it work in an application, >>>> provided >>>>> the appropriate call center application also ran on it. >>>> Some contact >>>>> centers do not use ISDN UUI, instead they use all kinds >> of really, >>>>> really ugly CTI protocols running in parallel. >>>> Yes, I know! :-( >>>> >>>>> This is a way of moving >>>>> those to the ISDN model, and from there to a more >>>> intelligent endpoint >>>>> SIP model. >>>>> >>>>>> Thanks, >>>>>> Paul >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> From chris.labarbera@citi.com Mon Jul 27 08:10:49 2009 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 71C0B28C113 for ; Mon, 27 Jul 2009 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 SJyNu6e-xqhM for ; Mon, 27 Jul 2009 08:10:48 -0700 (PDT) Received: from mail.citigroup.com (mail11.ssmb.com [199.67.179.105]) by core3.amsl.com (Postfix) with ESMTP id E64A028C120 for ; Mon, 27 Jul 2009 08:10:47 -0700 (PDT) Received: from imbarc-nj01.nj.ssmb.com (imbarc-nj01.nj.ssmb.com [150.110.115.169]) by imbaspam-ny05.iplex.ssmb.com (8.13.8/8.13.8/SSMB_EXT/ev: 24741 $) with ESMTP id n6RFAUSs022252; Mon, 27 Jul 2009 15:10:31 GMT Received: from mailhub-nj03-1.nj.ssmb.com (mailhub-nj03-1.nj.ssmb.com [150.110.237.160]) by imbarc-nj01.nj.ssmb.com (8.13.8/8.13.8/SSMB_QQQ_IN/1.1) with ESMTP id n6RFAOlF024033; Mon, 27 Jul 2009 15:10:24 GMT Received: from exnjiht02.nam.nsroot.net (EXNJIHT02.nam.nsroot.net [150.110.165.228]) by mailhub-nj03-1.nj.ssmb.com (8.13.8/8.13.8/CG_HUB) with ESMTP id n6RFALK4013737; Mon, 27 Jul 2009 15:10:24 GMT Received: from exnjht04.nam.nsroot.net (150.110.165.224) by exnjiht02.nam.nsroot.net (150.110.165.228) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Jul 2009 11:10:23 -0400 Received: from extxht01.nam.nsroot.net (169.185.148.155) by exnjht04.nam.nsroot.net (150.110.165.224) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Jul 2009 11:10:23 -0400 Received: from extxmb32.nam.nsroot.net ([165.203.255.102]) by extxht01.nam.nsroot.net ([169.185.148.155]) with mapi; Mon, 27 Jul 2009 10:10:22 -0500 From: "Labarbera, Chris " To: Roni Even , "'Alan Johnston'" , "'Leon Portman'" Date: Mon, 27 Jul 2009 10:10:20 -0500 Thread-Topic: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoOkWkcgAT2JLBdTUue6BVMNm53rwAOP6ogAABU32A= Message-ID: <2BA3AF6003BF4A488DA5705E23B36AAF16F3CB0A2E@extxmb32.nam.nsroot.net> References: <4A69FD6A.4020205@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> <4A6D6050.7060803@sipstation.com> <000601ca0eca$b66b52f0$2341f8d0$%roni@huawei.com> In-Reply-To: <000601ca0eca$b66b52f0$2341f8d0$%roni@huawei.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 X-WiganSS: 01000000010017exnjht04.nam.nsroot.net ID0044<2BA3AF6003BF4A488DA5705E23B36AAF16F3CB0A2E@extxmb32.nam.nsroot.net> X-Scanned-By: MIMEDefang 2.52 on 172.27.136.24 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 27 Jul 2009 15:22:23 -0000 We need to look at this in the big picture. If you want to address packet l= oss and control using RTCP, you will most likely use the services of a sess= ion border controller to act as the B2BUA and leverage the services of the = SBC to manage RTCP and MOS scores for the media. The whole context of the d= ispatch recording method is to provide a forking point at a large ingress p= oint such as a SBC. In this model, a SBC can deliver 15,000 SIP sessions to= a series of enterprise PBX/ACD systems and the dispatch method can be used= to selectively fork media to a voice recorder at great scale and capacity.= The overall goal of this model is to provide an effective and scalable sol= ution for recording in high availability (transparently) without putting an= y additional demand on the PBX systems downstream from the recorder. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Roni Even Sent: Monday, July 27, 2009 10:58 AM To: 'Alan Johnston'; 'Leon Portman' Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-p= rotocol-req-00 Hi, I am not sure how REQ-021 will work if you want to address packet loss and control using RTCP. I suggest you look at the Topologies RFC 5117 for directions Roni Even > > > " o REQ-021 The mechanism MUST support the ability for the RC to > only > > perform media replication to the RS, without needing to decode or > mix > > audio/video/etc., and without needing to be an RTP agent. This > will > > allow the RC to replicate media at layers below RTP. Clearly, > such > > an RC mode would not be able to provide transcoding, or media > > injection from the RS back into the Recorded Session." > > > > Does this mean that you think that RTP is unsuitable for transporting > > media between the RS and RC? Clearly it isn't for IM, but I would > think > > that many of the functions of RTP are needed for audio and video > media. > > To understand this requirement will take more discussion. > > > > [LeonP] Actually it was Hadriel requirement. I believe it only means > that RC does not required to implement RTP stack, it can just fork RTP > packets on the network level (by hardware) > > > > Yes, I think I get that when I reread the requirement. This is a very > important requirement that has a huge impact on the scalability of the > system. > > > Thanks, > > Alan > > _______________________________________________ > > 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 rjsparks@nostrum.com Mon Jul 27 08:46:35 2009 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 9F8BF3A6B5E for ; Mon, 27 Jul 2009 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 JVf132pr52LM for ; Mon, 27 Jul 2009 08:46:35 -0700 (PDT) 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 828833A6B15 for ; Mon, 27 Jul 2009 08:46:34 -0700 (PDT) Received: from dhcp-26f2.meeting.ietf.org (dhcp-26f2.meeting.ietf.org [130.129.38.242]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6RFkRGi023102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Jul 2009 10:46:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> From: Robert Sparks To: dispatch mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 17:46:26 +0200 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 130.129.38.242 is authenticated by a trusted mechanism) Subject: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 over Lunch on Friday 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, 27 Jul 2009 15:46:35 -0000 Room 300 over lunch on Friday From mohamed.boucadair@orange-ftgroup.com Mon Jul 27 13:12:18 2009 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 F2E0A3A6C1D for ; Mon, 27 Jul 2009 13:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 4St4R0nUpv4A for ; Mon, 27 Jul 2009 13:12:17 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C38743A6974 for ; Mon, 27 Jul 2009 13:12:16 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 22:12:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA0EF6.87D0D267" Date: Mon, 27 Jul 2009 22:12:10 +0200 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC144120A@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-dispatch-ipv6-atypes-00.txt Thread-Index: AcoO5kUahx0fa8gHRd+yxV7+m5zI0wAD+2Uw From: To: X-OriginalArrivalTime: 27 Jul 2009 20:12:15.0060 (UTC) FILETIME=[88A2E140:01CA0EF6] Subject: [dispatch] TR: I-D Action:draft-boucadair-dispatch-ipv6-atypes-00.txt 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, 27 Jul 2009 20:12:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0EF6.87D0D267 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, A new version of the atypes media feature tag draft has been submitted. This draft has been discussed in SIPPING mailing list: = http://www.ietf.org/mail-archive/web/sipping/current/msg16718.html. Comments and suggestions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : lundi 27 juillet 2009 20:15 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-dispatch-ipv6-atypes-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : The atypes media feature tag for Session Initiation = Protocol (SIP) Author(s) : M. Boucadair, et al. Filename : draft-boucadair-dispatch-ipv6-atypes-00.txt Pages : 16 Date : 2009-07-27 This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of = the UA (User Agent) and can aid the routing process and ease the = invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-dispatch-ipv6-atypes-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. ------_=_NextPart_001_01CA0EF6.87D0D267 Content-Type: application/octet-stream; name="draft-boucadair-dispatch-ipv6-atypes-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-dispatch-ipv6-atypes-00.URL Content-Disposition: attachment; filename="draft-boucadair-dispatch-ipv6-atypes-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItZGlzcGF0Y2gtaXB2Ni1hdHlwZXMtMDAudHh0DQo= ------_=_NextPart_001_01CA0EF6.87D0D267-- From dean.willis@softarmor.com Mon Jul 27 15:24:41 2009 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 4DF743A68F0 for ; Mon, 27 Jul 2009 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, 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 zQuI1lJXTCvx for ; Mon, 27 Jul 2009 15:24:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 16C173A6841 for ; Mon, 27 Jul 2009 15:24:40 -0700 (PDT) Received: from [78.64.69.187] (host-78-64-69-187.homerun.telia.com [78.64.69.187]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6RMOZpS020701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 17:24:38 -0500 Message-ID: <4A6E2921.7080507@softarmor.com> Date: Mon, 27 Jul 2009 17:24:33 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 22:24:41 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- From: Dean Willis >> [mailto:dean.willis@softarmor.com] Sent: Monday, July 27, 2009 4:49 >> AM To: Hadriel Kaplan >> >> I disagree. SIP is based on HTTP The Request URI encodes the >> request being made by the UAC to the UAS. > > Then you might as well argue the request-URI should encode MIME > bodies. The UUI is not a part of the resource being addressed in any > way, and thus not a part of a Uniform Resource Identifier. I take it you've never written an HTTP application using something like the Common Gateway Interface (CGI) for parameter passing. Perhaps taking some time to learn the history here would be helpful for you, so that you stop making patently incorrect assertions about what can be in a request URI. Let's look at the request-URI used by the IETF tools team's draft search page. Take, for example: http://tools.ietf.org/id/?doc=common Everything up to the first / is network routing information -- it finds the host responsible for the application. The /id/ part identifies the application. That might arguably be "application routing", but it is not NETWORK routing. It doesn't create Via header fields in the SIP request. The "?doc=common" part is parameters being delivered to the "id" application. The question mark is the common CGI delimiter for parameters. This delimits a parameter having the name "doc" and taking the value "common", thereby telling the id application to search for all docs having the string "common" in their name. Note that, in your parelance, "id" and "common" are NOT part of the resource being addressed in any way. Yet, they are encoded into the resource, in such a way that they can easily be presented in writing, pasted onto a business card, or whatever else you might want to do with a URI. Nowhere in the HTTP spec (nor in the HTTCP CGI spec at http://hoohoo.ncsa.illinois.edu/cgi/interface.html) is "doc" or "common" defined. Rather, the specification defines a syntax for parameter names and parameter values, and leaves the actual choice of parameter names and encoding of values up to the application. This has allowed many millions of HTTP applications to be developed without having to amend the HTTP specification for each one of them. Back when we were working on the SIP that eventually became RFC 2543, we intended SIP to support a CGI-type invocation model. We just didn't do it right, for a number of reasons mostly having to do with failed communication between the people driving the spec. > > >> Now, it might be reasonable to universally declare that SIP is, in >> fact, NOT HTTP, and that it uses a different parameter passing >> mechanism. > > Well, I'll probably be flamed, but afaict it is not HTTP in most > every important way. It does a LOT of things differently. That ship > has sailed. It is far closer to email (with some weird combo of SMTP > and POP3), if anything. Possibly true. But we need SOME equivalent of HTTP's parameter passing model, else we are stuck with having to extend SIP again and again for every possible application, and that's just a ridiculous idea. > > >> If so, then what we would probably want to do is define a new >> header field, perhaps "User-Parameters:", that is reserved for >> user-to-user data consumed by applications. I'd be okay with that. > > That was actually how I interpreted the semantic notion of the > User-to-User header. That is, I think, the intent in Alan's current draft. He's not at all far off from what I think would be a reasonable solution. There's some guidance needed on semantic negotiation and how to say "I don't understand the parameters you have sent me", but it should be pretty straightforward to remedy. I find this approach much more attractive for user-to-user parameter passing than the idea that we encode the parameters HTTP-style in the request URI, then have the UAS wade backwards thru the History-Info stack until it finds them. But our current consensus is to do just exactly that: so I'm using CC-UUI to challenge that consensus. Either we can use request-URI parameters and History-Info for parameter passing (in which case we should do CC-UUI that way), or we develop the more robust mechanism that SIP has long needed (and that Alan has a good start on). I'm in favor of the latter, but will accept either. What I won't accept is yet another application-specific SIP extension header that works for CC-UUI but doesn't solve the general problem, coupled with a head-in-sand insistence that we've solved the general problem using History-Info, despite having proved (by the need to develop yet another special extension for CC-UUI) that we in fact have NOT solved the general UAC-to-UAS parameter passing problem. -- Dean From dean.willis@softarmor.com Mon Jul 27 15:30:47 2009 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 74D193A6C82 for ; Mon, 27 Jul 2009 15:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 dJLeRtrgLKKU for ; Mon, 27 Jul 2009 15:30:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A84613A68F0 for ; Mon, 27 Jul 2009 15:30:46 -0700 (PDT) Received: from [78.64.69.187] (host-78-64-69-187.homerun.telia.com [78.64.69.187]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6RMUebu020747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 17:30:43 -0500 Message-ID: <4A6E2A8E.60105@softarmor.com> Date: Mon, 27 Jul 2009 17:30:38 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Alan Johnston References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <6FC29B49-B4CE-4155-A67C-DD94C87CC3FC@sipstation.com> <4A6DAC9D.7040903@cisco.com> <4A6DBD04.7070801@sipstation.com> In-Reply-To: <4A6DBD04.7070801@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 27 Jul 2009 22:30:47 -0000 Alan Johnston wrote: > The requirements currently say that a UAC has to be able to discover if > a UAS supports the UUI *mechanism*. The obvious way to do this is a > SIP option tag. But do we need a requirement for a UAC to discover if a > UAS supports a particular purpose/application? If the same UUI is > encoded in different ways, do we need a way to say "you need to be able > to support *one* of the data objects? We certainly need a way to say "I understand the parameter you have sent me, but the value you gave it doesn't make any sense". It might also be ok to have a criticality indicator on a parameter, and I can envision a subset-selection indication that wouldn't be too hairy, but I'm having a hard time coming up witha real use case. It would be a lot easier to write the applications to have positive resopnse: that is, if the UAS understands the parameter in question and the value makes sense, it says so affirmatively in the response. Further, it might indicate which of several alternatives it preferred. This provides a fail-safe, backward-compatible mechanism that gives debugging feedback, but at much less complexity cost. -- Dean From ranjit@motorola.com Mon Jul 27 22:58:53 2009 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 488C23A6837 for ; Mon, 27 Jul 2009 22:58:53 -0700 (PDT) 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 73LF8l2QQO1R for ; Mon, 27 Jul 2009 22:58:52 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 5FBA53A68CD for ; Mon, 27 Jul 2009 22:58:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-55.messagelabs.com!1248760728!29356921!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4577 invoked from network); 28 Jul 2009 05:58:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2009 05:58:48 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n6S5wjP1004846 for ; Mon, 27 Jul 2009 22:58:47 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n6S5wjRa018004 for ; Tue, 28 Jul 2009 00:58:45 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n6S5wihK017999 for ; Tue, 28 Jul 2009 00:58:44 -0500 (CDT) 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_01CA0F48.6A1D707F" Date: Tue, 28 Jul 2009 13:58:21 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted Thread-Index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3g== From: "Avasarala Ranjit-A20990" To: X-CFilter-Loop: Reflected Subject: [dispatch] New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted 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, 28 Jul 2009 05:58:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0F48.6A1D707F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info=20 It can be accessed at: http://www.ietf.org/staging/draft-avasarala-dispatch-comm-div-notificati on-01.txt This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604. Regards Ranjit ------_=_NextPart_001_01CA0F48.6A1D707F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of = "draft-avasasarala-dispatch-comm-diversion-info" draft = submitted

Hi All

We have submitted an = updated version of draft-avasasarala-dispatch-comm-diversion-info =

It can be accessed = at: http://www.ietf.org/staging/draft-avasarala-dispatch-comm-= div-notification-01.txt

This draft proposes a = SIP Event package for Communication Diversions Notification Information = and conforms to procedures and schema described in 3GPP TS = 24.604.

Regards
Ranjit

------_=_NextPart_001_01CA0F48.6A1D707F-- From sdoken@qualcomm.com Tue Jul 28 00:30:35 2009 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 3BEF23A6CF3 for ; Tue, 28 Jul 2009 00:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_33=0.6, 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 8avCsomPh3QG for ; Tue, 28 Jul 2009 00:30:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A59823A6CFA for ; Tue, 28 Jul 2009 00:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1248766235; x=1280302235; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "Jain,=20Rajnish"=20,=0D=0A=20=20 =20=20=20=20=20=20Vijay=20Gurbani=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"dispatch@ietf.or g"=20|Date:=20Tue,=2028=20Jul=202009 =2000:30:25=20-0700|Subject:=20RE:=20[dispatch]=20Session =20Recording=20in=20SIP|Thread-Topic:=20[dispatch]=20Sess ion=20Recording=20in=20SIP|Thread-Index:=20Acny7zk28PigrO +0SryRcGZzpsB+WwLm/JUQAgaJJ4AAo1zOIAGFhHsQ|Message-ID:=20 |References:=20<4A3F03F6.6060505@alcatel-l ucent.com>=0D=0A=20=0D=0A=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5690"=3B=20a=3D"21315935"; bh=jPGk0dCCdBXYXHTsPnbb4oazAkoVimVR2VUl5xDqbvQ=; b=B84j77FDzoxhFW/JJhLOEqsfTYY4XdkOEd/3OPcyOG4ooJ6H+HxUqxAs vleYw08f13p1Dppitz1F5YYhD6DXfD8LOv/QGUEtU4idie84w4Umh+A4p WjIKj1sOk7wJ2tpBbBELuUROtx+zhEMFjfFFKKb1fZxYV2fy9eFEmClDk M=; X-IronPort-AV: E=McAfee;i="5300,2777,5690"; a="21315935" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2009 00:30:35 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6S7UYFt002933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 00:30:34 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6S7UUHF027503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jul 2009 00:30:34 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Tue, 28 Jul 2009 00:30:29 -0700 From: "Doken, Serhad" To: "Jain, Rajnish" , Vijay Gurbani , "dispatch@ietf.org" Date: Tue, 28 Jul 2009 00:30:25 -0700 Thread-Topic: [dispatch] Session Recording in SIP Thread-Index: Acny7zk28PigrO+0SryRcGZzpsB+WwLm/JUQAgaJJ4AAo1zOIAGFhHsQ Message-ID: References: <4A3F03F6.6060505@alcatel-lucent.com> 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] Session Recording in SIP 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, 28 Jul 2009 07:30:35 -0000 > -----Original Message----- > From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] > Sent: Monday, July 20, 2009 5:51 AM > To: Doken, Serhad; Vijay Gurbani; dispatch@ietf.org > Subject: RE: [dispatch] Session Recording in SIP >=20 > Hi, >=20 > Thanks for your detailed comments. Please see inline: >=20 > > -----Original Message----- > > From: Doken, Serhad [mailto:sdoken@qualcomm.com] > > Sent: Friday, July 17, 2009 3:56 AM > > To: Jain, Rajnish; Vijay Gurbani; dispatch@ietf.org > > Subject: RE: [dispatch] Session Recording in SIP > > > > I read this draft and following are my comments : > > > > Section 3 Definitions > > > > Perhaps Recording Server(RS) should simply be called Recorder. I see > the > > note on the last sentence however as long as definitions refer to > Client and > > Server, it will always imply to the reader to think that RS is the > server. >=20 > Naming these things is always a bit tricky. If we called the RS simply > the Recorder given your reasoning, then the RC should also be named > differently (because the RC can act as the "server side" of the SRP > signaling). The RS naming is a bit akin to the term "Media Server". If > there is enough confusion on RS then, we can consider renaming it. Indeed, I think RC could be renamed as well since it is not a pure client a= nd can be a server at times. Using, Recording Client and Recording Server a= t section 1 before their definitions are given in Section 2 adds to the con= fusion. I would offer something like Recorder and (Recorded Media) Forker w= hich is self explanatory. >=20 > > The statement that SRP may be SIP is an understatement since the > definition > > for RC already referred to as a SIP UA/B2BUA. >=20 > This will be clarified in subsequent revisions when we'll say that SRP > is indeed SIP. >=20 > > Dynamic Recording, if the recording session is started and ended at > random > > points on demand, its length will not be the same as actual media > session. >=20 > Ok. We can clarify this. >=20 > > Persistent Recording, it is not clear what is meant by "system start > up". Is > > "system" referring to RC or RS ? >=20 > It meant that when both devices become functional. We can clarify this. It'll probably need more than functional, at a minimum registered/can make-= receive calls/process media. >=20 > > Depending on the answer, I am curious how are these persistent > recording > > sessions are correlated to many active media sessions and what would > be > > mechanism to keep them alive ? >=20 > The data over the call metadata interface will offer the correlation. A > simple way to keep SRP persistent sessions alive is through the SIP > session-timers. >=20 > What is the number of persistent recording > > sessions per RC/RS ? >=20 > That's an implementation-dependent choice. Obviously, however as I referred to in my subsequent question below, this m= ay have implications scaling up. If I have a device with high number of sim= ultaneous calls capability, media forker almost needs to keep that many per= sistent recording sessions and refresh them all the time by session timers.= A bunch of race conditions may occur and it may be a drain of resources on= the device that is doing the media forking especially when there is no act= ual session. Moreover, there will be certain assumptions made for such pers= istent recording sessions such as the codec used for the media session etc. =20 >=20 > > Perhaps implications of this should be covered somewhere else, maybe > in the > > requirements section ? > > > > Section 5 Requirements > > > > REQ-006 Not a good idea to talk about the solution here and how some > RC > > implementations handle the problem. >=20 > That note is only informative text. I guess we can take it out. >=20 > > Perhaps REQ-010 and 011 can be combined into one by just saying "over > a > > single or separate". >=20 > Fine. Will change this. >=20 > > REQ-018 can be extended to say that the mechanism MUST support the > ability > > to find out the associated recorded session(s) given that one(for > instance > > RS) is only aware of recording session(s). I'd rather prefer this to > be a > > separate requirement. >=20 > The RS is aware of the recorded session metadata. REQ-018 is a bit > broad in the sense that it talks about correlation in either direction > (i.e. from recorded sessions to recording sessions and vice-versa). I > think your comment is about splitting the two directions, right? Yes >=20 > > I have another requirement in mind : The mechanism MUST support the > ability > > to setup recording sessions that will record different conversation > > directions of the Recorded session(s) from RC(s) and they too should > be > > correlated accordingly. For instance, while an agent is talking to a > > customer, there should be a way to setup two recording sessions, one > > carrying the media from agent towards customer and vice versa for the > other. > > Furthermore, these recording sessions should be marked as such in > SRP. >=20 > Yes, this is needed. This requirement was actually in there and somehow > got removed in one of the edits. We'll add this. >=20 > > REQ-021 talks about a mode where RC just forks media to RS. However, > there > > is value in studying transcoding, media incompatibility use cases and > see if > > there are requirements they bring given that RS/RCs are/will most > likely > > have different media capabilities. >=20 > REQ-021 is primarily about a middle-box type of RC that forks the > media. The RC vendors in this case want their boxes to be optimal and > scalable by doing as little media processing as possible. REQ-021 isn't > precluding the use cases that you mentioned, but I think it'll make > sense to address such use cases in this document. >=20 > > If recorded session media is stopped/temporarily interrupted due to > problems > > or features invoked on it(recording session is put on hold or started > a > > conferencing or transfer operation), how does that affect the already > setup > > recording session(s) ? >=20 > I think that'll largely depend on the RC/RS implementations and the > nature of the SRP sessions. For instance, if the recording sessions are > persistent and the RC puts recorded session media on hold, then it RC > MAY reINVITE the RS and put the recording session media on hold or it > MAY just temporarily stop sending such media (silence suppression) to > the RS. In that case, the recorded session and the persistent recording sessions ne= ed to be synchronized back during resume which may bring the media clipping= problem that persistent recording attempted to solve in the first case. Regards, Serhad Doken >=20 > > Nit : > > > > Section2, sentence that starts with "that draft focuses on the > mechanism to > > provide the SRTP...." is odd. It is clear that srtp-key draft is not > for > > session recording, so no need to state the obvious. >=20 > Ok. We can change some wording here. >=20 > Thanks, > Raj >=20 > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the > sender that you have received it in error. Unintended recipients are > prohibited from taking action on the basis of information in this e- > mail.E-mail messages may contain computer viruses or other defects, may > not be accurately replicated on other systems, or may be intercepted, > deleted or interfered with without the knowledge of the sender or the > intended recipient. If you are not comfortable with the risks > associated with e-mail messages, you may decide not to use e-mail to > communicate with IPC. IPC reserves the right, to the extent and under > circumstances permitted by applicable law, to retain, monitor and > intercept e-mail messages to and from its systems. From gonzalo.camarillo@ericsson.com Tue Jul 28 00:44:38 2009 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 33B833A6ABC for ; Tue, 28 Jul 2009 00:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 n6VV-7j4LSiy for ; Tue, 28 Jul 2009 00:44:37 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 30CB43A696E for ; Tue, 28 Jul 2009 00:44:36 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-68-4a6eac653460 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 0E.9A.18827.56CAE6A4; Tue, 28 Jul 2009 09:44:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:44:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:44:36 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 990AB2595; Tue, 28 Jul 2009 10:44:36 +0300 (EEST) Message-ID: <4A6EAC64.4070500@ericsson.com> Date: Tue, 28 Jul 2009 09:44:36 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: dispatch mailing list References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> In-Reply-To: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 07:44:36.0929 (UTC) FILETIME=[41850B10:01CA0F57] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 over Lunch on Friday 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, 28 Jul 2009 07:44:38 -0000 Hi, since we are now allowed to bring food into the building, we will run this meeting from 12:00 to 13:00 so that people can either have a quick lunch from 11:30 to 12:00 or grab some food somewhere and bring it to the meeting. Cheers, Gonzalo Robert Sparks wrote: > Room 300 over lunch on Friday > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From sdoken@qualcomm.com Tue Jul 28 00:47:27 2009 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 B19B93A6ABC for ; Tue, 28 Jul 2009 00:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 UhZ5Et1EavQo for ; Tue, 28 Jul 2009 00:47:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3C0563A67BD for ; Tue, 28 Jul 2009 00:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1248767248; x=1280303248; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 Leon=20Portman=20,=20Alan=20Johnst on=20,=0D=0A=20=20=20=20=20=20=20=20 "dispatch@ietf.org"=20|Date:=20Tue,=20 28=20Jul=202009=2000:47:04=20-0700|Subject:=20RE:=20[disp atch]=20Comments=09on=0D=0A=09draft-jain-dispatch-session -recording-protocol-req-00|Thread-Topic:=20[dispatch]=20C omments=09on=0D=0A=09draft-jain-dispatch-session-recordin g-protocol-req-00|Thread-Index:=20AcoMjLJ6ThzVzaclTwCm7I3 jEBcc0QBBkppwAHDEl3A=3D|Message-ID:=20 |References:=20<4A69FD6A.4020205@sipstation.com>=0D=0A=20 <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice .com>|In-Reply-To:=20<07465C1D981ABC41A344374066AE1A2C37D 51541F2@TLVMBX01.nice.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5690"=3B=20a=3D"21316377"; bh=reZ+y23W/Udb+/0girypBG89X4PRE+yo1Ww37BQJf4k=; b=vYtyEkFaXO3aiwVg+IQ75po0cCwB9AIVU3C7XVq/NWA9UIBNwwTkSs0x VMHESEBogxWAqJDFIAOyBpurq/3li1huCjCiiPZBFiCj2YGEVS7FuLyxO Ch3vzSjUTee4PHaz65tSLn6F7pdbIbn2WRfpPb/3HLDC86yM9KH/S2e4q o=; X-IronPort-AV: E=McAfee;i="5300,2777,5690"; a="21316377" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2009 00:47:07 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6S7l6cZ026342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 00:47:07 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6S7l65d028376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jul 2009 00:47:06 -0700 (PDT) Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Tue, 28 Jul 2009 00:47:05 -0700 From: "Doken, Serhad" To: Leon Portman , Alan Johnston , "dispatch@ietf.org" Date: Tue, 28 Jul 2009 00:47:04 -0700 Thread-Topic: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppwAHDEl3A= Message-ID: References: <4A69FD6A.4020205@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.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 Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 28 Jul 2009 07:47:27 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Saturday, July 25, 2009 7:10 PM > To: Alan Johnston; dispatch@ietf.org > Subject: Re: [dispatch] Comments on draft-jain-dispatch-session- > recording-protocol-req-00 >=20 > Alan, Hi >=20 > Thanks for the comments. >=20 > Please see below my answers >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Alan Johnston > Sent: Friday, July 24, 2009 9:29 PM > To: dispatch@ietf.org > Subject: [dispatch] Comments on draft-jain-dispatch-session-recording- > protocol-req-00 >=20 > Here are my comments on this draft. >=20 > Overall, I think this draft is an excellent start at the requirements > for this important topic. I look forward to future discussions of > charter text so we can get started on the work. >=20 > Section 2: >=20 > " Another, related IETF draft is draft-wing-sipping-srtp-key > [I-D.wing-sipping-srtp-key], which describes an approach for > providing SRTP session keys to a recorder-type server. That draft > focuses on the mechanism to provide the SRTP session key, rather > than > the mechanism to invoke and sustain recording sessions themselves." >=20 > draft-wing-sipping-srtp-key actually has a lot of discussion, including > call flows showing how recording sessions can be established. Also, > this document has four recording modes discussed, which I think should > be discussed in this document. Two are mentioned without really > explaining them, and two others are implied by various requirements. >=20 > [LeonP] Yes, for the protocol draft, we will need to combine all of the > approaches and make sure that we covered all use cases >=20 > Section 3: >=20 > " Recording Session: The session created between an RC and RS for the > purpose of recording a Recorded Session. The Recorded Session may > itself be based on SIP, but it is a separate session from the > Recording Session. >=20 > Recorded Session: A session created between a UAC and UAS that is > recorded by the RC and RS systems." >=20 >=20 > These two terms only differ by their tense, yet I think one refers to a > signaling session and the other refers to a media session. If so, > better terms and definitions are needed. If not, we need a term for > the > actual recorded media. Also, there are (at least) two sessions here - > the one between the UAs and the Recording Session - in a few places I > suspect the two are being confused. >=20 > [LeonP] Actually Recording Session relates to both SIP and Media that > is forked to the recording server and Recorded Session is actually the > original conversation between two UAs. These two are exactly the two > sessions that you are describing. >=20 > " Dynamic Recording: Dynamic recording is a mode of recording where > the > recording sessions are established on an as needed basis. The > length > of these sessions is typically same as the length of the actual > media > sessions. >=20 > Persistent Recording: Persistent recording is a mode of recording > where the recording sessions are established at system start-up and > kept-alive from that point on. The length of these sessions is > independent from the length of the actual recorded media sessions. > Persistent recording sessions avoid issues such as media clipping > that can occur due to delays in recording session establishment." >=20 > These terms need more explanation as I can think of multiple things > they > might mean. For example, when you say "session" do you mean a > signaling > session or media session? When you talk about avoiding media clipping, > do you mean that media is always sent by the RC to the RS regardless of > whether there is any media? >=20 > [LeonP] Yes, by session we mean both legs: signaling and media. And in > Persistent Recording mode, the Recording SIP session supposed to stay > connected even there is not actual connected sessions for the specific > recorded UA. >=20 > Figures could use Figure numbers and labels. Also, it would be worth > showing which is the RC and which is the RS in them. >=20 > Section 5 >=20 > " o REQ-001 The mechanism MUST support the ability to perform > persistent (always-on) or dynamic (on-demand) Recording Sessions." >=20 > I'm not sure that the Persistent and Dynamic Recording as defined above > correspond to the Always On and On Demand modes defined in > http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4. >=20 > [LeonP] It is different in the way that the Recording Session is > established only once during initialization (or login events) and then > only media is forwarded per each call in order to minimize the > clipping. I see the "Always On" Recording as a separate third mode of Recording where= for a particular one or set of devices(possibly set via provisioning), all= calls are recorded from start to end(by setting up recording sessions) and= no persistent recording sessions are kept for them. >=20 > " o REQ-002 The mechanism MUST support the ability to perform > persistent Recording Sessions, such that the connection and > attributes of media in the Recording Session are not dynamically > signaled for each Recorded Session before it can be recorded. Call > details and metadata will still be signaled, but can be post- > correlated to the recorded media. There will still need to be a > means of correlating the recorded media connection/packets to the > Recorded Session, however this may be on a permanent filter-type > basis, such as based on a SIP AoR of an agent that is always > recorded, or based on identifiers in the recorded media itself." >=20 >=20 > Without fully understanding Persistent Recording, I can't evaluate this > requirement. >=20 > " o REQ-009 The mechanism MUST support the ability to deliver mixed > media streams to the RS. The RS MAY be informed about the > composition of the mixed streams through session metadata. >=20 > Note: A mixed media stream is where several recorded sessions are > carried in a single recording session. A mixed media stream is > typically produced by a mixer function." >=20 >=20 > I'm not clear what mixed media means here - does it mean a mix of media > types - synchronized audio and video from the same session, or do you > mean multiple media streams from different sessions? The note seems to > indicate that this relates only to a conference call where multiple > sources (SSRCs) have been combined into a single RTP session. >=20 > [LeonP] It is specific trading floor environment requirements where > multiple handset and speakers for specific turrets will be mixed on the > turret level for recording by one recording channel. >=20 >=20 > " o REQ-013 The mechanism MUST support the ability to inject tones > into > the Recorded Session either from the RS or from the RC." >=20 > Recorded Session seems to be defined as the media between the RC and > RS. Is that where the injected tones should be? Or should then be > mixed in the media between the two UAs? > [LeonP] we have multiple options here. Preferable solution that one of > the UAs will inject them (triggered by policy or parameters in SRP), > but there are also configuration where RS will be required to create > them and send back to RC (like talking clock for example) >=20 > " o REQ-021 The mechanism MUST support the ability for the RC to only > perform media replication to the RS, without needing to decode or > mix > audio/video/etc., and without needing to be an RTP agent. This will > allow the RC to replicate media at layers below RTP. Clearly, such > an RC mode would not be able to provide transcoding, or media > injection from the RS back into the Recorded Session." >=20 > Does this mean that you think that RTP is unsuitable for transporting > media between the RS and RC? Clearly it isn't for IM, but I would > think > that many of the functions of RTP are needed for audio and video media. > To understand this requirement will take more discussion. >=20 > [LeonP] Actually it was Hadriel requirement. I believe it only means > that RC does not required to implement RTP stack, it can just fork RTP > packets on the network level (by hardware) Most such middlebox media forkers will have RTP stack implemented anyway. T= hough packet replication can be done at a lower layer, it'd probably still = need the smarts to know the replicated packet is actually a RTP packet to d= etermine which packet to replicate. >=20 > Thanks, > Alan > _______________________________________________ > 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 spencer@wonderhamster.org Tue Jul 28 00:47:50 2009 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 28F743A6D1D for ; Tue, 28 Jul 2009 00:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, STOX_REPLY_TYPE=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 LUZJW+0Tk51v for ; Tue, 28 Jul 2009 00:47:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 3FE7A3A696E for ; Tue, 28 Jul 2009 00:47:49 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MVhPL2EIE-000NhU; Tue, 28 Jul 2009 03:47:38 -0400 Message-ID: From: "Spencer Dawkins" To: "dispatch mailing list" References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> Date: Tue, 28 Jul 2009 09:47:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/WVLFTkxAFqpbyMNJ4+e2jSqY7RxLb4/ntvk1 JKtRp01r/PMMzRZj7SAvoqJHWDWjl/SFaC/83w5Z5H0x3fpN71 JKaMoLg1yzpnD/4uOvM4GkjdT1yYwzNkfsCmu8XMEY= Cc: clf@ietf.org Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 over Lunch on Friday 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, 28 Jul 2009 07:47:50 -0000 Just to provide some logistics: We'll meet from 12 until 12:50 or so. Please use the 11:30-12:00 time to grab lunch. .SE has made arrangements to allow us to bring food into the conference center (not into the large conference rooms, but the rest of the building is OK), so you can pick up lunch and munch while we chat. Robert's goals for this session are: - To discuss feedback we gotten so far, - To refine the charter, and - To organize the next steps of work Please prepare for the meeting with these thoughts in mind. I also note that Robert's milestone dates on the proposed charter are currently: Oct 09 - Problem statement, motivation, and use cases WGLC Nov 09 - Problem statement, motivation, and use cases to IESG (Informational) Jan 10 - SIP Common Log Format specification WGLC Feb 10 - SIP Common Log Format specification to IESG (PS) There's not a lot of time between now and October/November, so please come prepared to make progress! Thanks, Spencer From gonzalo.camarillo@ericsson.com Tue Jul 28 00:56:02 2009 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 017143A6CB6 for ; Tue, 28 Jul 2009 00:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 b6q4x+ybzS6B for ; Tue, 28 Jul 2009 00:56:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 542BD3A691A for ; Tue, 28 Jul 2009 00:56:00 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-38-4a6eaeeb9268 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9E.B8.20893.BEEAE6A4; Tue, 28 Jul 2009 09:55:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:55:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:55:16 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 959972595; Tue, 28 Jul 2009 10:55:16 +0300 (EEST) Message-ID: <4A6EAEE4.2060206@ericsson.com> Date: Tue, 28 Jul 2009 09:55:16 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A6450D6.90904@ericsson.com> <4A646F12.8070000@cisco.com> <4A6C3C62.6050006@ericsson.com> <4A6DAA38.8010709@cisco.com> In-Reply-To: <4A6DAA38.8010709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 07:55:16.0925 (UTC) FILETIME=[BEFCAED0:01CA0F58] X-Brightmail-Tracker: AAAAAA== Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 28 Jul 2009 07:56:02 -0000 Hi Paul, yes, what you say is totally correct when one of the endpoints is not distributed. That case should be relatively-easy to resolve. The case where both ends are distributed is, of course, more "interesting" ;o) Cheers, Gonzalo Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: >> Hi, >> >>> I guess the one way I could buy into your "distributed" approach is >>> to simply model it as a conference, where the focus is at one "end". >>> But I think we discussed that once. >> >> that is how it is modeled when only one of the ends is distributed. >> What we discussed was that the semantics of join were intended for >> conferences and that even though this was very similar, it was not the >> same thing... but the model is valid. > > If the model is valid, then I think the mechanisms that go with it > should be valid too. > > The conferencing mechanism could be used for either the "distributed" or > "centralized" approach. Then there needs to be a focus somewhere, and > the difference between the approaches is where it resides - at your own > end, or at the "other" end. > > Thanks, > Paul From AUDET@nortel.com Tue Jul 28 01:24:04 2009 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 5D6673A6D15 for ; Tue, 28 Jul 2009 01:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 yFJ2oY1fFlZO for ; Tue, 28 Jul 2009 01:24:02 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 12EBC3A67BD for ; Tue, 28 Jul 2009 01:23:35 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6S8NTs20380; Tue, 28 Jul 2009 08:23:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jul 2009 03:23:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F312A25@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A6DC33F.7050108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt thread-index: AcoOzF4ZhbpIUPb5T1meB2AWH75xgQAjXjXw References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com><4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com><4A6DA80F.2070003@cisco.com> <4A6DC33F.7050108@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "DRAGE, Keith (Keith)" , "Alan Johnston" Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 28 Jul 2009 08:24:04 -0000 You could always read the appropriate ITU specs: http://www.itu.int/rec/T-REC-Q.957.1-199607-I/en and http://www.itu.int/rec/T-REC-Q.931-199805-I/en (section 4.5.30) And then, there would be all the "national" values, and, even more importantly, vendor specific values. Large operators and equipment manufacturers often have their own specificatons for use of UUS. UUS is more more complicated than just sending a blob in an=20 information element. And as I said yesterday, there is more to it than just carrying the UUI = IE blob. There is also Facility IE for example. The other thing is that UUS may = be=20 related to what specific ISDN message carries the information. I don't = think=20 this is addressed in the draft. So it may impose restrictions on when it = is appropriate to use this draft, versus, for example, the alternative = of=20 tunnelling the whole ISDN messages (=E0-la RFC 3204). I believe the intent of this draft is to cover ONLY the=20 UUIE case, not the others (again, like Facility). Perhaps I'm wrong, but at the very least, it needs to be clarified in the document. Realistically, just defining the blob for carrying UUI will NOT allow us to have any interoperability. It will just allow us to carry the = blob. Somebody else, perhaps other SDOs, or even just the vendors, would have to define the interop procedures. If it's something that is only meant to be vendor-specific, then I'm not even sure we need any standardization. One can use one of the=20 existing mechanisms in SIP (e.g., URI parameter, MIME bodies, = proprietary headers) to achieve this. > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, July 27, 2009 08:10 > To: DRAGE, Keith (Keith) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D=20 > Action:draft-johnston-sipping-cc-uui-08.txt >=20 >=20 >=20 > DRAGE, Keith (Keith) wrote: > > 1st octet of the payload. >=20 > Fine. But what does the first octet of the payload *mean*? >=20 > Aren't the encodings corresponding to particular values of=20 > that octet defined somewhere? If so, how many of the 256=20 > possible values are defined, and who controls how new values=20 > can be defined? >=20 > I'm pretty sure it isn't IETF or IANA. >=20 > Thanks, > Paul >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, July 27, 2009 2:14 PM > >> To: DRAGE, Keith (Keith) > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] I-D > >> Action:draft-johnston-sipping-cc-uui-08.txt > >> > >> Keith, > >> > >> If this is *not* ISDN encoding, then where is the=20 > indication of what=20 > >> encoding is being used? Are you saying that this is a private=20 > >> agreement between the UAC and UAS, neither signaled nor=20 > negotiated?=20 > >> How can that possibly work? > >> > >> I thought the first byte of the value was a registered format=20 > >> indicator. > >> > >> Thanks, > >> Paul > >> > >> DRAGE, Keith (Keith) wrote: > >>> Just to respond to this bit of the message: > >>> > >>>>> Not quite. We are not making the assumption that both are > >>>> gateways, > >>>>> although that is possible. Most likely, one element is > >> SIP enabled. > >>>>> However, it is not a fully intelligent SIP endpoint - the basic=20 > >>>>> software and application (probably many years old) is > >>>> unchanged but a > >>>>> SIP interface (SIP trunk) has been added. As such, the SIP > >>>> stack does > >>>>> not know anything about the UUI as it is implementing > >>>> exactly the ISDN > >>>>> UUI service - the information is just pushed up the stack > >>>> to another > >>>>> application, and this application knows nothing about SIP. =20 > >>>> It still > >>>>> thinks it is using an ISDN trunk. > >>>> Then in the way I meant the question, both ends *are* gateways. > >>>> > >>>> But then if someone wishes to build native sip gear to > >> plug into this > >>>> environment, then it will still have to understand this isdn=20 > >>>> encoding. > >>>> Perhaps that is the cruel truth, unless all the equipment > >> is replaced > >>>> at once. > >>> I've said this before and I'll say it again. The bit being > >> delivered to the end UE is not "isdn encoding". If it was ISDN=20 > >> encoding, then the ISDN / SIP gateway would be able to=20 > interpret it=20 > >> and map it into SIP. Rather it is some application sitting=20 > above the=20 > >> ISDN call control layer in the calling terminal, which is=20 > wishing to=20 > >> communicate with its peer application running in the=20 > destination SIP=20 > >> UA, or gateway. > >>> regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org > >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: Saturday, July 04, 2009 12:39 AM > >>>> To: Alan Johnston > >>>> Cc: dispatch@ietf.org > >>>> Subject: Re: [dispatch] I-D > >>>> Action:draft-johnston-sipping-cc-uui-08.txt > >>>> > >>>> Hi Alan, > >>>> > >>>> responses inline. I've trimmed out the parts that don't > >> require more > >>>> discussion. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> Alan Johnston wrote: > >>>>> Paul, > >>>>> > >>>>> Thanks for your comments. See mine below. > >>>>> > >>>>> Thanks, > >>>>> Alan > >>>>> > >>>>> Paul Kyzivat wrote: > >>>>>> Hi Alan, > >>>>>> > >>>>>> I took a quick look at this doc and the requirements doc > >>>> as well. I > >>>>>> have a few thoughts: > >>>>>> > >>>>>> From section 1: > >>>>>> > >>>>>>> In the future, where both endpoints are intelligent > >>>> SIP user agents, > >>>>>>> it may be possible for them to understand and > >>>> interpret the UUI data. > >>>>>>> There may be some cases where the UUI information is > >>>> relevant to SIP. > >>>>>>> In this case, it might be worthwhile attempting to map > >>>> UUI data to an > >>>>>>> appropriate SIP header field or to standardize a new > >>>> header field. > >>>>>>> However, the requirements and use cases for this are > >>>> different enough > >>>>>>> from those described in this document that these two > >> situations > >>>>>>> should be examined separately. This document looks > >> only at the > >>>>>>> requirements and mechanisms for replicating the > >>>> existing, widely used > >>>>>>> and deployed ISDN UUI service. > >>>>>> This *still* troubles me! > >>>>>> Is the assumption here that *both* the UAC and UAS are > >>>> gateways, so > >>>>>> that this mechanism is solely for the tunneling of Q.931 > >> and Q.763 > >>>>>> UUI message over SIP? > >>>>>> > >>>>>> I get the impression that an important use case is=20 > where at least > >>>>>> *one* end (probably the UAS) is a SIP device. In that > >> case it will > >>>>>> already be *necessary* for it to understand and > >> interpret UUI data. > >>>>>> And where there is redundancy between SIP data and the UUI > >>>> data, it > >>>>>> will need to resolve the discrepancy. > >>>>> Not quite. We are not making the assumption that both are > >>>> gateways, > >>>>> although that is possible. Most likely, one element is > >> SIP enabled. > >>>>> However, it is not a fully intelligent SIP endpoint - the basic=20 > >>>>> software and application (probably many years old) is > >>>> unchanged but a > >>>>> SIP interface (SIP trunk) has been added. As such, the SIP > >>>> stack does > >>>>> not know anything about the UUI as it is implementing > >>>> exactly the ISDN > >>>>> UUI service - the information is just pushed up the stack > >>>> to another > >>>>> application, and this application knows nothing about SIP. =20 > >>>> It still > >>>>> thinks it is using an ISDN trunk. > >>>> Then in the way I meant the question, both ends *are* gateways. > >>>> > >>>> But then if someone wishes to build native sip gear to > >> plug into this > >>>> environment, then it will still have to understand this isdn=20 > >>>> encoding. > >>>> Perhaps that is the cruel truth, unless all the equipment > >> is replaced > >>>> at once. > >>>> > >>>>>>> 5. Syntax for UUI Header Field > >>>>>> ... > >>>>>>> UUI =3D "User-to-User" HCOLON uui-data=20 > >>>> *(SEMI uui-param) > >>>>>>> uui-data =3D token > >>>>>>> uui-param =3D enc-param | cont-param | purp-param=20 > >>>> | generic-param > >>>>>>> enc-param =3D "encoding=3D" ("hex" | token) > >>>>>>> cont-param =3D "content=3D" ("isdn-uui" | token) > >>>>>>> purp-param =3D "purpose=3D" ("isdn-interwork" | token) > >>>>>> At the very least, I would request that this be expanded a > >>>> little bit > >>>>>> for future flexibility, by permitting the uui-data to be > >> either a > >>>>>> token or a string. While the encoding you have chosen=20 > works as a=20 > >>>>>> token, other encodings may need the additional flexibility > >>>> of a string. > >>>>>> uui-data =3D token | quoted-string > >>>>> OK, I guess I'm OK with that. For the isdn-interwork > >>>> purpose, we'll > >>>>> require the token, but other applications could utilize the > >>>> quoted string. > >>>> > >>>> I would hope that when the token encoding is sufficient, > >> then either > >>>> form would be accepted. Or it would perhaps be ok to=20 > specify for a=20 > >>>> particular encoding (hex) that the token encoding must=20 > be used. I=20 > >>>> don't see how the purpose has anything to do with it. > >>>> > >>>>>>> 6.3. Registration of SIP Option Tag > >>>>>> This section registers the new option tag. But I find > >>>> almost nothing > >>>>>> that defines the semantics of the option. (Section 5 does > >>>> include the > >>>>>> following: > >>>>>> > >>>>>>> A UA that supports this feature and the "uui" option > >>>> tag MUST support > >>>>>>> the call flows in [johnston-dispatch-sip-cc-uui]... > >>>>>> but that is pretty thin from a normative perspective. > >>>>>> > >>>>>> Of particular note, does support for the option tag mean > >>>> support for > >>>>>> the particular encoding, content, and purpose included in this=20 > >>>>>> document? Or does it only mean support for the header and > >>>> params in > >>>>>> the abstract? (That wouldn't be very useful.) > >>>>> Yes, this needs clarification. I'd suggest we define the > >>>> option tag > >>>>> to be uui-isdn which means it understands the header > >> field and the > >>>>> isdn-interwork purpose, and the call flows, including > >> escaping into > >>>>> redirection and Refer-To URIs. > >>>> I'd like to hear some other opinions on whether to have > >> tag per param > >>>> for tag, or a tag for the combination of param values. I > >> think I'm ok > >>>> with what you propose. > >>>> > >>>>>> I don't see how it can mean support for some other yet to > >>>> be defined > >>>>>> values for those. Yet if it only means support for the > >>>> current ones, > >>>>>> then how will one indicate support for future ones? > >>>>>> > >>>>>> The only way out of this that I can see is to have > >>>> separate options, > >>>>>> either for particular values of each parameter, or for > >> particular > >>>>>> combinations of values of all the parameters. > >>>>> New applications using this header field would have the=20 > option of=20 > >>>>> defining a new SIP option tag which would mean support for > >>>> the header > >>>>> field and their new purpose. > >>>>> > >>>>>> So you might have options uui-purpose-isdn-interwork,=20 > >>>>>> uui-content-isdn, and uui-encoding-hex. Or you might just > >>>> have option > >>>>>> uui-isdn-interwork that means the combination. > >>>>> I think the latter. I see it as a hierarchy - the=20 > application or=20 > >>>>> purpose is the top one. Each purpose has a number of > >>>> contents that it > >>>>> supports. Each content has a number of encoding schemes it > >>>> supports. > >>>> > >>>> I guess I'm ok with that, pending nailing down the definition of=20 > >>>> "purpose". > >>>> > >>>>>> I also am not finding much explanation of the semantics of the=20 > >>>>>> content and purpose parameters. I can only extrapolate > >>>> from a single > >>>>>> example of each, which I'm having trouble doing. > >>>>>> > >>>>>> I'm guessing that 'content' must refer to the precise > >>>> syntax of the > >>>>>> contained data, after decoding. So presumably it must map > >>>> onto some > >>>>>> particular spec. For isdn-uui, would that be [Q931] or > >>>> [Q763]? If so, > >>>>>> shouldn't it refer to something specific in that document? > >>>>> Not really. In this case, isdn-uui effectively means > >> "opaque data"=20 > >>>>> which is how ISDN defines the UUI - it is completely undefined,=20 > >>>>> necessarily so by the strict layering used in the ISDN > >> application. > >>>> I don't believe you! > >>>> > >>>> If that is the case, then the UAC and UAS must have a=20 > private side=20 > >>>> agreement about what the isdn-uui content means. Is that > >> really what > >>>> you mean? > >>>> > >>>> You already state that the first byte is a protocol=20 > discriminator.=20 > >>>> There must also be something, somewhere, that specifies > >> the mapping > >>>> from a particular value for that byte to a particular=20 > >>>> protocol/format. If there is, then that should be part of the=20 > >>>> definition of this content. > >>>> > >>>>>> 'purpose' is even less clear to me. Does it refer to why > >>>> it is being > >>>>>> included? Or what is to be done with it? If received by a > >>>> UA that is > >>>>>> not an ISDN gateway, how can it decide if this is > >>>> something it should > >>>>>> be trying to process? Is it still ISDN interworking if > >> neither the > >>>>>> UAC nor UAS is connected to an ISDN network? > >>>>> The purpose is the application using the UUI. Others have > >>>> expressed > >>>>> an interest in carrying other data in the header field, in > >>>> which case > >>>>> a new purpose would be defined. I'll see if I can think of > >>>> an example one. > >>>> > >>>> So are you saying that a particular call center=20 > application might=20 > >>>> constitute a distinct "purpose"? > >>>> > >>>>> Basically, if two UAs both support the header but have=20 > different=20 > >>>>> applications generating and consuming the UUI, it will not > >>>> work. This > >>>>> is not a SIP failure, and there is nothing SIP can do about > >>>> it. But > >>>>> this purpose header field allows the UAs to detect this=20 > condition. > >>>> In that case, perhaps "isdn-interwork" isn't really a > >> single purpose > >>>> at all, unless any two pieces of equipment that support > >> that purpose > >>>> can then interwork without knowing any more about each other. > >>>> > >>>>>> Suppose I was developing a sophisticated UA that > >>>> potentially might be > >>>>>> usable by a call center operator. How should > >>>> purpose=3Disdn-interwork > >>>>>> affect the operation of this device? > >>>>> To make it work in today's contact center applications, > >> supporting > >>>>> isdn-interwork would likely make it work in an application, > >>>> provided > >>>>> the appropriate call center application also ran on it. =20 > >>>> Some contact > >>>>> centers do not use ISDN UUI, instead they use all kinds > >> of really, > >>>>> really ugly CTI protocols running in parallel. > >>>> Yes, I know! :-( > >>>> > >>>>> This is a way of moving > >>>>> those to the ISDN model, and from there to a more > >>>> intelligent endpoint > >>>>> SIP model. > >>>>> > >>>>>> Thanks, > >>>>>> 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 >=20 From salvatore.loreto@ericsson.com Tue Jul 28 01:28:06 2009 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 89CA53A6D7B for ; Tue, 28 Jul 2009 01:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.808 X-Spam-Level: X-Spam-Status: No, score=-3.808 tagged_above=-999 required=5 tests=[AWL=-2.159, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_55=0.6] 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 LeIuiiZGOlZg for ; Tue, 28 Jul 2009 01:28:05 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 445933A6D78 for ; Tue, 28 Jul 2009 01:28:05 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-2b-4a6eb6952e61 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 33.2E.18827.596BE6A4; Tue, 28 Jul 2009 10:28:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 10:26:36 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 10:26:35 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5C90F28B1; Tue, 28 Jul 2009 11:26:35 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 27E0221A07; Tue, 28 Jul 2009 11:26:35 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DA40A21925; Tue, 28 Jul 2009 11:26:34 +0300 (EEST) Message-ID: <4A6EB63A.2020201@ericsson.com> Date: Tue, 28 Jul 2009 11:26:34 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A643F2D.5030300@ericsson.com> <4A646BAF.7030007@cisco.com> <4A6576B9.4020504@ericsson.com> <1248372794.4427.11.camel@victoria-pingtel-com.us.nortel.com> <4A697AA5.4020603@ericsson.com> <4A69B0FD.20308@cisco.com> In-Reply-To: <4A69B0FD.20308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 28 Jul 2009 08:26:35.0726 (UTC) FILETIME=[1ED6F6E0:01CA0F5D] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Disaggregated Media in SIP 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, 28 Jul 2009 08:28:06 -0000 Paul Kyzivat wrote: > > > Salvatore Loreto wrote: >> Dale Worley wrote: >>> On Tue, 2009-07-21 at 11:05 +0300, Gonzalo Camarillo wrote: >>> >>>> well, 3pcc is centralized because you have a (central) controller >>>> that is in control of all SIP signalling. If that controller leaves >>>> the session, the whole session disappears. An approach where >>>> several devices have their own SIP dialog with the remote devices >>>> is not centralized because you can remove any of them and the other >>>> sessions will remain unaffected. >>>> >>> >>> It's true that if the implementation is a single dialog, then the UA at >>> each end must remain in the call. For a UA to replace itself with >>> another UA would require a transfer-like process. >>> >>> The difficulty (under either implementation) is to transfer the "state" >>> information (which media stream goes to which destination) from one >>> controller to another. That need is obvious in the centralized >>> approach, but it seems to me that it would also be needed in the >>> decentralized approach. >>> >> the need or not to transfer the "state" really depends on how the >> decentralized approach will be designed. >> >> for example: >> In a "loosely coupled control" approach, as Francois is proposing, >> you don't have any "state" information that >> need to be transferred from one to another because you don't have a >> real controller. > > I don't understand that. > > Suppose Alice calls Bob using her voice phone. Then she arranges for > her laptop to join the call with Bob to add voice. (Bob has a video > phone.) > > Then Bob decides to do a consultative transfer of the call to Charlie. > Because Bob's phone is a video phone, its UI presumably treats this as > a single call, even if there are actually two calls behind the scenes. > So Bob first puts the call with Alice on hold. It already has to know > to do this on two separate calls. Then it calls Charlie, who also has > a video phone. So there is an audio+video call from Bob to Charlie. > Then Bob asks to complete the transfer. What does it do? Normally it > would send a REFER to Charlie's phone, asking it to do an > INVITE/Replaces to Alice. But there are two calls to Alice. > > The "state" of the call, that it is distributed across two dialogs, is > important info that needs to be transferred to Charlie given this > implementation approach. With the "centralized" approach that state > resides in Alice's realm and is of no concern to either Bob or Charlie. in the "disaggregated media" approach the state of the call will still reside in Alice's realm, however there will be some difference with the "centralized" approach because you don't have a controller and the state of the call is distributed among the different UAs present in the Alice's realm. Thanks /Sal From drage@alcatel-lucent.com Tue Jul 28 01:39:49 2009 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 04B8F3A6A75 for ; Tue, 28 Jul 2009 01:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 tzvtObudXaMZ for ; Tue, 28 Jul 2009 01:39:47 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 6954F3A6889 for ; Tue, 28 Jul 2009 01:39:43 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6S8aSIc002018 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jul 2009 10:39:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 28 Jul 2009 10:39:22 +0200 From: "DRAGE, Keith (Keith)" To: Francois Audet , Paul Kyzivat , Alan Johnston Date: Tue, 28 Jul 2009 10:39:20 +0200 Thread-Topic: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt Thread-Index: AcoOzF4ZhbpIUPb5T1meB2AWH75xgQAjXjXwAADLbtA= Message-ID: References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com><4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com><4A6DA80F.2070003@cisco.com> <4A6DC33F.7050108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F312A25@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F312A25@zrc2hxm0.corp.nortel.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 28 Jul 2009 08:39:49 -0000 If people read ITU-T Recommendation Q.957.1 (which incidently is the correc= t reference that should appear in the charter proposal and not Q.931) the k= ey works you are looking for are UUS service 1 implicit. This is "implicit"= in that the service is requested merely by the presence of the data to be = transferred and does not involve the use of the Facility information elemen= t to control this. Q.957.1 the references Q.931 for the coding of the information elements req= uired by the procedures in Q.957.1. (The procedures in ITU-T Recommendation Q.931 defines two different usages: - the mapping of user data in X.29 into Q.931 packet data. - the user to user bearer service which essentially defines a call th= at consists of the control signalling only (plus encapsulated data in the s= ignalling) and has no separate bearer path). regards Keith > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, July 28, 2009 9:23 AM > To: Paul Kyzivat; DRAGE, Keith (Keith); Alan Johnston > Cc: dispatch@ietf.org > Subject: RE: [dispatch] I-D > Action:draft-johnston-sipping-cc-uui-08.txt > > You could always read the appropriate ITU specs: > http://www.itu.int/rec/T-REC-Q.957.1-199607-I/en > > and > > http://www.itu.int/rec/T-REC-Q.931-199805-I/en > (section 4.5.30) > > And then, there would be all the "national" values, and, even > more importantly, vendor specific values. Large operators and > equipment manufacturers often have their own specificatons > for use of UUS. > > UUS is more more complicated than just sending a blob in an > information element. > > And as I said yesterday, there is more to it than just > carrying the UUI IE blob. > > There is also Facility IE for example. The other thing is > that UUS may be related to what specific ISDN message carries > the information. I don't think this is addressed in the > draft. So it may impose restrictions on when it is > appropriate to use this draft, versus, for example, the > alternative of tunnelling the whole ISDN messages (=E0-la RFC 3204). > > I believe the intent of this draft is to cover ONLY the UUIE > case, not the others (again, like Facility). Perhaps I'm > wrong, but at the very least, it needs to be clarified in the > document. > > Realistically, just defining the blob for carrying UUI will > NOT allow us to have any interoperability. It will just allow > us to carry the blob. > > Somebody else, perhaps other SDOs, or even just the vendors, > would have to define the interop procedures. > > If it's something that is only meant to be vendor-specific, > then I'm not even sure we need any standardization. One can > use one of the existing mechanisms in SIP (e.g., URI > parameter, MIME bodies, proprietary > headers) to achieve this. > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, July 27, 2009 08:10 > > To: DRAGE, Keith (Keith) > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] I-D > > Action:draft-johnston-sipping-cc-uui-08.txt > > > > > > > > DRAGE, Keith (Keith) wrote: > > > 1st octet of the payload. > > > > Fine. But what does the first octet of the payload *mean*? > > > > Aren't the encodings corresponding to particular values of > > that octet defined somewhere? If so, how many of the 256 > > possible values are defined, and who controls how new values > > can be defined? > > > > I'm pretty sure it isn't IETF or IANA. > > > > Thanks, > > Paul > > > > > Keith > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Monday, July 27, 2009 2:14 PM > > >> To: DRAGE, Keith (Keith) > > >> Cc: dispatch@ietf.org > > >> Subject: Re: [dispatch] I-D > > >> Action:draft-johnston-sipping-cc-uui-08.txt > > >> > > >> Keith, > > >> > > >> If this is *not* ISDN encoding, then where is the > > indication of what > > >> encoding is being used? Are you saying that this is a private > > >> agreement between the UAC and UAS, neither signaled nor > > negotiated? > > >> How can that possibly work? > > >> > > >> I thought the first byte of the value was a registered format > > >> indicator. > > >> > > >> Thanks, > > >> Paul > > >> > > >> DRAGE, Keith (Keith) wrote: > > >>> Just to respond to this bit of the message: > > >>> > > >>>>> Not quite. We are not making the assumption that both are > > >>>> gateways, > > >>>>> although that is possible. Most likely, one element is > > >> SIP enabled. > > >>>>> However, it is not a fully intelligent SIP endpoint - > the basic > > >>>>> software and application (probably many years old) is > > >>>> unchanged but a > > >>>>> SIP interface (SIP trunk) has been added. As such, the SIP > > >>>> stack does > > >>>>> not know anything about the UUI as it is implementing > > >>>> exactly the ISDN > > >>>>> UUI service - the information is just pushed up the stack > > >>>> to another > > >>>>> application, and this application knows nothing about SIP. > > >>>> It still > > >>>>> thinks it is using an ISDN trunk. > > >>>> Then in the way I meant the question, both ends *are* gateways. > > >>>> > > >>>> But then if someone wishes to build native sip gear to > > >> plug into this > > >>>> environment, then it will still have to understand this isdn > > >>>> encoding. > > >>>> Perhaps that is the cruel truth, unless all the equipment > > >> is replaced > > >>>> at once. > > >>> I've said this before and I'll say it again. The bit being > > >> delivered to the end UE is not "isdn encoding". If it was ISDN > > >> encoding, then the ISDN / SIP gateway would be able to > > interpret it > > >> and map it into SIP. Rather it is some application sitting > > above the > > >> ISDN call control layer in the calling terminal, which is > > wishing to > > >> communicate with its peer application running in the > > destination SIP > > >> UA, or gateway. > > >>> regards > > >>> > > >>> Keith > > >>> > > >>>> -----Original Message----- > > >>>> From: dispatch-bounces@ietf.org > > >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >>>> Sent: Saturday, July 04, 2009 12:39 AM > > >>>> To: Alan Johnston > > >>>> Cc: dispatch@ietf.org > > >>>> Subject: Re: [dispatch] I-D > > >>>> Action:draft-johnston-sipping-cc-uui-08.txt > > >>>> > > >>>> Hi Alan, > > >>>> > > >>>> responses inline. I've trimmed out the parts that don't > > >> require more > > >>>> discussion. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>> Alan Johnston wrote: > > >>>>> Paul, > > >>>>> > > >>>>> Thanks for your comments. See mine below. > > >>>>> > > >>>>> Thanks, > > >>>>> Alan > > >>>>> > > >>>>> Paul Kyzivat wrote: > > >>>>>> Hi Alan, > > >>>>>> > > >>>>>> I took a quick look at this doc and the requirements doc > > >>>> as well. I > > >>>>>> have a few thoughts: > > >>>>>> > > >>>>>> From section 1: > > >>>>>> > > >>>>>>> In the future, where both endpoints are intelligent > > >>>> SIP user agents, > > >>>>>>> it may be possible for them to understand and > > >>>> interpret the UUI data. > > >>>>>>> There may be some cases where the UUI information is > > >>>> relevant to SIP. > > >>>>>>> In this case, it might be worthwhile attempting to map > > >>>> UUI data to an > > >>>>>>> appropriate SIP header field or to standardize a new > > >>>> header field. > > >>>>>>> However, the requirements and use cases for this are > > >>>> different enough > > >>>>>>> from those described in this document that these two > > >> situations > > >>>>>>> should be examined separately. This document looks > > >> only at the > > >>>>>>> requirements and mechanisms for replicating the > > >>>> existing, widely used > > >>>>>>> and deployed ISDN UUI service. > > >>>>>> This *still* troubles me! > > >>>>>> Is the assumption here that *both* the UAC and UAS are > > >>>> gateways, so > > >>>>>> that this mechanism is solely for the tunneling of Q.931 > > >> and Q.763 > > >>>>>> UUI message over SIP? > > >>>>>> > > >>>>>> I get the impression that an important use case is > > where at least > > >>>>>> *one* end (probably the UAS) is a SIP device. In that > > >> case it will > > >>>>>> already be *necessary* for it to understand and > > >> interpret UUI data. > > >>>>>> And where there is redundancy between SIP data and the UUI > > >>>> data, it > > >>>>>> will need to resolve the discrepancy. > > >>>>> Not quite. We are not making the assumption that both are > > >>>> gateways, > > >>>>> although that is possible. Most likely, one element is > > >> SIP enabled. > > >>>>> However, it is not a fully intelligent SIP endpoint - > the basic > > >>>>> software and application (probably many years old) is > > >>>> unchanged but a > > >>>>> SIP interface (SIP trunk) has been added. As such, the SIP > > >>>> stack does > > >>>>> not know anything about the UUI as it is implementing > > >>>> exactly the ISDN > > >>>>> UUI service - the information is just pushed up the stack > > >>>> to another > > >>>>> application, and this application knows nothing about SIP. > > >>>> It still > > >>>>> thinks it is using an ISDN trunk. > > >>>> Then in the way I meant the question, both ends *are* gateways. > > >>>> > > >>>> But then if someone wishes to build native sip gear to > > >> plug into this > > >>>> environment, then it will still have to understand this isdn > > >>>> encoding. > > >>>> Perhaps that is the cruel truth, unless all the equipment > > >> is replaced > > >>>> at once. > > >>>> > > >>>>>>> 5. Syntax for UUI Header Field > > >>>>>> ... > > >>>>>>> UUI =3D "User-to-User" HCOLON uui-data > > >>>> *(SEMI uui-param) > > >>>>>>> uui-data =3D token > > >>>>>>> uui-param =3D enc-param | cont-param | purp-param > > >>>> | generic-param > > >>>>>>> enc-param =3D "encoding=3D" ("hex" | token) > > >>>>>>> cont-param =3D "content=3D" ("isdn-uui" | token) > > >>>>>>> purp-param =3D "purpose=3D" ("isdn-interwork" | token) > > >>>>>> At the very least, I would request that this be expanded a > > >>>> little bit > > >>>>>> for future flexibility, by permitting the uui-data to be > > >> either a > > >>>>>> token or a string. While the encoding you have chosen > > works as a > > >>>>>> token, other encodings may need the additional flexibility > > >>>> of a string. > > >>>>>> uui-data =3D token | quoted-string > > >>>>> OK, I guess I'm OK with that. For the isdn-interwork > > >>>> purpose, we'll > > >>>>> require the token, but other applications could utilize the > > >>>> quoted string. > > >>>> > > >>>> I would hope that when the token encoding is sufficient, > > >> then either > > >>>> form would be accepted. Or it would perhaps be ok to > > specify for a > > >>>> particular encoding (hex) that the token encoding must > > be used. I > > >>>> don't see how the purpose has anything to do with it. > > >>>> > > >>>>>>> 6.3. Registration of SIP Option Tag > > >>>>>> This section registers the new option tag. But I find > > >>>> almost nothing > > >>>>>> that defines the semantics of the option. (Section 5 does > > >>>> include the > > >>>>>> following: > > >>>>>> > > >>>>>>> A UA that supports this feature and the "uui" option > > >>>> tag MUST support > > >>>>>>> the call flows in [johnston-dispatch-sip-cc-uui]... > > >>>>>> but that is pretty thin from a normative perspective. > > >>>>>> > > >>>>>> Of particular note, does support for the option tag mean > > >>>> support for > > >>>>>> the particular encoding, content, and purpose > included in this > > >>>>>> document? Or does it only mean support for the header and > > >>>> params in > > >>>>>> the abstract? (That wouldn't be very useful.) > > >>>>> Yes, this needs clarification. I'd suggest we define the > > >>>> option tag > > >>>>> to be uui-isdn which means it understands the header > > >> field and the > > >>>>> isdn-interwork purpose, and the call flows, including > > >> escaping into > > >>>>> redirection and Refer-To URIs. > > >>>> I'd like to hear some other opinions on whether to have > > >> tag per param > > >>>> for tag, or a tag for the combination of param values. I > > >> think I'm ok > > >>>> with what you propose. > > >>>> > > >>>>>> I don't see how it can mean support for some other yet to > > >>>> be defined > > >>>>>> values for those. Yet if it only means support for the > > >>>> current ones, > > >>>>>> then how will one indicate support for future ones? > > >>>>>> > > >>>>>> The only way out of this that I can see is to have > > >>>> separate options, > > >>>>>> either for particular values of each parameter, or for > > >> particular > > >>>>>> combinations of values of all the parameters. > > >>>>> New applications using this header field would have the > > option of > > >>>>> defining a new SIP option tag which would mean support for > > >>>> the header > > >>>>> field and their new purpose. > > >>>>> > > >>>>>> So you might have options uui-purpose-isdn-interwork, > > >>>>>> uui-content-isdn, and uui-encoding-hex. Or you might just > > >>>> have option > > >>>>>> uui-isdn-interwork that means the combination. > > >>>>> I think the latter. I see it as a hierarchy - the > > application or > > >>>>> purpose is the top one. Each purpose has a number of > > >>>> contents that it > > >>>>> supports. Each content has a number of encoding schemes it > > >>>> supports. > > >>>> > > >>>> I guess I'm ok with that, pending nailing down the > definition of > > >>>> "purpose". > > >>>> > > >>>>>> I also am not finding much explanation of the > semantics of the > > >>>>>> content and purpose parameters. I can only extrapolate > > >>>> from a single > > >>>>>> example of each, which I'm having trouble doing. > > >>>>>> > > >>>>>> I'm guessing that 'content' must refer to the precise > > >>>> syntax of the > > >>>>>> contained data, after decoding. So presumably it must map > > >>>> onto some > > >>>>>> particular spec. For isdn-uui, would that be [Q931] or > > >>>> [Q763]? If so, > > >>>>>> shouldn't it refer to something specific in that document? > > >>>>> Not really. In this case, isdn-uui effectively means > > >> "opaque data" > > >>>>> which is how ISDN defines the UUI - it is completely > undefined, > > >>>>> necessarily so by the strict layering used in the ISDN > > >> application. > > >>>> I don't believe you! > > >>>> > > >>>> If that is the case, then the UAC and UAS must have a > > private side > > >>>> agreement about what the isdn-uui content means. Is that > > >> really what > > >>>> you mean? > > >>>> > > >>>> You already state that the first byte is a protocol > > discriminator. > > >>>> There must also be something, somewhere, that specifies > > >> the mapping > > >>>> from a particular value for that byte to a particular > > >>>> protocol/format. If there is, then that should be part of the > > >>>> definition of this content. > > >>>> > > >>>>>> 'purpose' is even less clear to me. Does it refer to why > > >>>> it is being > > >>>>>> included? Or what is to be done with it? If received by a > > >>>> UA that is > > >>>>>> not an ISDN gateway, how can it decide if this is > > >>>> something it should > > >>>>>> be trying to process? Is it still ISDN interworking if > > >> neither the > > >>>>>> UAC nor UAS is connected to an ISDN network? > > >>>>> The purpose is the application using the UUI. Others have > > >>>> expressed > > >>>>> an interest in carrying other data in the header field, in > > >>>> which case > > >>>>> a new purpose would be defined. I'll see if I can think of > > >>>> an example one. > > >>>> > > >>>> So are you saying that a particular call center > > application might > > >>>> constitute a distinct "purpose"? > > >>>> > > >>>>> Basically, if two UAs both support the header but have > > different > > >>>>> applications generating and consuming the UUI, it will not > > >>>> work. This > > >>>>> is not a SIP failure, and there is nothing SIP can do about > > >>>> it. But > > >>>>> this purpose header field allows the UAs to detect this > > condition. > > >>>> In that case, perhaps "isdn-interwork" isn't really a > > >> single purpose > > >>>> at all, unless any two pieces of equipment that support > > >> that purpose > > >>>> can then interwork without knowing any more about each other. > > >>>> > > >>>>>> Suppose I was developing a sophisticated UA that > > >>>> potentially might be > > >>>>>> usable by a call center operator. How should > > >>>> purpose=3Disdn-interwork > > >>>>>> affect the operation of this device? > > >>>>> To make it work in today's contact center applications, > > >> supporting > > >>>>> isdn-interwork would likely make it work in an application, > > >>>> provided > > >>>>> the appropriate call center application also ran on it. > > >>>> Some contact > > >>>>> centers do not use ISDN UUI, instead they use all kinds > > >> of really, > > >>>>> really ugly CTI protocols running in parallel. > > >>>> Yes, I know! :-( > > >>>> > > >>>>> This is a way of moving > > >>>>> those to the ISDN model, and from there to a more > > >>>> intelligent endpoint > > >>>>> SIP model. > > >>>>> > > >>>>>> Thanks, > > >>>>>> 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 pkyzivat@cisco.com Tue Jul 28 05:47:23 2009 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 38D403A6E61 for ; Tue, 28 Jul 2009 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 hpJ2ncjs06cu for ; Tue, 28 Jul 2009 05:47:22 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1BFCC3A6A84 for ; Tue, 28 Jul 2009 05:47:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOePbkpAZnmf/2dsb2JhbAC7M4gnj1sFhAw X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="179920236" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2009 12:47:21 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SClLAW029566; Tue, 28 Jul 2009 08:47:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SClLVo017589; Tue, 28 Jul 2009 12:47:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 08:47:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 08:47:20 -0400 Message-ID: <4A6EF357.2070202@cisco.com> Date: Tue, 28 Jul 2009 08:47:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A6450D6.90904@ericsson.com> <4A646F12.8070000@cisco.com> <4A6C3C62.6050006@ericsson.com> <4A6DAA38.8010709@cisco.com> <4A6EAEE4.2060206@ericsson.com> In-Reply-To: <4A6EAEE4.2060206@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 12:47:20.0774 (UTC) FILETIME=[8C03D660:01CA0F81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1369; t=1248785241; x=1249649241; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=SBI+zO0dDHqmSQlNv0ZDMDIzTZFVim0ksfkuqDdATG8=; b=f5i2OJSH19hpZu07D0BREvV7qElWyVL0srjA1Yqq6v1BwMkP8+PCTQbUvz HVynpGZOZ8IRCHGR932P7EOtXkCJHhOhXSqynMRZTtEsMTLAVAoVZu4NJ6qD pggespR0e0; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 28 Jul 2009 12:47:23 -0000 Gonzalo Camarillo wrote: > Hi Paul, > > yes, what you say is totally correct when one of the endpoints is not > distributed. That case should be relatively-easy to resolve. The case > where both ends are distributed is, of course, more "interesting" ;o) I don't understand at all how the "distributed" model works when both ends want to be distributed. Thanks, Paul > Cheers, > > Gonzalo > > Paul Kyzivat wrote: >> >> >> Gonzalo Camarillo wrote: >>> Hi, >>> >>>> I guess the one way I could buy into your "distributed" approach is >>>> to simply model it as a conference, where the focus is at one "end". >>>> But I think we discussed that once. >>> >>> that is how it is modeled when only one of the ends is distributed. >>> What we discussed was that the semantics of join were intended for >>> conferences and that even though this was very similar, it was not >>> the same thing... but the model is valid. >> >> If the model is valid, then I think the mechanisms that go with it >> should be valid too. >> >> The conferencing mechanism could be used for either the "distributed" >> or "centralized" approach. Then there needs to be a focus somewhere, >> and the difference between the approaches is where it resides - at >> your own end, or at the "other" end. >> >> Thanks, >> Paul > > From pkyzivat@cisco.com Tue Jul 28 06:04:06 2009 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 9D2713A68E9 for ; Tue, 28 Jul 2009 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 ZiYycCwNXC04 for ; Tue, 28 Jul 2009 06:04:04 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7290D3A6F55 for ; Tue, 28 Jul 2009 06:04:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB+UbkpAZnme/2dsb2JhbAC7TIgnj2IFhAw X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="52086381" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2009 13:04:02 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6SD42xI030269; Tue, 28 Jul 2009 09:04:02 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SD42hV023164; Tue, 28 Jul 2009 13:04:02 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:04:01 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 09:04:01 -0400 Message-ID: <4A6EF73D.4060905@cisco.com> Date: Tue, 28 Jul 2009 09:03:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <20090702211501.52B5B3A6B6C@core3.amsl.com> <4A4D3E55.80307@cisco.com><4A4E2E1E.1050509@sipstation.com> <4A4E96B1.1080005@cisco.com><4A6DA80F.2070003@cisco.com> <4A6DC33F.7050108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F312A25@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F312A25@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Jul 2009 13:04:01.0525 (UTC) FILETIME=[E0825250:01CA0F83] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16803; t=1248786242; x=1249650242; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20I-D=20Action=3Adraft-johns ton-sipping-cc-uui-08.txt |Sender:=20 |To:=20Francois=20Audet=20; bh=orsvnL7o+ieVz8ptqup9cXEphcoJ3tKX6Aq257TNET0=; b=JbvaAE7kPjhnrW0WNXvp+tmjwnhY306GfQUflRmb14Is7ucMFG/TUpYjaT N/SdXxum1IBu4rxcd7iHgboUv4XTS+68F8Q9Jo1uU8FvF+uCDEXSA6X2lyKr kZqqeCRkjR; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action:draft-johnston-sipping-cc-uui-08.txt 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, 28 Jul 2009 13:04:06 -0000 Francois Audet wrote: > You could always read the appropriate ITU specs: > http://www.itu.int/rec/T-REC-Q.957.1-199607-I/en > > and > > http://www.itu.int/rec/T-REC-Q.931-199805-I/en > (section 4.5.30) How would I know those are the "appropriate" specs to read? In the doc, Q.957 isn't mentioned at all. Q.931 is referenced as an informative document in the list of references, and referenced non-normatively in the first paragraph of the Overview. There is no linkage at all of encoding/content/purpose params to either of these specs. > And then, there would be all the "national" values, > and, even more importantly, vendor specific values. Large operators > and equipment manufacturers often have their own specificatons > for use of UUS. So, how would the use of national and/or vendor specific values be indicated in this header? > UUS is more more complicated than just sending a blob in an > information element. > > And as I said yesterday, there is more to it than just carrying the UUI IE > blob. > > There is also Facility IE for example. The other thing is that UUS may be > related to what specific ISDN message carries the information. I don't think > this is addressed in the draft. So it may impose restrictions on when it > is appropriate to use this draft, versus, for example, the alternative of > tunnelling the whole ISDN messages (à-la RFC 3204). > > I believe the intent of this draft is to cover ONLY the > UUIE case, not the others (again, like Facility). Perhaps I'm wrong, > but at the very least, it needs to be clarified in the document. > > Realistically, just defining the blob for carrying UUI will NOT allow > us to have any interoperability. It will just allow us to carry the blob. That is a big part of my concern. I am looking for the direct linkage from the values in the header to the specs that define what those values mean. > Somebody else, perhaps other SDOs, or even just the vendors, would have > to define the interop procedures. That would be a problem. > If it's something that is only meant to be vendor-specific, then I'm > not even sure we need any standardization. One can use one of the > existing mechanisms in SIP (e.g., URI parameter, MIME bodies, proprietary > headers) to achieve this. I agree. Thanks, Paul >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, July 27, 2009 08:10 >> To: DRAGE, Keith (Keith) >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D >> Action:draft-johnston-sipping-cc-uui-08.txt >> >> >> >> DRAGE, Keith (Keith) wrote: >>> 1st octet of the payload. >> Fine. But what does the first octet of the payload *mean*? >> >> Aren't the encodings corresponding to particular values of >> that octet defined somewhere? If so, how many of the 256 >> possible values are defined, and who controls how new values >> can be defined? >> >> I'm pretty sure it isn't IETF or IANA. >> >> Thanks, >> Paul >> >>> Keith >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, July 27, 2009 2:14 PM >>>> To: DRAGE, Keith (Keith) >>>> Cc: dispatch@ietf.org >>>> Subject: Re: [dispatch] I-D >>>> Action:draft-johnston-sipping-cc-uui-08.txt >>>> >>>> Keith, >>>> >>>> If this is *not* ISDN encoding, then where is the >> indication of what >>>> encoding is being used? Are you saying that this is a private >>>> agreement between the UAC and UAS, neither signaled nor >> negotiated? >>>> How can that possibly work? >>>> >>>> I thought the first byte of the value was a registered format >>>> indicator. >>>> >>>> Thanks, >>>> Paul >>>> >>>> DRAGE, Keith (Keith) wrote: >>>>> Just to respond to this bit of the message: >>>>> >>>>>>> Not quite. We are not making the assumption that both are >>>>>> gateways, >>>>>>> although that is possible. Most likely, one element is >>>> SIP enabled. >>>>>>> However, it is not a fully intelligent SIP endpoint - the basic >>>>>>> software and application (probably many years old) is >>>>>> unchanged but a >>>>>>> SIP interface (SIP trunk) has been added. As such, the SIP >>>>>> stack does >>>>>>> not know anything about the UUI as it is implementing >>>>>> exactly the ISDN >>>>>>> UUI service - the information is just pushed up the stack >>>>>> to another >>>>>>> application, and this application knows nothing about SIP. >>>>>> It still >>>>>>> thinks it is using an ISDN trunk. >>>>>> Then in the way I meant the question, both ends *are* gateways. >>>>>> >>>>>> But then if someone wishes to build native sip gear to >>>> plug into this >>>>>> environment, then it will still have to understand this isdn >>>>>> encoding. >>>>>> Perhaps that is the cruel truth, unless all the equipment >>>> is replaced >>>>>> at once. >>>>> I've said this before and I'll say it again. The bit being >>>> delivered to the end UE is not "isdn encoding". If it was ISDN >>>> encoding, then the ISDN / SIP gateway would be able to >> interpret it >>>> and map it into SIP. Rather it is some application sitting >> above the >>>> ISDN call control layer in the calling terminal, which is >> wishing to >>>> communicate with its peer application running in the >> destination SIP >>>> UA, or gateway. >>>>> regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: Saturday, July 04, 2009 12:39 AM >>>>>> To: Alan Johnston >>>>>> Cc: dispatch@ietf.org >>>>>> Subject: Re: [dispatch] I-D >>>>>> Action:draft-johnston-sipping-cc-uui-08.txt >>>>>> >>>>>> Hi Alan, >>>>>> >>>>>> responses inline. I've trimmed out the parts that don't >>>> require more >>>>>> discussion. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Alan Johnston wrote: >>>>>>> Paul, >>>>>>> >>>>>>> Thanks for your comments. See mine below. >>>>>>> >>>>>>> Thanks, >>>>>>> Alan >>>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>>> Hi Alan, >>>>>>>> >>>>>>>> I took a quick look at this doc and the requirements doc >>>>>> as well. I >>>>>>>> have a few thoughts: >>>>>>>> >>>>>>>> From section 1: >>>>>>>> >>>>>>>>> In the future, where both endpoints are intelligent >>>>>> SIP user agents, >>>>>>>>> it may be possible for them to understand and >>>>>> interpret the UUI data. >>>>>>>>> There may be some cases where the UUI information is >>>>>> relevant to SIP. >>>>>>>>> In this case, it might be worthwhile attempting to map >>>>>> UUI data to an >>>>>>>>> appropriate SIP header field or to standardize a new >>>>>> header field. >>>>>>>>> However, the requirements and use cases for this are >>>>>> different enough >>>>>>>>> from those described in this document that these two >>>> situations >>>>>>>>> should be examined separately. This document looks >>>> only at the >>>>>>>>> requirements and mechanisms for replicating the >>>>>> existing, widely used >>>>>>>>> and deployed ISDN UUI service. >>>>>>>> This *still* troubles me! >>>>>>>> Is the assumption here that *both* the UAC and UAS are >>>>>> gateways, so >>>>>>>> that this mechanism is solely for the tunneling of Q.931 >>>> and Q.763 >>>>>>>> UUI message over SIP? >>>>>>>> >>>>>>>> I get the impression that an important use case is >> where at least >>>>>>>> *one* end (probably the UAS) is a SIP device. In that >>>> case it will >>>>>>>> already be *necessary* for it to understand and >>>> interpret UUI data. >>>>>>>> And where there is redundancy between SIP data and the UUI >>>>>> data, it >>>>>>>> will need to resolve the discrepancy. >>>>>>> Not quite. We are not making the assumption that both are >>>>>> gateways, >>>>>>> although that is possible. Most likely, one element is >>>> SIP enabled. >>>>>>> However, it is not a fully intelligent SIP endpoint - the basic >>>>>>> software and application (probably many years old) is >>>>>> unchanged but a >>>>>>> SIP interface (SIP trunk) has been added. As such, the SIP >>>>>> stack does >>>>>>> not know anything about the UUI as it is implementing >>>>>> exactly the ISDN >>>>>>> UUI service - the information is just pushed up the stack >>>>>> to another >>>>>>> application, and this application knows nothing about SIP. >>>>>> It still >>>>>>> thinks it is using an ISDN trunk. >>>>>> Then in the way I meant the question, both ends *are* gateways. >>>>>> >>>>>> But then if someone wishes to build native sip gear to >>>> plug into this >>>>>> environment, then it will still have to understand this isdn >>>>>> encoding. >>>>>> Perhaps that is the cruel truth, unless all the equipment >>>> is replaced >>>>>> at once. >>>>>> >>>>>>>>> 5. Syntax for UUI Header Field >>>>>>>> ... >>>>>>>>> UUI = "User-to-User" HCOLON uui-data >>>>>> *(SEMI uui-param) >>>>>>>>> uui-data = token >>>>>>>>> uui-param = enc-param | cont-param | purp-param >>>>>> | generic-param >>>>>>>>> enc-param = "encoding=" ("hex" | token) >>>>>>>>> cont-param = "content=" ("isdn-uui" | token) >>>>>>>>> purp-param = "purpose=" ("isdn-interwork" | token) >>>>>>>> At the very least, I would request that this be expanded a >>>>>> little bit >>>>>>>> for future flexibility, by permitting the uui-data to be >>>> either a >>>>>>>> token or a string. While the encoding you have chosen >> works as a >>>>>>>> token, other encodings may need the additional flexibility >>>>>> of a string. >>>>>>>> uui-data = token | quoted-string >>>>>>> OK, I guess I'm OK with that. For the isdn-interwork >>>>>> purpose, we'll >>>>>>> require the token, but other applications could utilize the >>>>>> quoted string. >>>>>> >>>>>> I would hope that when the token encoding is sufficient, >>>> then either >>>>>> form would be accepted. Or it would perhaps be ok to >> specify for a >>>>>> particular encoding (hex) that the token encoding must >> be used. I >>>>>> don't see how the purpose has anything to do with it. >>>>>> >>>>>>>>> 6.3. Registration of SIP Option Tag >>>>>>>> This section registers the new option tag. But I find >>>>>> almost nothing >>>>>>>> that defines the semantics of the option. (Section 5 does >>>>>> include the >>>>>>>> following: >>>>>>>> >>>>>>>>> A UA that supports this feature and the "uui" option >>>>>> tag MUST support >>>>>>>>> the call flows in [johnston-dispatch-sip-cc-uui]... >>>>>>>> but that is pretty thin from a normative perspective. >>>>>>>> >>>>>>>> Of particular note, does support for the option tag mean >>>>>> support for >>>>>>>> the particular encoding, content, and purpose included in this >>>>>>>> document? Or does it only mean support for the header and >>>>>> params in >>>>>>>> the abstract? (That wouldn't be very useful.) >>>>>>> Yes, this needs clarification. I'd suggest we define the >>>>>> option tag >>>>>>> to be uui-isdn which means it understands the header >>>> field and the >>>>>>> isdn-interwork purpose, and the call flows, including >>>> escaping into >>>>>>> redirection and Refer-To URIs. >>>>>> I'd like to hear some other opinions on whether to have >>>> tag per param >>>>>> for tag, or a tag for the combination of param values. I >>>> think I'm ok >>>>>> with what you propose. >>>>>> >>>>>>>> I don't see how it can mean support for some other yet to >>>>>> be defined >>>>>>>> values for those. Yet if it only means support for the >>>>>> current ones, >>>>>>>> then how will one indicate support for future ones? >>>>>>>> >>>>>>>> The only way out of this that I can see is to have >>>>>> separate options, >>>>>>>> either for particular values of each parameter, or for >>>> particular >>>>>>>> combinations of values of all the parameters. >>>>>>> New applications using this header field would have the >> option of >>>>>>> defining a new SIP option tag which would mean support for >>>>>> the header >>>>>>> field and their new purpose. >>>>>>> >>>>>>>> So you might have options uui-purpose-isdn-interwork, >>>>>>>> uui-content-isdn, and uui-encoding-hex. Or you might just >>>>>> have option >>>>>>>> uui-isdn-interwork that means the combination. >>>>>>> I think the latter. I see it as a hierarchy - the >> application or >>>>>>> purpose is the top one. Each purpose has a number of >>>>>> contents that it >>>>>>> supports. Each content has a number of encoding schemes it >>>>>> supports. >>>>>> >>>>>> I guess I'm ok with that, pending nailing down the definition of >>>>>> "purpose". >>>>>> >>>>>>>> I also am not finding much explanation of the semantics of the >>>>>>>> content and purpose parameters. I can only extrapolate >>>>>> from a single >>>>>>>> example of each, which I'm having trouble doing. >>>>>>>> >>>>>>>> I'm guessing that 'content' must refer to the precise >>>>>> syntax of the >>>>>>>> contained data, after decoding. So presumably it must map >>>>>> onto some >>>>>>>> particular spec. For isdn-uui, would that be [Q931] or >>>>>> [Q763]? If so, >>>>>>>> shouldn't it refer to something specific in that document? >>>>>>> Not really. In this case, isdn-uui effectively means >>>> "opaque data" >>>>>>> which is how ISDN defines the UUI - it is completely undefined, >>>>>>> necessarily so by the strict layering used in the ISDN >>>> application. >>>>>> I don't believe you! >>>>>> >>>>>> If that is the case, then the UAC and UAS must have a >> private side >>>>>> agreement about what the isdn-uui content means. Is that >>>> really what >>>>>> you mean? >>>>>> >>>>>> You already state that the first byte is a protocol >> discriminator. >>>>>> There must also be something, somewhere, that specifies >>>> the mapping >>>>>> from a particular value for that byte to a particular >>>>>> protocol/format. If there is, then that should be part of the >>>>>> definition of this content. >>>>>> >>>>>>>> 'purpose' is even less clear to me. Does it refer to why >>>>>> it is being >>>>>>>> included? Or what is to be done with it? If received by a >>>>>> UA that is >>>>>>>> not an ISDN gateway, how can it decide if this is >>>>>> something it should >>>>>>>> be trying to process? Is it still ISDN interworking if >>>> neither the >>>>>>>> UAC nor UAS is connected to an ISDN network? >>>>>>> The purpose is the application using the UUI. Others have >>>>>> expressed >>>>>>> an interest in carrying other data in the header field, in >>>>>> which case >>>>>>> a new purpose would be defined. I'll see if I can think of >>>>>> an example one. >>>>>> >>>>>> So are you saying that a particular call center >> application might >>>>>> constitute a distinct "purpose"? >>>>>> >>>>>>> Basically, if two UAs both support the header but have >> different >>>>>>> applications generating and consuming the UUI, it will not >>>>>> work. This >>>>>>> is not a SIP failure, and there is nothing SIP can do about >>>>>> it. But >>>>>>> this purpose header field allows the UAs to detect this >> condition. >>>>>> In that case, perhaps "isdn-interwork" isn't really a >>>> single purpose >>>>>> at all, unless any two pieces of equipment that support >>>> that purpose >>>>>> can then interwork without knowing any more about each other. >>>>>> >>>>>>>> Suppose I was developing a sophisticated UA that >>>>>> potentially might be >>>>>>>> usable by a call center operator. How should >>>>>> purpose=isdn-interwork >>>>>>>> affect the operation of this device? >>>>>>> To make it work in today's contact center applications, >>>> supporting >>>>>>> isdn-interwork would likely make it work in an application, >>>>>> provided >>>>>>> the appropriate call center application also ran on it. >>>>>> Some contact >>>>>>> centers do not use ISDN UUI, instead they use all kinds >>>> of really, >>>>>>> really ugly CTI protocols running in parallel. >>>>>> Yes, I know! :-( >>>>>> >>>>>>> This is a way of moving >>>>>>> those to the ISDN model, and from there to a more >>>>>> intelligent endpoint >>>>>>> SIP model. >>>>>>> >>>>>>>> Thanks, >>>>>>>> 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 gonzalo.camarillo@ericsson.com Tue Jul 28 06:32:53 2009 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 8CA5B3A6F79 for ; Tue, 28 Jul 2009 06:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 Q7IVU-95QZ4e for ; Tue, 28 Jul 2009 06:32:52 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1731C3A6F86 for ; Tue, 28 Jul 2009 06:32:51 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-21-4a6efe036292 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 6D.54.18827.30EFE6A4; Tue, 28 Jul 2009 15:32:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 15:32:48 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 15:32:48 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3FFFD2537; Tue, 28 Jul 2009 16:32:47 +0300 (EEST) Message-ID: <4A6EFDFE.9030707@ericsson.com> Date: Tue, 28 Jul 2009 15:32:46 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A5261E2.4050506@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <4A5348F5.5030200@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91D73@zrc2hxm0.corp.nortel.com> <4A536DF9.4020906@cisco.com> <1ECE0EB50388174790F9694F77522CCF1ED91E95@zrc2hxm0.corp.nortel.com> <4A537B66.4000608@cisco.com> <4A6450D6.90904@ericsson.com> <4A646F12.8070000@cisco.com> <4A6C3C62.6050006@ericsson.com> <4A6DAA38.8010709@cisco.com> <4A6EAEE4.2060206@ericsson.com> <4A6EF357.2070202@cisco.com> In-Reply-To: <4A6EF357.2070202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 13:32:48.0683 (UTC) FILETIME=[E5F9B7B0:01CA0F87] X-Brightmail-Tracker: AAAAAA== Cc: Henry Sinnreich , dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP 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, 28 Jul 2009 13:32:53 -0000 Hi Paul, yes, I agree we need to add use cases where both ends are distributed to the draft so that we understand this type of scenario in a better way. Cheers, Gonzalo Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: >> Hi Paul, >> >> yes, what you say is totally correct when one of the endpoints is not >> distributed. That case should be relatively-easy to resolve. The case >> where both ends are distributed is, of course, more "interesting" ;o) > > I don't understand at all how the "distributed" model works when both > ends want to be distributed. > > Thanks, > Paul > >> Cheers, >> >> Gonzalo >> >> Paul Kyzivat wrote: >>> >>> >>> Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>>> I guess the one way I could buy into your "distributed" approach is >>>>> to simply model it as a conference, where the focus is at one >>>>> "end". But I think we discussed that once. >>>> >>>> that is how it is modeled when only one of the ends is distributed. >>>> What we discussed was that the semantics of join were intended for >>>> conferences and that even though this was very similar, it was not >>>> the same thing... but the model is valid. >>> >>> If the model is valid, then I think the mechanisms that go with it >>> should be valid too. >>> >>> The conferencing mechanism could be used for either the "distributed" >>> or "centralized" approach. Then there needs to be a focus somewhere, >>> and the difference between the approaches is where it resides - at >>> your own end, or at the "other" end. >>> >>> Thanks, >>> Paul >> >> From HKaplan@acmepacket.com Tue Jul 28 08:41:52 2009 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 153E43A70B1 for ; Tue, 28 Jul 2009 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 qKPAtNyUjZOm for ; Tue, 28 Jul 2009 08:41:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ABAC23A6FF6 for ; Tue, 28 Jul 2009 08:41:50 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 28 Jul 2009 11:41:49 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 28 Jul 2009 11:41:49 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 28 Jul 2009 11:41:49 -0400 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoPCRWDdSdHrW/3SAagiCYeuQkXmAAjtdZw Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <4A6E2921.7080507@softarmor.com> In-Reply-To: <4A6E2921.7080507@softarmor.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@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 28 Jul 2009 15:41:52 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, July 27, 2009 6:25 PM >=20 > Hadriel Kaplan wrote: > > > >> -----Original Message----- From: Dean Willis > >> [mailto:dean.willis@softarmor.com] Sent: Monday, July 27, 2009 4:49 > >> AM To: Hadriel Kaplan > >> > >> I disagree. SIP is based on HTTP The Request URI encodes the > >> request being made by the UAC to the UAS. > > > > Then you might as well argue the request-URI should encode MIME > > bodies. The UUI is not a part of the resource being addressed in any > > way, and thus not a part of a Uniform Resource Identifier. >=20 > I take it you've never written an HTTP application using something like > the Common Gateway Interface (CGI) for parameter passing. Perhaps taking > some time to learn the history here would be helpful for you, so that > you stop making patently incorrect assertions about what can be in a > request URI. Au contraire, mon ami. I was not talking about the history of HTTP, nor do I care. (and to be fair= , the "history" of HTTP goes back before the term URI was ever invented, if= I recall). I am talking about the request URI in SIP. And I'm not talking about what = can/cannot be there - you can put whatever you want in it - I'm talking abo= ut what we should semantically expect/prescribe to be there from a standard= s usage perspective. =20 > Let's look at the request-URI used by the IETF tools team's draft search > page. >=20 > Take, for example: http://tools.ietf.org/id/?doc=3Dcommon > [snip] > Note that, in your parelance, "id" and "common" are NOT part of the > resource being addressed in any way.=20 I disagree. They are absolutely part of the resource being addressed. The= y are not a filename/directory/route identifier, but that doesn't matter. > Yet, they are encoded into the > resource, in such a way that they can easily be presented in writing, > pasted onto a business card, or whatever else you might want to do with > a URI. And that's exactly it! I cannot go around adding "/id/?doc=3Dcommon" to th= e end of every HTTP URI/URL and expect anything to work. Why? Because it = only has meaning to tools.ietf.org, the *target* of the HTTP request. UUI = is different. I can go add the same UUI value to every request I send rega= rdless of the target, because it's a property of, or based on, the *sender*= . (well, mostly... it's proprietary of course, so who the heck knows what's= in there) And while *anyone* can go add "/id/?doc=3Dcommon" to the tools.ietf.org URI= , if it were on a business card, for example - the same is not true of a UU= I's value. You could not put the UUI's hex value as a param into a busines= s card and have anyone/everyone use it to you and expect it to work right. = (again, generally speaking, ignoring the fact it's a proprietary blob)=20 -hadriel=20 From dean.willis@softarmor.com Tue Jul 28 16:49:34 2009 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 29E603A6C07 for ; Tue, 28 Jul 2009 16:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 RBRhKa7a3lBq for ; Tue, 28 Jul 2009 16:49:33 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5A75D3A6B93 for ; Tue, 28 Jul 2009 16:49:33 -0700 (PDT) Received: from [78.64.69.150] (host-78-64-69-150.homerun.telia.com [78.64.69.150]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6SNnTOr004044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 18:49:32 -0500 Message-ID: <4A6F8E88.3070408@softarmor.com> Date: Tue, 28 Jul 2009 18:49:28 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <4A6E2921.7080507@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 28 Jul 2009 23:49:34 -0000 Hadriel Kaplan wrote: > > And that's exactly it! I cannot go around adding "/id/?doc=common" > to the end of every HTTP URI/URL and expect anything to work. Why? > Because it only has meaning to tools.ietf.org, the *target* of the > HTTP request. UUI is different. I can go add the same UUI value to > every request I send regardless of the target, because it's a > property of, or based on, the *sender*. (well, mostly... it's > proprietary of course, so who the heck knows what's in there) Horsefeathers. It has nothing to do with the sender (UAC). Understanding the data is all up to the receiver (UAS). If UUI data were printed on a business card and entered on my Nokia phone (which I assure you, doesn't understand UUI) it would still be delivered to the receiver. If the receiver understands it, it can act on it with complete independence from any property of the sender. > And while *anyone* can go add "/id/?doc=common" to the tools.ietf.org > URI, if it were on a business card, for example - the same is not > true of a UUI's value. You could not put the UUI's hex value as a > param into a business card and have anyone/everyone use it to you and > expect it to work right. (again, generally speaking, ignoring the > fact it's a proprietary blob) That sort of depends on the UUI application, doesn't it? -- Dean From pkyzivat@cisco.com Tue Jul 28 18:14:16 2009 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 DF3923A696A for ; Tue, 28 Jul 2009 18:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 FRterxu4PT0E for ; Tue, 28 Jul 2009 18:14:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B0ACA3A6949 for ; Tue, 28 Jul 2009 18:14:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALQ/b0pAZnmf/2dsb2JhbAC8bYgnkCgFhBA X-IronPort-AV: E=Sophos;i="4.43,285,1246838400"; d="scan'208";a="52102189" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2009 01:14:16 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6T1EGmw022656; Tue, 28 Jul 2009 21:14:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6T1EGtk016571; Wed, 29 Jul 2009 01:14:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 21:14:16 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 21:14:15 -0400 Message-ID: <4A6FA268.2040506@cisco.com> Date: Tue, 28 Jul 2009 21:14:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dean Willis References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <4A6E2921.7080507@softarmor.com> <4A6F8E88.3070408@softarmor.com> In-Reply-To: <4A6F8E88.3070408@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2009 01:14:15.0990 (UTC) FILETIME=[E3F71D60:01CA0FE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2201; t=1248830056; x=1249694056; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20CCUS=20and=20History-Info= 20(was=20Proposed=20Charter=20for=20CCUS=0A=20-=20Call=20Con trol=20UUI=20for=20SIP) |Sender:=20 |To:=20Dean=20Willis=20; bh=1EUkmHPi1KLSY4cIWQ4AlPMyTw7fg0k+CowMOqYneuc=; b=iDPLY4rOaUI1sU0y3fmhix/JslWq2x1MSBaEfX2U5+VBFIZt5CjtLCQzRR dHgQUcEQVs9YZero/DQkINsujjtyx67rQNWTvjH47LquQwYajMIoU2grh/dR pLPp2ru8Jx; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 29 Jul 2009 01:14:17 -0000 Hadriel, I don't understand what you are trying to say at all. I *think* your are saying that UUI is like my scribbling any random garbage, in any notation I want, onto my business card and handing it to somebody, in expectation that they will be able to do something useful with it. I indeed *might* be able to do that, if I know precisely who I am handing the card to, and what sorts of things they understand, and the notations they will be able to process. But of course in this case I have to put this info into the INVITE before I know who I will end up talking to. Thanks, Paul Dean Willis wrote: > Hadriel Kaplan wrote: > >> And that's exactly it! I cannot go around adding "/id/?doc=common" >> to the end of every HTTP URI/URL and expect anything to work. Why? >> Because it only has meaning to tools.ietf.org, the *target* of the >> HTTP request. UUI is different. I can go add the same UUI value to >> every request I send regardless of the target, because it's a >> property of, or based on, the *sender*. (well, mostly... it's >> proprietary of course, so who the heck knows what's in there) > > > Horsefeathers. It has nothing to do with the sender (UAC). Understanding > the data is all up to the receiver (UAS). If UUI data were printed on a > business card and entered on my Nokia phone (which I assure you, doesn't > understand UUI) it would still be delivered to the receiver. If the > receiver understands it, it can act on it with complete independence > from any property of the sender. > >> And while *anyone* can go add "/id/?doc=common" to the tools.ietf.org >> URI, if it were on a business card, for example - the same is not >> true of a UUI's value. You could not put the UUI's hex value as a >> param into a business card and have anyone/everyone use it to you and >> expect it to work right. (again, generally speaking, ignoring the >> fact it's a proprietary blob) > > > That sort of depends on the UUI application, doesn't it? > > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Tue Jul 28 22:10:34 2009 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 914F43A6E53 for ; Tue, 28 Jul 2009 22:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 TVvcukpmbAnJ for ; Tue, 28 Jul 2009 22:10:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A281D3A6941 for ; Tue, 28 Jul 2009 22:10:32 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 29 Jul 2009 01:10:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 29 Jul 2009 01:10:32 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Dean Willis Date: Wed, 29 Jul 2009 01:10:29 -0400 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoP6fGaKANx9Ug7RP2JXAyc1Zi6TQAHvoNg Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <4A6E2921.7080507@softarmor.com> <4A6F8E88.3070408@softarmor.com> <4A6FA268.2040506@cisco.com> In-Reply-To: <4A6FA268.2040506@cisco.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@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 29 Jul 2009 05:10:34 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 28, 2009 9:14 PM > To: Dean Willis >=20 > Hadriel, > I don't understand what you are trying to say at all. > I *think* your are saying that UUI is like my scribbling any random > garbage, in any notation I want, onto my business card and handing it to > somebody, in expectation that they will be able to do something useful > with it. Nope, I said *if* we were to put it into the request-URI, then that's what = it would be like. I don't want to put it into the request-URI, because I t= hink the req-URI is the wrong semantic. Dean's saying we should put it in = the req-uri, because HTTP would.=20 =20 > I indeed *might* be able to do that, if I know precisely who I am > handing the card to, and what sorts of things they understand, and the > notations they will be able to process. But of course in this case I > have to put this info into the INVITE before I know who I will end up > talking to. Yup. > Dean Willis wrote: > > Hadriel Kaplan wrote: > > > >> And that's exactly it! I cannot go around adding "/id/?doc=3Dcommon" > >> to the end of every HTTP URI/URL and expect anything to work. Why? > >> Because it only has meaning to tools.ietf.org, the *target* of the > >> HTTP request. UUI is different. I can go add the same UUI value to > >> every request I send regardless of the target, because it's a > >> property of, or based on, the *sender*. (well, mostly... it's > >> proprietary of course, so who the heck knows what's in there) > > > > > > Horsefeathers. It has nothing to do with the sender (UAC). Understandin= g > > the data is all up to the receiver (UAS). If UUI data were printed on a > > business card and entered on my Nokia phone (which I assure you, doesn'= t > > understand UUI) it would still be delivered to the receiver. If the > > receiver understands it, it can act on it with complete independence > > from any property of the sender. > > > >> And while *anyone* can go add "/id/?doc=3Dcommon" to the tools.ietf.or= g > >> URI, if it were on a business card, for example - the same is not > >> true of a UUI's value. You could not put the UUI's hex value as a > >> param into a business card and have anyone/everyone use it to you and > >> expect it to work right. (again, generally speaking, ignoring the > >> fact it's a proprietary blob) > > > > > > That sort of depends on the UUI application, doesn't it? > > > > -- > > Dean > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From HKaplan@acmepacket.com Tue Jul 28 22:34:58 2009 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 154D33A6B99 for ; Tue, 28 Jul 2009 22:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 DbaxCk9kAOPB for ; Tue, 28 Jul 2009 22:34:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1DEDE3A690A for ; Tue, 28 Jul 2009 22:34:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 29 Jul 2009 01:34:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 29 Jul 2009 01:34:57 -0400 From: Hadriel Kaplan To: Dean Willis Date: Wed, 29 Jul 2009 01:34:57 -0400 Thread-Topic: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) Thread-Index: AcoP3g9hL5hJd4l3QnyIpnVNuV/YzwAK5y/w Message-ID: References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <4A6E2921.7080507@softarmor.com> <4A6F8E88.3070408@softarmor.com> In-Reply-To: <4A6F8E88.3070408@softarmor.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@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 29 Jul 2009 05:34:58 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, July 28, 2009 7:49 PM > To: Hadriel Kaplan >=20 > Horsefeathers. It has nothing to do with the sender (UAC). Understanding > the data is all up to the receiver (UAS). If UUI data were printed on a > business card and entered on my Nokia phone (which I assure you, doesn't > understand UUI) it would still be delivered to the receiver. If the > receiver understands it, it can act on it with complete independence > from any property of the sender. Poppycock. What's *in* the UUI can change based on who's sending it, even = if it's accessing the same target resource. The fact that the receiving UA= S' application above SIP has to understand it to use it, doesn't mean a hec= k of a lot. There's are plenty of existing SIP headers that I could enter = into your Nokia phone (were it to let me) that its SIP stack needs to know = nothing about to send the INVITE, that only the receiver has to understand.= Although I guess your point is that we were wrong to do that before, so w= e should stop doing it. (right?) > > And while *anyone* can go add "/id/?doc=3Dcommon" to the tools.ietf.org > > URI, if it were on a business card, for example - the same is not > > true of a UUI's value. You could not put the UUI's hex value as a > > param into a business card and have anyone/everyone use it to you and > > expect it to work right. (again, generally speaking, ignoring the > > fact it's a proprietary blob) >=20 >=20 > That sort of depends on the UUI application, doesn't it? Unfortunately yes. It's an opaque blob. It can have anything in it. =20 -hadriel From dean.willis@softarmor.com Wed Jul 29 06:05:13 2009 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 50FE53A6884 for ; Wed, 29 Jul 2009 06:05:13 -0700 (PDT) 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 Yv2pKplWGGw3 for ; Wed, 29 Jul 2009 06:05:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 21D673A682D for ; Wed, 29 Jul 2009 06:05:12 -0700 (PDT) Received: from [130.129.21.224] (dhcp-15e0.meeting.ietf.org [130.129.21.224]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TD57Tm011577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2009 08:05:10 -0500 Message-ID: <4A704902.1030603@softarmor.com> Date: Wed, 29 Jul 2009 08:05:06 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A6740CD.3070609@sipstation.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E9813@GBNTHT12009MSX.gb002.siemens.net> <4A685DC9.9080209@sipstation.com> <4A6AC91F.6030804@softarmor.com> <4A6B1A84.2060505@sipstation.com> <4A6D69E9.4030200@softarmor.com> <4A6E2921.7080507@softarmor.com> <4A6F8E88.3070408@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] CCUS and History-Info (was Proposed Charter for CCUS - Call Control UUI for SIP) 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, 29 Jul 2009 13:05:13 -0000 Hadriel Kaplan wrote: > > Poppycock. What's *in* the UUI can change based on who's sending it, > even if it's accessing the same target resource. The fact that the > receiving UAS' application above SIP has to understand it to use it, > doesn't mean a heck of a lot. There's are plenty of existing SIP > headers that I could enter into your Nokia phone (were it to let me) > that its SIP stack needs to know nothing about to send the INVITE, > that only the receiver has to understand. Although I guess your > point is that we were wrong to do that before, so we should stop > doing it. (right?) > Right. We totally molested the poodle by putting so much application-specific cruft into SIP extension header fields. HTTP has been able to support new applications without having to make a protocol extension for every new application because it does NOT put application data into HTTP extensions. Rather, it uses HTTP as a transport for the application data, which is what SIP should have done and what we really meant to do back when starting SIP. HTTP has two places to transport application-specific stuff: in the request URI, and in payloads. Application parameters are generally sent using the request URI. We have two alternatives to choose from: 1) Fix SIP so that we can use HTTP-style request URI parameterization. Currently, SIPCORE has consensus to do exactly this, using history-info. 2) Give up on using HTTP-style request-URI parameterization and develop an alternative. Adding application-specific SIP extensions for every different application is not a reasonable alternative. Dedicating a specific new extension field for all user-to-user parameters might be, and that's essentially what Alan has proposed. Pick one and use it. -- Dean > >>> And while *anyone* can go add "/id/?doc=common" to the >>> tools.ietf.org URI, if it were on a business card, for example - >>> the same is not true of a UUI's value. You could not put the >>> UUI's hex value as a param into a business card and have >>> anyone/everyone use it to you and expect it to work right. >>> (again, generally speaking, ignoring the fact it's a proprietary >>> blob) >> >> That sort of depends on the UUI application, doesn't it? > > Unfortunately yes. It's an opaque blob. It can have anything in it. > > > -hadriel > From spencer@wonderhamster.org Wed Jul 29 22:17:50 2009 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 2362C3A6FA1 for ; Wed, 29 Jul 2009 22:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, STOX_REPLY_TYPE=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 9Eg8Bg7qEUZ5 for ; Wed, 29 Jul 2009 22:17:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 1FAD73A6BFD for ; Wed, 29 Jul 2009 22:17:49 -0700 (PDT) Received: from S73602b (dhcp-42d5.meeting.ietf.org [130.129.66.213]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MWO1T1GDt-000P1J; Thu, 30 Jul 2009 01:17:50 -0400 Message-ID: <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> From: "Spencer Dawkins" To: "dispatch mailing list" References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> Date: Thu, 30 Jul 2009 00:14:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19MkeBTc5McKtBQ4IaFn7ZOTFwi4PAg3QDjk5O dX1fy3iLmuBUE5eullLmrWz7m7chdo0Gi7kaVkUhLSpXjaWdoj ZLk0va3jMEI8oVg3xEMpMHLD/3FYLBTDA9R8heQMi0= Cc: clf@ietf.org Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 overLunch on Friday 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, 30 Jul 2009 05:17:50 -0000 The SIP-CLF DISPATCH ad hoc on Friday is intended to form a working group, and we'll be noodling over charter text that Robert has produced (in consultation with others) during the meeting. Just to make sure we're all on the same page, here's the charter text we'll be discussing - please look it over BEFORE the meeting (and if you want to talk about it on the sip-clf@ietf.org mailing list before the meeting, that's fine, too): The SIP Common Log Format (CLF) working group is chartered to define a standard logging format for systems processing SIP messages. Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files to produce reports and trends and to search for a certain SIP message or messages, a transaction or a related set of transactions. Furthermore, these log records can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format. Diverse element provide distinct log formats making it complex to produce tools to analyze them. The CLF working group will produce a format suitable for logging from any SIP element. The format will anticipate the need to search, merge, and summarize the log records from diverse elements. The format will anticipate the need to correlate messages from multiple elements related to a given request (that may fork) or a given dialog. The format will take SIP's extensibility into consideration, providing a way to represent SIP message components that are defined in the future. The format will anticipate being used both for off-line analysis and on-line real-time processing applications. The working group will consider the need for efficient creation of records and the need for efficient processing of the records. The working group will identify the fields to appear in a log record and provide one or more formats for encoding those fields. The working group is not pre-constrained to producing either a bit-field oriented or text-oriented format, and may choose to provide both. If the group chooses to specify both, it must be possible to mechanically translate between the formats without loss of information. Specifying the mechanics of exchanging, transporting, and storing SIP Common Log Format records is explicitly out of scope. Specifying a real-time transfer mechanism for heuristic analysis is explicitly out of scope. The group will generate: A problem statement enunciating the motivation, and use cases for a SIP Common Log Format. This analysis will identify the required minimal information that must appear in any record. A specification of the SIP Common Log Format record The group will consider providing one or more reference implementations for decoding a CLF record. One more piece of logistics ... We'll need at least one, and preferably two, scribes and a jabber scribe for our CLF session on Friday during lunch. We'll call for volunteers at the meeting if necessary - we can't have the meeting without producing minutes - but it would be great if you could consider volunteering NOW. We have about an hour to get through some pretty important discussions, and every minute we DON'T spend gazing meaningfully at the attendees (us) and looking down at computers trying not to make eye contact with the chairs (you) is a minute that we can use more productively! Thanks, Spencer and Theo From tom.taylor@rogers.com Thu Jul 30 00:03:22 2009 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 BFF0B28C155 for ; Thu, 30 Jul 2009 00:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 EoCAkdN0t+si for ; Thu, 30 Jul 2009 00:03:22 -0700 (PDT) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by core3.amsl.com (Postfix) with SMTP id CBED828C13D for ; Thu, 30 Jul 2009 00:03:21 -0700 (PDT) Received: (qmail 51637 invoked from network); 30 Jul 2009 07:03:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rBOzWja9Rp01vUB+OWPfu9Qu4b+UpblBr/U0E82w4PSQ7xWFuqhBWEU8m2ThG36dgUOzBFtYZYmOXR1CEYfMT8rkP7QRF/WLlEsuklmJT+X+tP+ey4Y52qu0899yCBtDnMHMSXy4UARgmUv2uxS7wPdH6Gt9QwIstMEy8HcParI= ; Received: from unknown (HELO ?130.129.22.181?) (tom.taylor@130.129.22.181 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 30 Jul 2009 07:03:21 -0000 X-YMail-OSG: gWJ8oHIVM1kiU7rHAPfjGJpZFiThWR9jhwlzy3F.r8EYfnIMp6MbALe3QslQeLTYMA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A7145B7.9030707@rogers.com> Date: Thu, 30 Jul 2009 09:03:19 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Spencer Dawkins References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> In-Reply-To: <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch mailing list , clf@ietf.org Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 overLunch on Friday 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, 30 Jul 2009 07:03:22 -0000 Small comments below. Spencer Dawkins wrote: > The SIP-CLF DISPATCH ad hoc on Friday is intended to form a working group, > and we'll be noodling over charter text that Robert has produced (in > consultation with others) during the meeting. > > Just to make sure we're all on the same page, here's the charter text we'll > be discussing - please look it over BEFORE the meeting (and if you want > to talk about it on the sip-clf@ietf.org mailing list before the > meeting, that's fine, too): > > The SIP Common Log Format (CLF) working group is chartered to define a > standard logging format for systems processing SIP messages. > > Well-known web servers such as Apache and web proxies like Squid support > event logging using a common log format. The logs produced using these > de-facto standard formats are invaluable to system administrators for > trouble-shooting a server and tool writers to craft tools that mine the log > files to produce reports and trends and to search for a certain SIP message > or messages, a transaction or a related set of transactions. Furthermore, > these log records can also be used to train anomaly detection systems and > feed events into a security event management system. [PTT] Since this is a description of existing usage, I would drop "SIP" four lines up. > > The Session Initiation Protocol does not have a common log format. Diverse > element provide distinct log formats making it complex to produce tools to > analyze them. [PTT] element -> elements > ... From vkg@alcatel-lucent.com Thu Jul 30 00:49:32 2009 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 82D873A6E1D for ; Thu, 30 Jul 2009 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 WU0fwl6YSZV5 for ; Thu, 30 Jul 2009 00:49:31 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 013653A69AD for ; Thu, 30 Jul 2009 00:49:30 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n6U7nVZT008400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 02:49:31 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6U7nTUf012447; Thu, 30 Jul 2009 02:49:30 -0500 (CDT) Message-ID: <4A7150B6.1010603@alcatel-lucent.com> Date: Thu, 30 Jul 2009 02:50:14 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Tom Taylor References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> <4A7145B7.9030707@rogers.com> In-Reply-To: <4A7145B7.9030707@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: dispatch mailing list , clf@ietf.org Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 overLunch on Friday 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, 30 Jul 2009 07:49:32 -0000 Tom Taylor wrote: > Small comments below. [...] > [PTT] Since this is a description of existing usage, I would drop "SIP" > four lines up. Yes, I agree. I was about to make the same comment as well. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://ect.bell-labs.com/who/vkg From rajnish.jain@ipc.com Thu Jul 30 04:02:40 2009 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 3EEC128C1E8 for ; Thu, 30 Jul 2009 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_29=0.6] 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 GxVW8bPMdb+8 for ; Thu, 30 Jul 2009 04:02:39 -0700 (PDT) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by core3.amsl.com (Postfix) with ESMTP id 2EB8828C1E3 for ; Thu, 30 Jul 2009 04:02:39 -0700 (PDT) Received: from unknown [65.244.37.51] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net (mxl_mta-6.3.0-2) with ESMTP id 1dd717a4.ceb8db90.524805.00-507.984739.p01c11o145.mxlogic.net (envelope-from ); Thu, 30 Jul 2009 05:02:41 -0600 (MDT) X-MXL-Hash: 4a717dd12faf2c90-2becada8fe145778e4c37d5e0977c79316d5cbc9 Received: from unknown [65.244.37.51] by p01c11o145.mxlogic.net (mxl_mta-6.3.0-2) with SMTP id 59d717a4.0.524601.00-002.984648.p01c11o145.mxlogic.net (envelope-from ); Thu, 30 Jul 2009 05:02:27 -0600 (MDT) X-MXL-Hash: 4a717dc368c36de3-27c6b65ceebb36619021e9f94832737c87fb0d3e Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.27]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Thu, 30 Jul 2009 06:58:20 -0400 From: "Jain, Rajnish" To: "Doken, Serhad" , Vijay Gurbani , "dispatch@ietf.org" Date: Thu, 30 Jul 2009 06:58:24 -0400 Thread-Topic: [dispatch] Session Recording in SIP Thread-Index: Acny7zk28PigrO+0SryRcGZzpsB+WwLm/JUQAgaJJ4AAo1zOIAGFhHsQAG5Y/+A= Message-ID: References: <4A3F03F6.6060505@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16794.004 x-tm-as-result: No--43.570700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009071501)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=yoqeWMBPYRgA:10 a=z+2a4RCZxltofrpCDsS06w==:17 ] X-AnalysisOut: [a=cg4j_VLt3_JRueDtpegA:9 a=gxyG5BFqFiguIVtJz9MA:7 a=PrXkmZ] X-AnalysisOut: [lvMC2_QhPnvIQPAYOHzmgA:4 a=0Q1QvrLx6p-XA_3P:21 a=zAxivR6YM] X-AnalysisOut: [UY4WkOb:21] Subject: Re: [dispatch] Session Recording in SIP 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, 30 Jul 2009 11:02:40 -0000 Hi Serhad, Comments inline: > > Naming these things is always a bit tricky. If we called the RS simply > > the Recorder given your reasoning, then the RC should also be named > > differently (because the RC can act as the "server side" of the SRP > > signaling). The RS naming is a bit akin to the term "Media Server". If > > there is enough confusion on RS then, we can consider renaming it. > > Indeed, I think RC could be renamed as well since it is not a pure client > and can be a server at times. Using, Recording Client and Recording Serve= r > at section 1 before their definitions are given in Section 2 adds to the > confusion. I would offer something like Recorder and (Recorded Media) For= ker > which is self explanatory. The RC/RS naming is intended to be _logical_ as opposed to the client serve= r roles in an INVITE transaction. I'll try to gather design team's input on= this. > > What is the number of persistent recording > > > sessions per RC/RS ? > > > > That's an implementation-dependent choice. > > Obviously, however as I referred to in my subsequent question below, this > may have implications scaling up. If I have a device with high number of > simultaneous calls capability, media forker almost needs to keep that man= y > persistent recording sessions and refresh them all the time by session > timers. A bunch of race conditions may occur and it may be a drain of > resources on the device that is doing the media forking especially when > there is no actual session. Moreover, there will be certain assumptions m= ade > for such persistent recording sessions such as the codec used for the med= ia > session etc. These appear to be implementation issues. The SRP mechanism must allow for = scalable implementations, but I don't think we can state that RC and RS mus= t support 'n' number of session. > > > If recorded session media is stopped/temporarily interrupted due to > > problems > > > or features invoked on it(recording session is put on hold or started > > a > > > conferencing or transfer operation), how does that affect the already > > setup > > > recording session(s) ? > > > > I think that'll largely depend on the RC/RS implementations and the > > nature of the SRP sessions. For instance, if the recording sessions are > > persistent and the RC puts recorded session media on hold, then it RC > > MAY reINVITE the RS and put the recording session media on hold or it > > MAY just temporarily stop sending such media (silence suppression) to > > the RS. > > In that case, the recorded session and the persistent recording sessions > need to be synchronized back during resume which may bring the media > clipping problem that persistent recording attempted to solve in the firs= t > case. Persistent recording sessions will likely not use re-INVITEs for recording = session on recorded session hold/resume. They'll simply pause/resume record= ing session RTP. The metadata events will slightly lag behind this RTP acti= vity, but there will be timestamps in those events to achieve synchronizati= on. Thanks, Raj DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From rajnish.jain@ipc.com Thu Jul 30 04:17:44 2009 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 01FB23A6C0D for ; Thu, 30 Jul 2009 04:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 ftlKqvVSQOOs for ; Thu, 30 Jul 2009 04:17:43 -0700 (PDT) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by core3.amsl.com (Postfix) with ESMTP id 278BF3A6A0E for ; Thu, 30 Jul 2009 04:17:43 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net (mxl_mta-6.3.0-2) with ESMTP id 951817a4.9df3fb90.525280.00-512.985638.p01c11o145.mxlogic.net (envelope-from ); Thu, 30 Jul 2009 05:17:45 -0600 (MDT) X-MXL-Hash: 4a7181590c106823-cbac3ab9ec6f3dbce37f4f38a25ad8317d8d07a9 Received: from unknown [65.244.37.52] (EHLO smtp.ipc.com) by p01c11o145.mxlogic.net (mxl_mta-6.3.0-2) over TLS secured channel with ESMTP id b31817a4.0.525263.00-004.985600.p01c11o145.mxlogic.net (envelope-from ); Thu, 30 Jul 2009 05:17:31 -0600 (MDT) X-MXL-Hash: 4a71814b4609110f-143a14fa8200e18283966f2953c38bb65fab7dc3 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.27]) by STSNYHTCAS2.corp.root.ipc.com ([10.201.40.93]) with mapi; Thu, 30 Jul 2009 07:17:14 -0400 From: "Jain, Rajnish" To: "Doken, Serhad" , Leon Portman , Alan Johnston , "dispatch@ietf.org" Date: Thu, 30 Jul 2009 07:17:14 -0400 Thread-Topic: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppwAHDEl3AAbBzkIA== Message-ID: References: <4A69FD6A.4020205@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16794.004 x-tm-as-result: No--37.342400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009071501)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=1.0 c=1 a=D4USGbs0y0J827gn68Ljfg==:17 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=7FSLcVdvdOOWYAcfDgoA:9 a=uV57MIB1xYsRArT9OhEA:7 a=hDxoucB] X-AnalysisOut: [DGljsYGnUpckoli8PvDMA:4] Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 30 Jul 2009 11:17:44 -0000 > > I'm not sure that the Persistent and Dynamic Recording as defined above > > correspond to the Always On and On Demand modes defined in > > http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4. > > > > [LeonP] It is different in the way that the Recording Session is > > established only once during initialization (or login events) and then > > only media is forwarded per each call in order to minimize the > > clipping. > > I see the "Always On" Recording as a separate third mode of Recording whe= re > for a particular one or set of devices(possibly set via provisioning), al= l > calls are recorded from start to end(by setting up recording sessions) an= d > no persistent recording sessions are kept for them. I guess this is semantics, but wouldn't that still be "On Demand"? In your = scenario, it just so happens that the RC/RS have been configured to record = all calls for a given end-point, but the recording sessions are still estab= lished on a per call basis. Thanks, Raj DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From sanjsinh@cisco.com Thu Jul 30 07:35:55 2009 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 83FB53A719C for ; Thu, 30 Jul 2009 07:35:55 -0700 (PDT) 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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 CsbC6gYCVOVv for ; Thu, 30 Jul 2009 07:35:53 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DB8153A71A8 for ; Thu, 30 Jul 2009 07:35:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK9McUpAZnme/2dsb2JhbAC6XIgnkCMFhBE X-IronPort-AV: E=Sophos;i="4.43,295,1246838400"; d="scan'208";a="52260889" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2009 14:35:53 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6UEZpb0007661; Thu, 30 Jul 2009 10:35:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6UEZp3J027996; Thu, 30 Jul 2009 14:35:51 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:35:51 -0400 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, 30 Jul 2009 10:35:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch]Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppwAHDEl3AAbBzkIAACPZAQ References: <4A69FD6A.4020205@sipstation.com><07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> From: "Sanjay Sinha (sanjsinh)" To: "Jain, Rajnish" , "Doken, Serhad" , "Leon Portman" , "Alan Johnston" , X-OriginalArrivalTime: 30 Jul 2009 14:35:51.0578 (UTC) FILETIME=[09952FA0:01CA1123] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1474; t=1248964551; x=1249828551; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[dispatch]Comments=09on=09draft-jain-di spatch-session-recording-protocol-req-00 |Sender:=20 |To:=20=22Jain,=20Rajnish=22=20,=0A=2 0=20=20=20=20=20=20=20=22Doken,=20Serhad=22=20,=0A=20=20=20=20=20=20=20=20=22Leon=20Portman=22=20,=0A=20=20=20=20=20=20=20=20=22Alan=20J ohnston=22=20,=20; bh=FsfqeksahHKl3AbBGFFKifHjI3jNZDzfn46ezaP4Xnk=; b=ridwsL2+oNqnNsieUhQAsw2M+1Q9en38vGSOfTEMWMiwTEfbm/4gb2ARxp oHWdw0AMtIsnnupLSrlmwjH8eiri6LRplVEjmQNzFZl8Eh5l10kavy7byduv PewuBg+pku; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 30 Jul 2009 14:35:55 -0000 Pl. see inline ...=20 >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of Jain, Rajnish >Sent: Thursday, July 30, 2009 4:47 PM >To: Doken, Serhad; Leon Portman; Alan Johnston; dispatch@ietf.org >Subject: Re: [dispatch]Comments on=20 >draft-jain-dispatch-session-recording-protocol-req-00 > >> >> I see the "Always On" Recording as a separate third mode of=20 >Recording=20 >> where for a particular one or set of devices(possibly set via=20 >> provisioning), all calls are recorded from start to end(by=20 >setting up=20 >> recording sessions) and no persistent recording sessions are=20 >kept for them. > >I guess this is semantics, but wouldn't that still be "On=20 >Demand"? In your scenario, it just so happens that the RC/RS=20 >have been configured to record all calls for a given=20 >end-point, but the recording sessions are still established on=20 >a per call basis. This is similar to a recording anchor where during recording either RC or RS is designated as the recording anchor. For example in a call center, the external caller is the recording anchor and recording continues even when call is transferred to another agent, call is put on hold or another agent is conferenced, the recording from the caller device does not stop. The recording anchor also provides the metadata to the RS to keep track of different service interactions. Thanks > >Thanks, >Raj From rajnish.jain@ipc.com Thu Jul 30 08:00:47 2009 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 8D4233A71AA for ; Thu, 30 Jul 2009 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 YPTH8f5AH9bz for ; Thu, 30 Jul 2009 08:00:46 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 9021B3A6982 for ; Thu, 30 Jul 2009 08:00:46 -0700 (PDT) Received: from unknown [65.244.37.51] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net (mxl_mta-6.3.0-2) with ESMTP id 0a5b17a4.bc042b90.872028.00-504.1700400.p01c12o144.mxlogic.net (envelope-from ); Thu, 30 Jul 2009 09:00:48 -0600 (MDT) X-MXL-Hash: 4a71b5a05c2619c1-db2a8473ed93f119aea85a79383edfd783671ce9 Received: from unknown [65.244.37.51] by p01c12o144.mxlogic.net (mxl_mta-6.3.0-2) with SMTP id c85b17a4.0.871732.00-012.1700185.p01c12o144.mxlogic.net (envelope-from ); Thu, 30 Jul 2009 09:00:29 -0600 (MDT) X-MXL-Hash: 4a71b58d0050c3fe-907c5b444d27cb68946b437e13c2fbc5b5f7c503 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.2.27]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Thu, 30 Jul 2009 11:00:07 -0400 From: "Jain, Rajnish" To: "Sanjay Sinha (sanjsinh)" , "Doken, Serhad" , Leon Portman , Alan Johnston , "dispatch@ietf.org" Date: Thu, 30 Jul 2009 11:00:06 -0400 Thread-Topic: [dispatch]Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppwAHDEl3AAbBzkIAACPZAQAAVFwlA= Message-ID: References: <4A69FD6A.4020205@sipstation.com><07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16794.004 x-tm-as-result: No--38.138300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009071501)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=z+2a4RCZxltofrpCDsS06w==:17 a=AUd_NHdVAAAA:8 a] X-AnalysisOut: [=rd_hZMwNXrk22cojUFoA:9 a=zcszgMsat8DgrhLu4AIA:7 a=JsFdZLz] X-AnalysisOut: [eUF7lly5LFVDH42i_mwQA:4 a=JfD0Fch1gWkA:10 a=W3RyiZmDcVe3aa] X-AnalysisOut: [Cz:21 a=ykvIGFcOfA_AGfQj:21] Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 30 Jul 2009 15:00:47 -0000 Hi Sanjay, Pls. see inline: > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Sent: Thursday, July 30, 2009 10:36 AM > >I guess this is semantics, but wouldn't that still be "On > >Demand"? In your scenario, it just so happens that the RC/RS > >have been configured to record all calls for a given > >end-point, but the recording sessions are still established on > >a per call basis. > > This is similar to a recording anchor where during recording either RC > or RS is designated as the recording anchor. For example in a call > center, the external caller is the recording anchor and recording > continues even when call is transferred to another agent, call is put on > hold or another agent is conferenced, the recording from the caller > device does not stop. The recording anchor also provides the metadata to > the RS to keep track of different service interactions. That's a good use case. One way to look at this is that the RC is anchored = on the end-point that represents the external caller. This is also known as= line-side recording. Another way to look at this is that the RCs are ancho= red on the agent UAs and the metadata is used to correlate and construct th= e overall call. This is also known as station-side recording. I'd imagine that this use case (regardless of where the RC is anchored) cou= ld still be addressed through either On-Demand or Always-on recording modes= . I don't see this as a separate recording mode, unless I'm missing somethi= ng. Thanks, Raj DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From sdoken@qualcomm.com Fri Jul 31 00:25:02 2009 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 C1E2B3A6BD2 for ; Fri, 31 Jul 2009 00:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 Hb+N9DUC3nL6 for ; Fri, 31 Jul 2009 00:25:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 94A673A67E3 for ; Fri, 31 Jul 2009 00:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1249025103; x=1280561103; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "Jain,=20Rajnish"=20,=0D=0A=20=20 =20=20=20=20=20=20Vijay=20Gurbani=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"dispatch@ietf.or g"=20|Date:=20Fri,=2031=20Jul=202009 =2000:24:55=20-0700|Subject:=20RE:=20[dispatch]=20Session =20Recording=20in=20SIP|Thread-Topic:=20[dispatch]=20Sess ion=20Recording=20in=20SIP|Thread-Index:=20Acny7zk28PigrO +0SryRcGZzpsB+WwLm/JUQAgaJJ4AAo1zOIAGFhHsQAG5Y/+AAKoerAA =3D=3D|Message-ID:=20|References:=20<4A3F0 3F6.6060505@alcatel-lucent.com>=0D=0A=20 =0D=0A=20=0D=0A=20=0D=0A=20 =0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5693"=3B=20a=3D"21495136"; bh=d9+VHI4VruhZpxYDWdAEguv8swTvqz0QVTsRWkQ1ZFI=; b=WfV6abUI2Ni2t9IjD7UYLwfkRovpfBA8TDsHriEz2gbYwwp0NQEVjW0g MO14R5Q93F1OX5jwSfxdTuweKYkrpGirXA/j1qFYxMwTm3zk70GDGE0dY 5mOWo5hhT1pcoXg9/ti8/h1u5q9+p/Zp2Yq8IZ7TUSDuHsUzzHKEo9m88 Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5693"; a="21495136" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2009 00:25:03 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6V7P32Z024428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Jul 2009 00:25:03 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6V7Owek001051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Jul 2009 00:25:02 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 31 Jul 2009 00:24:58 -0700 From: "Doken, Serhad" To: "Jain, Rajnish" , Vijay Gurbani , "dispatch@ietf.org" Date: Fri, 31 Jul 2009 00:24:55 -0700 Thread-Topic: [dispatch] Session Recording in SIP Thread-Index: Acny7zk28PigrO+0SryRcGZzpsB+WwLm/JUQAgaJJ4AAo1zOIAGFhHsQAG5Y/+AAKoerAA== Message-ID: References: <4A3F03F6.6060505@alcatel-lucent.com> 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] Session Recording in SIP 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, 31 Jul 2009 07:25:02 -0000 Hi Rajnish, > -----Original Message----- > From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] > Sent: Thursday, July 30, 2009 3:58 AM > To: Doken, Serhad; Vijay Gurbani; dispatch@ietf.org > Subject: RE: [dispatch] Session Recording in SIP >=20 > Hi Serhad, >=20 > Comments inline: >=20 > > > Naming these things is always a bit tricky. If we called the RS > simply > > > the Recorder given your reasoning, then the RC should also be named > > > differently (because the RC can act as the "server side" of the SRP > > > signaling). The RS naming is a bit akin to the term "Media Server". > If > > > there is enough confusion on RS then, we can consider renaming it. > > > > Indeed, I think RC could be renamed as well since it is not a pure > client > > and can be a server at times. Using, Recording Client and Recording > Server > > at section 1 before their definitions are given in Section 2 adds to > the > > confusion. I would offer something like Recorder and (Recorded Media) > Forker > > which is self explanatory. >=20 > The RC/RS naming is intended to be _logical_ as opposed to the client > server roles in an INVITE transaction. I'll try to gather design team's > input on this. >=20 > > > What is the number of persistent recording > > > > sessions per RC/RS ? > > > > > > That's an implementation-dependent choice. > > > > Obviously, however as I referred to in my subsequent question below, > this > > may have implications scaling up. If I have a device with high number > of > > simultaneous calls capability, media forker almost needs to keep that > many > > persistent recording sessions and refresh them all the time by > session > > timers. A bunch of race conditions may occur and it may be a drain of > > resources on the device that is doing the media forking especially > when > > there is no actual session. Moreover, there will be certain > assumptions made > > for such persistent recording sessions such as the codec used for the > media > > session etc. >=20 > These appear to be implementation issues. The SRP mechanism must allow > for scalable implementations, but I don't think we can state that RC > and RS must support 'n' number of session. >=20 It could be more than implementation issues especially for the enviroments = where the media forker (RC) is limited in its capabilities such as memory, = power, bandwidth. For such cases it is preferable that the Recorder(RS) set= s up the persistent recording sessions. >=20 > > > > If recorded session media is stopped/temporarily interrupted due > to > > > problems > > > > or features invoked on it(recording session is put on hold or > started > > > a > > > > conferencing or transfer operation), how does that affect the > already > > > setup > > > > recording session(s) ? > > > > > > I think that'll largely depend on the RC/RS implementations and the > > > nature of the SRP sessions. For instance, if the recording sessions > are > > > persistent and the RC puts recorded session media on hold, then it > RC > > > MAY reINVITE the RS and put the recording session media on hold or > it > > > MAY just temporarily stop sending such media (silence suppression) > to > > > the RS. > > > > In that case, the recorded session and the persistent recording > sessions > > need to be synchronized back during resume which may bring the media > > clipping problem that persistent recording attempted to solve in the > first > > case. >=20 > Persistent recording sessions will likely not use re-INVITEs for > recording session on recorded session hold/resume. They'll simply > pause/resume recording session RTP. The metadata events will slightly > lag behind this RTP activity, but there will be timestamps in those > events to achieve synchronization. That is interesting. Since we are requirement phase, I will hold off my tho= ughts till the solution draft. Thanks, Serhad Doken >=20 > Thanks, > Raj >=20 >=20 >=20 > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the > sender that you have received it in error. Unintended recipients are > prohibited from taking action on the basis of information in this e- > mail.E-mail messages may contain computer viruses or other defects, may > not be accurately replicated on other systems, or may be intercepted, > deleted or interfered with without the knowledge of the sender or the > intended recipient. If you are not comfortable with the risks > associated with e-mail messages, you may decide not to use e-mail to > communicate with IPC. IPC reserves the right, to the extent and under > circumstances permitted by applicable law, to retain, monitor and > intercept e-mail messages to and from its systems. From sdoken@qualcomm.com Fri Jul 31 00:54:35 2009 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 EEEC33A6C27 for ; Fri, 31 Jul 2009 00:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 FRgPekrVTEje for ; Fri, 31 Jul 2009 00:54:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 7956228C1C7 for ; Fri, 31 Jul 2009 00:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1249026873; x=1280562873; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "Jain,=20Rajnish"=20,=0D=0A=20=20 =20=20=20=20=20=20Leon=20Portman=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Alan=20Johnston=20< alan@sipstation.com>,=0D=0A=20=20=20=20=20=20=20=20"dispa tch@ietf.org"=20|Date:=20Fri,=2031=20J ul=202009=2000:54:30=20-0700|Subject:=20RE:=20[dispatch] =09Comments=09on=0D=0A=09draft-jain-dispatch-session-reco rding-protocol-req-00|Thread-Topic:=20[dispatch]=09Commen ts=09on=0D=0A=09draft-jain-dispatch-session-recording-pro tocol-req-00|Thread-Index:=20AcoMjLJ6ThzVzaclTwCm7I3jEBcc 0QBBkppwAHDEl3AAbBzkIAAqmxLw|Message-ID:=20|References:=20<4A69FD6A.4020205@sipstation.com>=0D=0A =09<07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.n ice.com>=0D=0A=20=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5693"=3B=20a=3D"21495850"; bh=wYZK6EkViNsZftFBBX0A7pO36dhmc2wtBM7Pj0y6Xsc=; b=V0igFG5RNxacMOBVJbzQ7zJgvyBK5HZ1tUs6HyuyO0SOrdHoj3c1tUmB MQOiDaV1tLEov3rn0g0p+5ksPDM4Mi+zxXMqgj3WHAfS85ANS4ptbdo2M C7X3QHVsO7RE7QApQM5daPHfnVUeZ2klZ56IdHOrAvCneSSwhMDLzG5p6 w=; X-IronPort-AV: E=McAfee;i="5300,2777,5693"; a="21495850" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2009 00:54:33 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6V7sXrg002979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Jul 2009 00:54:33 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6V7sWfP023826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Jul 2009 00:54:32 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 31 Jul 2009 00:54:32 -0700 From: "Doken, Serhad" To: "Jain, Rajnish" , Leon Portman , Alan Johnston , "dispatch@ietf.org" Date: Fri, 31 Jul 2009 00:54:30 -0700 Thread-Topic: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00 Thread-Index: AcoMjLJ6ThzVzaclTwCm7I3jEBcc0QBBkppwAHDEl3AAbBzkIAAqmxLw Message-ID: References: <4A69FD6A.4020205@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D51541F2@TLVMBX01.nice.com> 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] Comments on draft-jain-dispatch-session-recording-protocol-req-00 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, 31 Jul 2009 07:54:36 -0000 > -----Original Message----- > From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] > Sent: Thursday, July 30, 2009 4:17 AM > To: Doken, Serhad; Leon Portman; Alan Johnston; dispatch@ietf.org > Subject: RE: [dispatch] Comments on draft-jain-dispatch-session- > recording-protocol-req-00 >=20 > > > I'm not sure that the Persistent and Dynamic Recording as defined > above > > > correspond to the Always On and On Demand modes defined in > > > http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section- > 4. > > > > > > [LeonP] It is different in the way that the Recording Session is > > > established only once during initialization (or login events) and > then > > > only media is forwarded per each call in order to minimize the > > > clipping. > > > > I see the "Always On" Recording as a separate third mode of Recording > where > > for a particular one or set of devices(possibly set via > provisioning), all > > calls are recorded from start to end(by setting up recording > sessions) and > > no persistent recording sessions are kept for them. >=20 > I guess this is semantics, but wouldn't that still be "On Demand"? In > your scenario, it just so happens that the RC/RS have been configured > to record all calls for a given end-point, but the recording sessions > are still established on a per call basis. The nuance I was thinking in my scenario is RC or RS avoids the need notify= the other via signaling to kick off the recording session which I consider= this notification process as on demand. So, yes in the end, I agree it is = mostly semantics. >=20 > Thanks, > Raj >=20 >=20 >=20 > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the > sender that you have received it in error. Unintended recipients are > prohibited from taking action on the basis of information in this e- > mail.E-mail messages may contain computer viruses or other defects, may > not be accurately replicated on other systems, or may be intercepted, > deleted or interfered with without the knowledge of the sender or the > intended recipient. If you are not comfortable with the risks > associated with e-mail messages, you may decide not to use e-mail to > communicate with IPC. IPC reserves the right, to the extent and under > circumstances permitted by applicable law, to retain, monitor and > intercept e-mail messages to and from its systems. From spencer@wonderhamster.org Fri Jul 31 01:56:35 2009 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 801F33A6DDD for ; Fri, 31 Jul 2009 01:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 PYmwy4GrEAut for ; Fri, 31 Jul 2009 01:56:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 7DF9C3A6805 for ; Fri, 31 Jul 2009 01:56:34 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MWnui13bI-000Osf; Fri, 31 Jul 2009 04:56:35 -0400 Message-ID: From: "Spencer Dawkins" To: "dispatch mailing list" References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> Date: Fri, 31 Jul 2009 10:56:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+0eLyZlthsMX1lwQ0XFP09UfafNhrbn9Y3oNH S8Zxv9/cA/G/GGsLpwEAKh8isXTjgrSZ/aKe83Jav1/UZEEdZJ 6u4c30WkE/jf9DNwHGYySH5zQ9oVVwfMrcRctGx2U0= Cc: clf@ietf.org Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 overLunchon Friday 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, 31 Jul 2009 08:56:35 -0000 Just to let people know - Mary has graciously posted the SIP-CLF slides to the meeting materials page (since this is a DISPATCH ad hoc, they're under DISPATCH). URLs are http://www.ietf.org/proceedings/75/slides/dispatch-6.ppt http://www.ietf.org/proceedings/75/slides/dispatch-5.pdf See you in about an hour... Spencer > The SIP-CLF DISPATCH ad hoc on Friday is intended to form a working group, > and we'll be noodling over charter text that Robert has produced (in > consultation with others) during the meeting. > > Just to make sure we're all on the same page, here's the charter text > we'll > be discussing - please look it over BEFORE the meeting (and if you want to > talk about it on the sip-clf@ietf.org mailing list before the meeting, > that's fine, too): > > The SIP Common Log Format (CLF) working group is chartered to define a > standard logging format for systems processing SIP messages. > > Well-known web servers such as Apache and web proxies like Squid support > event logging using a common log format. The logs produced using these > de-facto standard formats are invaluable to system administrators for > trouble-shooting a server and tool writers to craft tools that mine the > log > files to produce reports and trends and to search for a certain SIP > message > or messages, a transaction or a related set of transactions. Furthermore, > these log records can also be used to train anomaly detection systems and > feed events into a security event management system. > > The Session Initiation Protocol does not have a common log format. Diverse > element provide distinct log formats making it complex to produce tools to > analyze them. > > The CLF working group will produce a format suitable for logging from any > SIP element. The format will anticipate the need to search, merge, and > summarize the log records from diverse elements. The format will > anticipate > the need to correlate messages from multiple elements related to a given > request (that may fork) or a given dialog. The format will take SIP's > extensibility into consideration, providing a way to represent SIP message > components that are defined in the future. The format will anticipate > being > used both for off-line analysis and on-line real-time processing > applications. The working group will consider the need for efficient > creation of records and the need for efficient processing of the records. > > The working group will identify the fields to appear in a log record and > provide one or more formats for encoding those fields. The working group > is > not pre-constrained to producing either a bit-field oriented or > text-oriented format, and may choose to provide both. If the group chooses > to specify both, it must be possible to mechanically translate between the > formats without loss of information. > > Specifying the mechanics of exchanging, transporting, and storing SIP > Common Log Format records is explicitly out of scope. Specifying a > real-time > transfer mechanism for heuristic analysis is explicitly out of scope. > > The group will generate: > > A problem statement enunciating the motivation, and use cases for a SIP > Common Log Format. This analysis will identify the required minimal > information that must appear in any record. > > A specification of the SIP Common Log Format record > > The group will consider providing one or more reference implementations > for > decoding a CLF record. > > One more piece of logistics ... > > We'll need at least one, and preferably two, scribes and a jabber scribe > for > our CLF session on Friday during lunch. > > We'll call for volunteers at the meeting if necessary - we can't have the > meeting without producing minutes - but it would be great if you could > consider volunteering NOW. > > We have about an hour to get through some pretty important discussions, > and > every minute we DON'T spend gazing meaningfully at the attendees (us) and > looking down at computers trying not to make eye contact with the chairs > (you) is a minute that we can use more productively! > > Thanks, > > Spencer and Theo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From rjsparks@nostrum.com Fri Jul 31 03:07:19 2009 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 4E65D3A6960; Fri, 31 Jul 2009 03:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 z4whub+KjX2f; Fri, 31 Jul 2009 03:07:18 -0700 (PDT) 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 2046A3A68B7; Fri, 31 Jul 2009 03:07:17 -0700 (PDT) Received: from dhcp-26f2.meeting.ietf.org (dhcp-26f2.meeting.ietf.org [130.129.38.242]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6VA7G1m052659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2009 05:07:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: dispatch mailing list , sip-clf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 12:07:14 +0200 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 130.129.38.242 is authenticated by a trusted mechanism) Subject: [dispatch] Next revision for the proposed CLF charter 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, 31 Jul 2009 10:07:19 -0000 The SIP Common Log Format (CLF) working group is chartered to define a standard logging format for systems processing SIP messages. Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files to produce reports and trends and to search for a certain message or messages, a transaction or a related set of transactions. Furthermore, these log records can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format. Diverse elements provide distinct log formats making it complex to produce tools to analyze them. The CLF working group will produce a format suitable for logging from any SIP element. The format will anticipate the need to search, merge, and summarize the log records from diverse elements. The format will anticipate the need to correlate messages from multiple elements related to a given request (that may fork) or a given dialog. The format will take SIP's extensibility into consideration, providing a way to represent SIP message components that are defined in the future. The format will anticipate being used both for off-line analysis and on-line real-time processing applications. The working group will consider the need for efficient creation of records and the need for efficient processing of the records. The working group will identify the fields to appear in a log record and provide one or more formats for encoding those fields. The working group is not pre-constrained to producing either a bit-field oriented or text-oriented format, and may choose to provide both. If the group chooses to specify both, it must be possible to mechanically translate between the formats without loss of information. Specifying the mechanics of exchanging, transporting, and storing SIP Common Log Format records is explicitly out of scope. Specifying a real-time transfer mechanism for heuristic analysis is explicitly out of scope. The group will generate: - A problem statement enunciating the motivation, and use cases for a SIP Common Log Format. This analysis will identify the required minimal information that must appear in any record. - A specification of the SIP Common Log Format record The group will consider providing one or more reference implementations for decoding a CLF record. Goals and Milestones =========================== Oct 09 - Problem statement, motivation, and use cases WGLC Nov 09 - Problem statement, motivation, and use cases to IESG (Informational) Jan 10 - SIP Common Log Format specification WGLC Feb 10 - SIP Common Log Format specification to IESG (PS) From Jan.Seedorf@nw.neclab.eu Fri Jul 31 04:04:44 2009 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 257733A68E8 for ; Fri, 31 Jul 2009 04:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, 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 2MT7MbHNfiFU for ; Fri, 31 Jul 2009 04:04:43 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DC1573A6825 for ; Fri, 31 Jul 2009 04:04:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 353402C0012C6; Fri, 31 Jul 2009 13:04:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8+Ht0ji-Lyw; Fri, 31 Jul 2009 13:04:44 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 097122C0012C4; Fri, 31 Jul 2009 13:04:34 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 31 Jul 2009 13:04:34 +0200 Message-ID: In-Reply-To: <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 overLunchon Friday Thread-Index: AcoQ1SVnTszlp9g5RKuZ13f6NiVqzAA91j3A References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com> <2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> From: "Jan Seedorf" To: "Spencer Dawkins" , "dispatch mailing list" Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 overLunchon Friday 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, 31 Jul 2009 11:04:44 -0000 Dear Spencer, Are the slides from the bof available? And who was the second chair of = the bof? - Jan > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Donnerstag, 30. Juli 2009 00:14 > To: dispatch mailing list > Cc: clf@ietf.org > Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 > overLunchon Friday >=20 > The SIP-CLF DISPATCH ad hoc on Friday is intended to form a working > group, > and we'll be noodling over charter text that Robert has produced (in > consultation with others) during the meeting. >=20 > Just to make sure we're all on the same page, here's the charter text > we'll > be discussing - please look it over BEFORE the meeting (and if you = want > to > talk about it on the sip-clf@ietf.org mailing list before the meeting, > that's fine, too): >=20 > The SIP Common Log Format (CLF) working group is chartered to define a > standard logging format for systems processing SIP messages. >=20 > Well-known web servers such as Apache and web proxies like Squid > support > event logging using a common log format. The logs produced using these > de-facto standard formats are invaluable to system administrators for > trouble-shooting a server and tool writers to craft tools that mine = the > log > files to produce reports and trends and to search for a certain SIP > message > or messages, a transaction or a related set of transactions. > Furthermore, > these log records can also be used to train anomaly detection systems > and > feed events into a security event management system. >=20 > The Session Initiation Protocol does not have a common log format. > Diverse > element provide distinct log formats making it complex to produce = tools > to > analyze them. >=20 > The CLF working group will produce a format suitable for logging from > any > SIP element. The format will anticipate the need to search, merge, and > summarize the log records from diverse elements. The format will > anticipate > the need to correlate messages from multiple elements related to a > given > request (that may fork) or a given dialog. The format will take SIP's > extensibility into consideration, providing a way to represent SIP > message > components that are defined in the future. The format will anticipate > being > used both for off-line analysis and on-line real-time processing > applications. The working group will consider the need for efficient > creation of records and the need for efficient processing of the > records. >=20 > The working group will identify the fields to appear in a log record > and > provide one or more formats for encoding those fields. The working > group is > not pre-constrained to producing either a bit-field oriented or > text-oriented format, and may choose to provide both. If the group > chooses > to specify both, it must be possible to mechanically translate between > the > formats without loss of information. >=20 > Specifying the mechanics of exchanging, transporting, and storing SIP > Common Log Format records is explicitly out of scope. Specifying a > real-time > transfer mechanism for heuristic analysis is explicitly out of scope. >=20 > The group will generate: >=20 > A problem statement enunciating the motivation, and use cases for a = SIP > Common Log Format. This analysis will identify the required minimal > information that must appear in any record. >=20 > A specification of the SIP Common Log Format record >=20 > The group will consider providing one or more reference = implementations > for > decoding a CLF record. >=20 > One more piece of logistics ... >=20 > We'll need at least one, and preferably two, scribes and a jabber > scribe for > our CLF session on Friday during lunch. >=20 > We'll call for volunteers at the meeting if necessary - we can't have > the > meeting without producing minutes - but it would be great if you could > consider volunteering NOW. >=20 > We have about an hour to get through some pretty important = discussions, > and > every minute we DON'T spend gazing meaningfully at the attendees (us) > and > looking down at computers trying not to make eye contact with the > chairs > (you) is a minute that we can use more productively! >=20 > Thanks, >=20 > Spencer and Theo >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Fri Jul 31 04:12:37 2009 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 0FFDA3A6A3B for ; Fri, 31 Jul 2009 04:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fZ6XC26XqbJD for ; Fri, 31 Jul 2009 04:12:35 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8C76E3A6C4D for ; Fri, 31 Jul 2009 04:12:35 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6VBAj216325; Fri, 31 Jul 2009 11:10:45 GMT 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_01CA11CF.CCC54D26" Date: Fri, 31 Jul 2009 06:11:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1BF5FE5B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300overLunchon Friday thread-index: AcoQ1SVnTszlp9g5RKuZ13f6NiVqzAA91j3AAADONQQ= References: <8889A362-7C1C-4712-94CC-3A0C9B6B6F79@nostrum.com><2D74BB779EAF4B5CBCF19030A9BA3E70@china.huawei.com> From: "Mary Barnes" To: "Jan Seedorf" , "Spencer Dawkins" , "dispatch mailing list" Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300overLunchon Friday 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, 31 Jul 2009 11:12:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA11CF.CCC54D26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The charts are in the meeting materials for IETF-75 under the DISPATCH = working group. Theo was the second chair. Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org on behalf of Jan Seedorf Sent: Fri 7/31/2009 6:04 AM To: Spencer Dawkins; dispatch mailing list Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room = 300overLunchon Friday =20 Dear Spencer, Are the slides from the bof available? And who was the second chair of = the bof? - Jan > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Donnerstag, 30. Juli 2009 00:14 > To: dispatch mailing list > Cc: clf@ietf.org > Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room 300 > overLunchon Friday >=20 > The SIP-CLF DISPATCH ad hoc on Friday is intended to form a working > group, > and we'll be noodling over charter text that Robert has produced (in > consultation with others) during the meeting. >=20 > Just to make sure we're all on the same page, here's the charter text > we'll > be discussing - please look it over BEFORE the meeting (and if you = want > to > talk about it on the sip-clf@ietf.org mailing list before the meeting, > that's fine, too): >=20 > The SIP Common Log Format (CLF) working group is chartered to define a > standard logging format for systems processing SIP messages. >=20 > Well-known web servers such as Apache and web proxies like Squid > support > event logging using a common log format. The logs produced using these > de-facto standard formats are invaluable to system administrators for > trouble-shooting a server and tool writers to craft tools that mine = the > log > files to produce reports and trends and to search for a certain SIP > message > or messages, a transaction or a related set of transactions. > Furthermore, > these log records can also be used to train anomaly detection systems > and > feed events into a security event management system. >=20 > The Session Initiation Protocol does not have a common log format. > Diverse > element provide distinct log formats making it complex to produce = tools > to > analyze them. >=20 > The CLF working group will produce a format suitable for logging from > any > SIP element. The format will anticipate the need to search, merge, and > summarize the log records from diverse elements. The format will > anticipate > the need to correlate messages from multiple elements related to a > given > request (that may fork) or a given dialog. The format will take SIP's > extensibility into consideration, providing a way to represent SIP > message > components that are defined in the future. The format will anticipate > being > used both for off-line analysis and on-line real-time processing > applications. The working group will consider the need for efficient > creation of records and the need for efficient processing of the > records. >=20 > The working group will identify the fields to appear in a log record > and > provide one or more formats for encoding those fields. The working > group is > not pre-constrained to producing either a bit-field oriented or > text-oriented format, and may choose to provide both. If the group > chooses > to specify both, it must be possible to mechanically translate between > the > formats without loss of information. >=20 > Specifying the mechanics of exchanging, transporting, and storing SIP > Common Log Format records is explicitly out of scope. Specifying a > real-time > transfer mechanism for heuristic analysis is explicitly out of scope. >=20 > The group will generate: >=20 > A problem statement enunciating the motivation, and use cases for a = SIP > Common Log Format. This analysis will identify the required minimal > information that must appear in any record. >=20 > A specification of the SIP Common Log Format record >=20 > The group will consider providing one or more reference = implementations > for > decoding a CLF record. >=20 > One more piece of logistics ... >=20 > We'll need at least one, and preferably two, scribes and a jabber > scribe for > our CLF session on Friday during lunch. >=20 > We'll call for volunteers at the meeting if necessary - we can't have > the > meeting without producing minutes - but it would be great if you could > consider volunteering NOW. >=20 > We have about an hour to get through some pretty important = discussions, > and > every minute we DON'T spend gazing meaningfully at the attendees (us) > and > looking down at computers trying not to make eye contact with the > chairs > (you) is a minute that we can use more productively! >=20 > Thanks, >=20 > Spencer and Theo >=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 ------_=_NextPart_001_01CA11CF.CCC54D26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dispatch] Room for DISPATCH ad-hoc on CLF : Room = 300overLunchon Friday

The charts are in the meeting materials for IETF-75 = under the DISPATCH working group.  Theo was the second chair.

Mary.


-----Original Message-----
From: dispatch-bounces@ietf.org on behalf of Jan Seedorf
Sent: Fri 7/31/2009 6:04 AM
To: Spencer Dawkins; dispatch mailing list
Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room = 300overLunchon Friday

Dear Spencer,

Are the slides from the bof available? And who was the second chair of = the bof?

 - Jan

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.or= g] On
> Behalf Of Spencer Dawkins
> Sent: Donnerstag, 30. Juli 2009 00:14
> To: dispatch mailing list
> Cc: clf@ietf.org
> Subject: Re: [dispatch] Room for DISPATCH ad-hoc on CLF : Room = 300
> overLunchon Friday
>
> The SIP-CLF DISPATCH ad hoc on Friday is intended to form a = working
> group,
> and we'll be noodling over charter text that Robert has produced = (in
> consultation with others) during the meeting.
>
> Just to make sure we're all on the same page, here's the charter = text
> we'll
> be discussing - please look it over BEFORE the meeting (and if you = want
> to
> talk about it on the sip-clf@ietf.org mailing list before the = meeting,
> that's fine, too):
>
> The SIP Common Log Format (CLF) working group is chartered to = define a
> standard logging format for systems processing SIP messages.
>
> Well-known web servers such as Apache and web proxies like = Squid
> support
> event logging using a common log format. The logs produced using = these
> de-facto standard formats are invaluable to system administrators = for
> trouble-shooting a server and tool writers to craft tools that mine = the
> log
> files to produce reports and trends and to search for a certain = SIP
> message
> or messages, a transaction or a related set of transactions.
> Furthermore,
> these log records can also be used to train anomaly detection = systems
> and
> feed events into a security event management system.
>
> The Session Initiation Protocol does not have a common log = format.
> Diverse
> element provide distinct log formats making it complex to produce = tools
> to
> analyze them.
>
> The CLF working group will produce a format suitable for logging = from
> any
> SIP element. The format will anticipate the need to search, merge, = and
> summarize the log records from diverse elements. The format = will
> anticipate
> the need to correlate messages from multiple elements related to = a
> given
> request (that may fork) or a given dialog. The format will take = SIP's
> extensibility into consideration, providing a way to represent = SIP
> message
> components that are defined in the future. The format will = anticipate
> being
> used both for off-line analysis and on-line real-time = processing
> applications. The working group will consider the need for = efficient
> creation of records and the need for efficient processing of = the
> records.
>
> The working group will identify the fields to appear in a log = record
> and
> provide one or more formats for encoding those fields. The = working
> group is
> not pre-constrained to producing either a bit-field oriented or
> text-oriented format, and may choose to provide both. If the = group
> chooses
> to specify both, it must be possible to mechanically translate = between
> the
> formats without loss of information.
>
> Specifying the mechanics of exchanging, transporting, and storing = SIP
> Common Log Format records is explicitly out of scope. Specifying = a
> real-time
> transfer mechanism for heuristic analysis is explicitly out of = scope.
>
> The group will generate:
>
> A problem statement enunciating the motivation, and use cases for a = SIP
> Common Log Format. This analysis will identify the required = minimal
> information that must appear in any record.
>
> A specification of the SIP Common Log Format record
>
> The group will consider providing one or more reference = implementations
> for
> decoding a CLF record.
>
> One more piece of logistics ...
>
> We'll need at least one, and preferably two, scribes and a = jabber
> scribe for
> our CLF session on Friday during lunch.
>
> We'll call for volunteers at the meeting if necessary - we can't = have
> the
> meeting without producing minutes - but it would be great if you = could
> consider volunteering NOW.
>
> We have about an hour to get through some pretty important = discussions,
> and
> every minute we DON'T spend gazing meaningfully at the attendees = (us)
> and
> looking down at computers trying not to make eye contact with = the
> chairs
> (you) is a minute that we can use more productively!
>
> Thanks,
>
> Spencer and Theo
>
> _______________________________________________
> 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

------_=_NextPart_001_01CA11CF.CCC54D26-- From rjsparks@nostrum.com Fri Jul 31 05:29:59 2009 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 D8FB23A6E20; Fri, 31 Jul 2009 05:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 T42-ne40P1cd; Fri, 31 Jul 2009 05:29:58 -0700 (PDT) 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 24CB23A6E30; Fri, 31 Jul 2009 05:28:42 -0700 (PDT) Received: from dhcp-26f2.meeting.ietf.org (dhcp-26f2.meeting.ietf.org [130.129.38.242]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6VCSf22067998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2009 07:28:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: sip-clf@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 14:28:40 +0200 References: X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 130.129.38.242 is authenticated by a trusted mechanism) Cc: dispatch mailing list Subject: Re: [dispatch] [sip-clf] Next revision for the proposed CLF charter 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, 31 Jul 2009 12:30:00 -0000 For those not in the ad-hoc - this was the text before the meeting we had today. We got a lot of good feedback (minutes should be in soon). Expect a revision of this in a few days (probably sometime week after next). RjS On Jul 31, 2009, at 12:07 PM, Robert Sparks wrote: > The SIP Common Log Format (CLF) working group is chartered to define > a standard logging format for systems processing SIP messages. > > Well-known web servers such as Apache and web proxies like Squid > support event logging using a common log format. The logs produced > using these de-facto standard formats are invaluable to system > administrators for trouble-shooting a server and tool writers to > craft tools that mine the log files to produce reports and trends > and to search for a certain message or messages, a transaction > or a related set of transactions. Furthermore, these log records > can also be used to train anomaly detection systems and feed events > into a security event management system. > > The Session Initiation Protocol does not have a common log > format. Diverse elements provide distinct log formats making > it complex to produce tools to analyze them. > > The CLF working group will produce a format suitable for logging > from any SIP element. The format will anticipate the need to > search, merge, and summarize the log records from diverse elements. > The format will anticipate the need to correlate messages from > multiple elements related to a given request (that may fork) or a > given dialog. The format will take SIP's extensibility into > consideration, providing a way to represent SIP message components > that are defined in the future. The format will anticipate being > used both for off-line analysis and on-line real-time processing > applications. The working group will consider the need for > efficient creation of records and the need for efficient processing > of the records. > > The working group will identify the fields to appear in a log > record and provide one or more formats for encoding those fields. > The working group is not pre-constrained to producing either a > bit-field oriented or text-oriented format, and may choose to > provide both. If the group chooses to specify both, it must be > possible to mechanically translate between the formats without loss > of information. > > Specifying the mechanics of exchanging, transporting, and storing > SIP Common Log Format records is explicitly out of scope. Specifying > a real-time transfer mechanism for heuristic analysis is explicitly > out of scope. > > The group will generate: > > - A problem statement enunciating the motivation, > and use cases for a SIP Common Log Format. This analysis > will identify the required minimal information that must > appear in any record. > > - A specification of the SIP Common Log Format record > > The group will consider providing one or more reference > implementations for decoding a CLF record. > > Goals and Milestones > =========================== > > Oct 09 - Problem statement, motivation, and use cases > WGLC > Nov 09 - Problem statement, motivation, and use cases > to IESG (Informational) > Jan 10 - SIP Common Log Format specification > WGLC > Feb 10 - SIP Common Log Format specification > to IESG (PS) > > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf From akoba@nttv6.net Fri Jul 31 21:21:05 2009 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 AFE7D3A689C; Fri, 31 Jul 2009 21:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 4Gcg9IUcLIzB; Fri, 31 Jul 2009 21:21:04 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 4C22B3A67AD; Fri, 31 Jul 2009 21:21:04 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:cd57:c336:1bdd:a5b]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n714L4D2073718; Sat, 1 Aug 2009 13:21:05 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 01 Aug 2009 13:15:39 +0900 From: Atsushi Kobayashi To: Robert Sparks In-Reply-To: References: Message-Id: <20090801130506.288A.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Sat, 01 Aug 2009 13:21:05 +0900 (JST) Cc: sip-clf@ietf.org, dispatch mailing list Subject: Re: [dispatch] [sip-clf] Next revision for the proposed CLF charter 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, 01 Aug 2009 04:21:05 -0000 Dear all, I have one question. Does this charter include the media description part, i.e. SDP? I understood this motivation, however regarding security and trouble shooting, we need to track signaling and media as well. If SIP-CLF outputs the media description, we can correlate SIP signaling and media traffic data. The media traffic data may be outputted by IPFIX or other protocols. Otherwise, is it future work? Regards, Atsushi On Fri, 31 Jul 2009 12:07:14 +0200 Robert Sparks wrote: > The SIP Common Log Format (CLF) working group is chartered to define > a standard logging format for systems processing SIP messages. > > Well-known web servers such as Apache and web proxies like Squid > support event logging using a common log format. The logs produced > using these de-facto standard formats are invaluable to system > administrators for trouble-shooting a server and tool writers to > craft tools that mine the log files to produce reports and trends > and to search for a certain message or messages, a transaction > or a related set of transactions. Furthermore, these log records > can also be used to train anomaly detection systems and feed events > into a security event management system. > > The Session Initiation Protocol does not have a common log > format. Diverse elements provide distinct log formats making > it complex to produce tools to analyze them. > > The CLF working group will produce a format suitable for logging > from any SIP element. The format will anticipate the need to > search, merge, and summarize the log records from diverse elements. > The format will anticipate the need to correlate messages from > multiple elements related to a given request (that may fork) or a > given dialog. The format will take SIP's extensibility into > consideration, providing a way to represent SIP message components > that are defined in the future. The format will anticipate being > used both for off-line analysis and on-line real-time processing > applications. The working group will consider the need for > efficient creation of records and the need for efficient processing > of the records. > > The working group will identify the fields to appear in a log > record and provide one or more formats for encoding those fields. > The working group is not pre-constrained to producing either a > bit-field oriented or text-oriented format, and may choose to > provide both. If the group chooses to specify both, it must be > possible to mechanically translate between the formats without loss > of information. > > Specifying the mechanics of exchanging, transporting, and storing > SIP Common Log Format records is explicitly out of scope. Specifying > a real-time transfer mechanism for heuristic analysis is explicitly > out of scope. > > The group will generate: > > - A problem statement enunciating the motivation, > and use cases for a SIP Common Log Format. This analysis > will identify the required minimal information that must > appear in any record. > > - A specification of the SIP Common Log Format record > > The group will consider providing one or more reference > implementations for decoding a CLF record. > > Goals and Milestones > =========================== > > Oct 09 - Problem statement, motivation, and use cases > WGLC > Nov 09 - Problem statement, motivation, and use cases > to IESG (Informational) > Jan 10 - SIP Common Log Format specification > WGLC > Feb 10 - SIP Common Log Format specification > to IESG (PS) > > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637