From laura.liess.dt@googlemail.com Thu Apr 1 08:10:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682C13A699E for ; Thu, 1 Apr 2010 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.731 X-Spam-Level: * X-Spam-Status: No, score=1.731 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_64=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 K-icPQMRWKeA for ; Thu, 1 Apr 2010 08:10:25 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id A6B733A6933 for ; Thu, 1 Apr 2010 08:10:22 -0700 (PDT) Received: by qyk33 with SMTP id 33so1232275qyk.28 for ; Thu, 01 Apr 2010 08:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=LAdYAsNCaEIq5QFaqkC595m5K/3XEAcbp1KTXn6PCco=; b=VtE+952sni3HENVqJoTJX9TNUrJ6cCrFiEjpiqUw3WvMG3Zr9WmTs7qjwxbQ7ErxPM jGp5+AqeqUJvYMdyCev2Rs1OQl8nZKon3WdkwSZp7TNFeB/GnHd+vJ8fQCZ+zktTmBIH B6kuggUPMGWdc1a3x9T0wFtAnaYy2nYo8U5g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=D/aswG3K4K+76iDLrmNNXZdNbq6MckXuLMYm+FlyBX4mwI4OeFB7GSyGDNHLgOTqOF LFb8RxYVQPIdzA6kObeVR7ytxed++p+6DfuyopC8M33xGxtNK2hUHMvI4H+wyAk4FBdf w1PSadbY31Bae96Z6lt8If2aEqy5VdgS9PFVQ= Received: by 10.229.250.197 with SMTP id mp5mr1334848qcb.16.1270134640990; Thu, 01 Apr 2010 08:10:40 -0700 (PDT) Received: from LauraLiess ([72.14.241.8]) by mx.google.com with ESMTPS id 4sm15090435qwe.32.2010.04.01.08.10.36 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 08:10:39 -0700 (PDT) From: Laura Liess To: "'Paul Kyzivat'" , "'Laura Liess'" References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> In-Reply-To: <4BAC15AB.8090308@cisco.com> Date: Thu, 1 Apr 2010 17:10:35 +0200 Message-ID: <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrMiGGvl/W80+j8QIyAkERCnQRkygFFKSgQ Content-Language: de Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 01 Apr 2010 15:10:27 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Freitag, 26. M=E4rz 2010 03:02 > An: Laura Liess > Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; 'Gerold Pinker'; Huelsemann, > Martin; R.Jesske@telekom.de > Betreff: Re: AW: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info- > urns-01.txt >=20 >=20 >=20 > Laura Liess wrote: > > Paul, > > > > Thank you for the proposal and the elaborate description. I = definitively > > like it. > > It seems to solve the combinations problem, it is extensible and = easy to > > understand. > > I have two comments on it, connected to "call-waiting". > > > > 1) It seems to me that there is some misunderstanding concerning the meaning > > of the "call-waiting" alert urn. It is not the callee's presence = state, but > > the state of the call itself. The "call-waiting" tone tells the = caller: > > "Your call is temporary queued (waiting) at the callee's side = because the > > callee is currently involved in another call. The callee was = informed that > > your call is waiting." Having this information, the caller can = decide to > > wait for a while or to cancel the call. This is an already existing > > PSTN-service which customers expect us to provide also when we = migrate to > > SIP. > > Because this urn tells the user that the service "call-waiting" was > > performed at the other side of the call, we name "service" was = choosed for > > this category. >=20 > I wasn't sure from the draft whether this was about the ringback to = the > caller (which is what you are describing), or whether it was about the > "ring" to the callee, which is of typically different in this case. >=20 > As I noted, I didn't think it made that much sense as an indication to > the callee, since the callee knows its status. So I think we are in > agreement about the important use - for ringback when the callee is > currently handling another call. >=20 > As I was writing things down I realized that this is really a = statement > about the state of the callee that happens to be known to the UAS and > hence reportable. I realize in the commonly used case this is a > "service" in the network, and hence is different from a feature of the > UAS - such as a multi-line phone.=20 This was the reason why we called this category "service". > But the two are functionally > equivalent to both the caller and the callee - the callee is occupied = on > some other call, and may (or may not) be delayed in answering. = (Whether > this delay is likely to be longer, or shorter, than would be the case = if > not on another call, is debatable. I guess just reporting it to the > caller as a datum does permit the caller to make his own judgement. >=20 > If this is reported as a distinct category, then it can be reported in > an orthogonal way. For instance maybe the ringback will be "normal" = but > there will be a display on the phone - perhaps akin to a "on hold" = light. >=20 > > 2) There are already implementations of = urn:alert:service:call-waiting. This > > syntax is used in the 3GPP Specification for the call-waiting = service (TS > > 24.615 "Communication Waiting (CW) using IP Multimedia (IM) Core = Network > > (CN) subsystem"). If we change this name, people either change their > > software, which means money and time for them, or they leave it as = it is, > > which means lack of interoperability e2e. The "reason"-category = contains in > > principles names for services, so I think it does not harm the = proposal if > > we just replace "reason" by "service" and keep the interoperability = with > > existing implementations. >=20 > How to name things is a second order issue. If its just a matter of > "service" vs. "reason" then I don't care very much. (I'm not = especially > attached to "reason", but I also find "service" somewhat confusing for > the purpose.) >=20 > The orthogonality is more important. The way I partitioned the data is > just a first cut, and I'm entirely open to alternative ways of doing > that. But I would hate to see the categorization warped just to fit = one > preexisting use. IMO it would make more sense to special-case that one = - > perhaps treat it as a separate category of its own. I agree. I went through the items we currently have in the category "service" (or "reason"). We have there "transfer-recall", = "auto-callback" and "hold-recall", which are sent in an INVITE and indicate to the = callee the "reason" for the incoming call. We could put them in the "reason" category. We also have "call-waiting" and "forward", which are sent in = an 180 Ringing and indicate to the caller that some network service was = applied to the call at the calee's side. We could put them in the "service" category.=20 Would this partitioning suit your vision ? Thanks a lot Laura=20 >=20 > Thanks, > Paul >=20 > > Thanks a lot > > Laura > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Gesendet: Donnerstag, 25. M=E4rz 2010 19:51 > > An: Laura Liess > > Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; = Gerold Pinker > > Betreff: Re: [dispatch] FW: I-D > > Action:draft-liess-dispatch-alert-info-urns-01.txt > > > > I've been thinking about how the "namespace" of alert-info URNs = might be > > reorganized. My goals in doing so are: > > - allow the different "aspects" of the alert to be specified > > - make it clear what the combination rules are for these > > - allow for comparable expressiveness for rings and ringbacks > > - provide room for extension > > > > The following is a rough outline of a what I have in mind: > > > > The urn syntax is as in the current draft, *except*: > > > > alert-category =3D "reason" / "priority" / "source" / > > "duration" / "delay" / "locale" / > > extension-category > > extension-category =3D token > > > > The principle for choosing these categories is that they are = orthogonal. > > Hence there is a single rule for well-formedness of Alert-Info: > > there can be at most one instance of each alert-category, and in > > principle any such combination is valid. (Though some may be silly = or > > uninteresting.) > > > > The above doesn't distinguish ring from ringback. That is to be > > determined from context - when present in a request it describes the > > ring. When present in a response it describes the ringback. Again, = in > > principle any combination can be used for either ring or ringback, > > though some combinations may be silly or uninteresting. > > > > The exact way in which the various categories are combined for = rendering > > is left as an implementation issue. The implementation is free to = ignore > > any or all at its whim. > > > > Its my intent that things previously discussed in the draft can all = be > > mapped onto these categories. Here is my swag at doing so: > > > > urn:alert:reason: > > > > - normal (default) > > - call-waiting > > - forward > > - auto-callback > > - recall.hold > > - recall.transfer > > - private. > > > > urn:alert:priority: > > > > - normal (default) > > - low > > - high > > - crisis > > - private. > > > > urn:alert:source: > > > > - unclassified (default) > > - internal > > - external > > - friend > > - family > > - private. > > > > urn:alert:duration: > > > > - normal (default) > > - short (or could be "zip") > > - long (for completeness, or omit if unneeded) > > - private. > > > > urn:alert:delay: > > > > - none (default) > > - yes (not sure what to put here) > > - private. > > > > urn:alert:locale: > > > > - default (default) > > - country. > > - private. > > > > In the above the "private." syntax is for extensions > > specific to independent organizations. The is in the = form > > of a "reverse FQDN" such as is used for Java package names. This = gives a > > way of assigning unique names without the need for a new registry. = The > > namespace for each alert category is independent. Those assigning = new > > names must ensure they are in a position to assign names uniquely = for > > the FQDN they choose. > > > > (I have considerable reservation about introducing such an = uncontrolled > > extension mechanism. I see how it can provide a lot of flexibility = in > > providing tailored user experiences. But it can also lead to vendor = lock > > in if a device is only capable of supporting a particular vendor's > > specific extensions. So I think this needs a lot of discussion.) > > > > For example, I might want to define: > > > > urn:alert:source:private.com.cisco.customer > > > > If I were to do so, I should first ensure that I speak for cisco.com > > when coining this. > > > > Additions to the values above other than via the "private" mechanism > > would be by standards action. The same for adding new categories. > > (There could be a "private" mechanism for categories too. But I'm = not at > > all confident that is a good thing.) > > > > I'm not quite sure about "call-waiting" as a "reason" - it doesn't = seem > > quite right. The reason could still be any of those other things. = For > > the ring indication its far from clear to me that it is needed at = all - > > the recipient already knows it is on a call, and doesn't need to be = told > > that. It may make more sense for the ringback - in that case you are > > being told something about the state of the other party. Perhaps = this > > should be replaced by something about the state of the party sending = the > > message. E.g. > > > > urn:alert:state: > > > > - unknown > > - waiting (in a request, means the caller is waiting > > for the call to complete. The normal case.) > > - on-a-call (in a response, means the called party > > is on another call - the call waiting case. > > But could apply to a caller as well.) > > - away (in a request, means the call has been generated > > automatically and the user will be summoned if/when > > the call completes. This is the converse of waiting) > > > > (This "state" is really a form of presence. Whether its good to = encode > > it here, rather than actually transmitting pidf, is an interesting > > question.) > > > > How all of this might be mapped onto actual renderings is probably = not > > something that should be standardized, but it might be worth = including > > some possibilities as examples. One that comes to mind is: > > > > (Assuming all rendering are audio): > > > > - the device has a set of possible clips it can render > > - each is attributed with the values it matches for each > > category above. (none, one, several, or all for each > > category.) > > > > The device just finds the maximal match and renders that one. > > > > This might be augmented if there are different sorts of renderings - > > e.g. audio, visual, tactile (vibrarion). In that case it might seek = out > > a match for each sort and render them all. > > > > Thanks, > > Paul > > > > From pkyzivat@cisco.com Thu Apr 1 11:40:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BC53A6A94 for ; Thu, 1 Apr 2010 11:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.109 X-Spam-Level: X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytHihrkeqE6i for ; Thu, 1 Apr 2010 11:40:46 -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 329E43A67D7 for ; Thu, 1 Apr 2010 11:40:45 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABOGtEtAZnwM/2dsb2JhbACbPnGdFpkLgksBgjUE X-IronPort-AV: E=Sophos;i="4.51,350,1267401600"; d="scan'208";a="98079955" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Apr 2010 18:41:17 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o31IfH9e028086; Thu, 1 Apr 2010 18:41:17 GMT Message-ID: <4BB4E8D0.4030407@cisco.com> Date: Thu, 01 Apr 2010 14:41:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> In-Reply-To: <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 01 Apr 2010 18:40:47 -0000 Laura Liess wrote: >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> How to name things is a second order issue. If its just a matter of >> "service" vs. "reason" then I don't care very much. (I'm not especially >> attached to "reason", but I also find "service" somewhat confusing for >> the purpose.) >> >> The orthogonality is more important. The way I partitioned the data is >> just a first cut, and I'm entirely open to alternative ways of doing >> that. But I would hate to see the categorization warped just to fit one >> preexisting use. IMO it would make more sense to special-case that one - >> perhaps treat it as a separate category of its own. > > I agree. I went through the items we currently have in the category > "service" (or "reason"). We have there "transfer-recall", "auto-callback" > and "hold-recall", which are sent in an INVITE and indicate to the callee > the "reason" for the incoming call. We could put them in the "reason" > category. We also have "call-waiting" and "forward", which are sent in an > 180 Ringing and indicate to the caller that some network service was applied > to the call at the calee's side. We could put them in the "service" > category. > > Would this partitioning suit your vision ? I had proposed just clumping those together into a single category (which I called reason): urn:alert:reason: - normal (default) (ring & ringback) - call-waiting ( ringback) - forward (ring & ringback) - auto-callback (ring & ringback) - recall.hold (ring & ringback) - recall.transfer (ring & ringback) - private. (ring & ringback) My logic above is: - whether this applies to ring or ringback depends on context (the message it is in) so doesn't have to be part of the naming. Making this part of the naming just introduces another sort of error to deal with. ("reason" can only be used in requests, while "service" can only be used in responses.) Is there a strong reason partition things that way? - for many (but perhaps not all) it might be useful in both directions, though the particular alert used would differ. For instance, its useful to inform both the holder and the holdee of a hold-recall. (Note that I also changed the naming to recall.hold and recall.transfer because the are both "recall" functions, and it might be convenient for some devices to alert them both the same. I'm still debating with myself whether auto-callback should be recall.auto.) Thanks, Paul > Thanks a lot > Laura > >> Thanks, >> Paul >> >>> Thanks a lot >>> Laura >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Gesendet: Donnerstag, 25. März 2010 19:51 >>> An: Laura Liess >>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerold > Pinker >>> Betreff: Re: [dispatch] FW: I-D >>> Action:draft-liess-dispatch-alert-info-urns-01.txt >>> >>> I've been thinking about how the "namespace" of alert-info URNs might be >>> reorganized. My goals in doing so are: >>> - allow the different "aspects" of the alert to be specified >>> - make it clear what the combination rules are for these >>> - allow for comparable expressiveness for rings and ringbacks >>> - provide room for extension >>> >>> The following is a rough outline of a what I have in mind: >>> >>> The urn syntax is as in the current draft, *except*: >>> >>> alert-category = "reason" / "priority" / "source" / >>> "duration" / "delay" / "locale" / >>> extension-category >>> extension-category = token >>> >>> The principle for choosing these categories is that they are orthogonal. >>> Hence there is a single rule for well-formedness of Alert-Info: >>> there can be at most one instance of each alert-category, and in >>> principle any such combination is valid. (Though some may be silly or >>> uninteresting.) >>> >>> The above doesn't distinguish ring from ringback. That is to be >>> determined from context - when present in a request it describes the >>> ring. When present in a response it describes the ringback. Again, in >>> principle any combination can be used for either ring or ringback, >>> though some combinations may be silly or uninteresting. >>> >>> The exact way in which the various categories are combined for rendering >>> is left as an implementation issue. The implementation is free to ignore >>> any or all at its whim. >>> >>> Its my intent that things previously discussed in the draft can all be >>> mapped onto these categories. Here is my swag at doing so: >>> >>> urn:alert:reason: >>> >>> - normal (default) >>> - call-waiting >>> - forward >>> - auto-callback >>> - recall.hold >>> - recall.transfer >>> - private. >>> >>> urn:alert:priority: >>> >>> - normal (default) >>> - low >>> - high >>> - crisis >>> - private. >>> >>> urn:alert:source: >>> >>> - unclassified (default) >>> - internal >>> - external >>> - friend >>> - family >>> - private. >>> >>> urn:alert:duration: >>> >>> - normal (default) >>> - short (or could be "zip") >>> - long (for completeness, or omit if unneeded) >>> - private. >>> >>> urn:alert:delay: >>> >>> - none (default) >>> - yes (not sure what to put here) >>> - private. >>> >>> urn:alert:locale: >>> >>> - default (default) >>> - country. >>> - private. >>> >>> In the above the "private." syntax is for extensions >>> specific to independent organizations. The is in the form >>> of a "reverse FQDN" such as is used for Java package names. This gives a >>> way of assigning unique names without the need for a new registry. The >>> namespace for each alert category is independent. Those assigning new >>> names must ensure they are in a position to assign names uniquely for >>> the FQDN they choose. >>> >>> (I have considerable reservation about introducing such an uncontrolled >>> extension mechanism. I see how it can provide a lot of flexibility in >>> providing tailored user experiences. But it can also lead to vendor lock >>> in if a device is only capable of supporting a particular vendor's >>> specific extensions. So I think this needs a lot of discussion.) >>> >>> For example, I might want to define: >>> >>> urn:alert:source:private.com.cisco.customer >>> >>> If I were to do so, I should first ensure that I speak for cisco.com >>> when coining this. >>> >>> Additions to the values above other than via the "private" mechanism >>> would be by standards action. The same for adding new categories. >>> (There could be a "private" mechanism for categories too. But I'm not at >>> all confident that is a good thing.) >>> >>> I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem >>> quite right. The reason could still be any of those other things. For >>> the ring indication its far from clear to me that it is needed at all - >>> the recipient already knows it is on a call, and doesn't need to be told >>> that. It may make more sense for the ringback - in that case you are >>> being told something about the state of the other party. Perhaps this >>> should be replaced by something about the state of the party sending the >>> message. E.g. >>> >>> urn:alert:state: >>> >>> - unknown >>> - waiting (in a request, means the caller is waiting >>> for the call to complete. The normal case.) >>> - on-a-call (in a response, means the called party >>> is on another call - the call waiting case. >>> But could apply to a caller as well.) >>> - away (in a request, means the call has been generated >>> automatically and the user will be summoned if/when >>> the call completes. This is the converse of waiting) >>> >>> (This "state" is really a form of presence. Whether its good to encode >>> it here, rather than actually transmitting pidf, is an interesting >>> question.) >>> >>> How all of this might be mapped onto actual renderings is probably not >>> something that should be standardized, but it might be worth including >>> some possibilities as examples. One that comes to mind is: >>> >>> (Assuming all rendering are audio): >>> >>> - the device has a set of possible clips it can render >>> - each is attributed with the values it matches for each >>> category above. (none, one, several, or all for each >>> category.) >>> >>> The device just finds the maximal match and renders that one. >>> >>> This might be augmented if there are different sorts of renderings - >>> e.g. audio, visual, tactile (vibrarion). In that case it might seek out >>> a match for each sort and render them all. >>> >>> Thanks, >>> Paul >>> >>> > > From volker.hilt@alcatel-lucent.com Thu Apr 1 17:55:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8523A6812; Thu, 1 Apr 2010 17:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JCdq4FgjaHA; Thu, 1 Apr 2010 17:55:41 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A6DA43A6809; Thu, 1 Apr 2010 17:55:38 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o320u8Kt018913; Thu, 1 Apr 2010 19:56:08 -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 o320u7Ws003268; Thu, 1 Apr 2010 19:56:08 -0500 (CDT) Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 1 Apr 2010 19:56:07 -0500 Message-ID: <4BB5409E.5080108@alcatel-lucent.com> Date: Thu, 1 Apr 2010 20:55:58 -0400 From: Volker Hilt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: DISPATCH , "sip-overload@ietf.org" References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> In-Reply-To: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.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.35 Cc: Lars Eggert Subject: [dispatch] Proposed SIP Overload Control 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, 02 Apr 2010 00:55:42 -0000 All, below is an updated charter proposal for a SIP Overload Control WG. It has additional text that specifications developed by the proposed WG need to define scope and limitations (see below). Thanks, Volker SIP Overload Control WG Charter ------------------------------- As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate 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 fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control can be split into i) overload control between a user agent and a SIP server and overload control between SIP servers. A specification developed by the proposed working group needs to clearly specify its scope. A specification also needs to clearly state any limitations in performance or otherwise the proposed overload control mechanism may have. 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 jgunn6@csc.com Fri Apr 2 08:11:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13343A6936; Fri, 2 Apr 2010 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 gDJPoqW2OnpE; Fri, 2 Apr 2010 08:11:14 -0700 (PDT) Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with ESMTP id 895F33A6907; Fri, 2 Apr 2010 08:11:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-145.messagelabs.com!1270221104!10026971!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 22229 invoked from network); 2 Apr 2010 15:11:45 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-7.tower-145.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Apr 2010 15:11:45 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id o32FBiBm017623; Fri, 2 Apr 2010 11:11:44 -0400 In-Reply-To: <4BB5409E.5080108@alcatel-lucent.com> References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> To: Volker Hilt MIME-Version: 1.0 X-KeepSent: 15B89DE4:C12B307F-852576F9:0052B459; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 2 Apr 2010 11:11:35 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/02/2010 11:12:38 AM, Serialize complete at 04/02/2010 11:12:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0053752B852576F9_=" Cc: sip-overload-bounces@ietf.org, DISPATCH , "sip-overload@ietf.org" , Lars Eggert Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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, 02 Apr 2010 15:11:15 -0000 This is a multipart message in MIME format. --=_alternative 0053752B852576F9_= Content-Type: text/plain; charset="US-ASCII" > > [sip-overload] Proposed SIP Overload Control Charter > > Volker Hilt > This text > 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. seems to imply that there are ONLY TWO complementary approaches. There are, in fact, a much larger number of possible approaches. Filters based on the SOURCE domain, telephone number prefix or for a specific user are the most obvious omission, but I am sure there are many more. Perhaps better wording would be "At least two complementary approaches exist for handling overload situations:..." Janet > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 0053752B852576F9_= Content-Type: text/html; charset="US-ASCII"


>
> [sip-overload] Proposed SIP Overload Control Charter
>
> Volker Hilt
>

This text

> 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.

seems to imply that there are ONLY TWO complementary approaches.  

There are, in fact, a much larger number of possible approaches.

Filters based on the SOURCE domain, telephone number prefix or for a specific user are the most obvious omission, but I am sure there are many more.

Perhaps better wording would be

"At least two complementary approaches exist for handling overload situations:..."

Janet





> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 0053752B852576F9_=-- From charles.newyork@gmail.com Fri Apr 2 08:28:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAB03A6821; Fri, 2 Apr 2010 08:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 y3s4xkV6N2jt; Fri, 2 Apr 2010 08:28:05 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 5396D3A67DA; Fri, 2 Apr 2010 08:28:05 -0700 (PDT) Received: by pvd12 with SMTP id 12so579214pvd.31 for ; Fri, 02 Apr 2010 08:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=8pJoQxJXjsm85q3NhcBUw13zpIc5PIsF8KEgC6WChTM=; b=mtMA+EdqPRKUZ7TVcDuKLOjQjqqu+AZGT5yk4cc3zUsDThfwuFbp4sVE9YjDueeBO5 aM8q5F9vVj27c8fgOAGv/zb0UIKeAyzTy6KeJnuZfUZz6JWxdEWCJ8aB6jwpzKKx+9LN uHEXe5Oe1vqUSIHqzGEd3Vjvy/GzHeXxfESVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ty92i7z8RRy/ra9yAeTBzRc+0mtT1etmlYBRTVXzZ9y5y1Fr3V8/+5LQ6e/mHLfd9l i13VHH7WZheltZqp/Jc5iH2nXPimghP+QNKUueSonz7nWX/AUGBjTnYzat4jPPTwC/tD K74LIAopuTb3f7D8vh6W8CjAAyVi9V/KYAtcY= MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.142.174.20 with HTTP; Fri, 2 Apr 2010 08:28:36 -0700 (PDT) In-Reply-To: References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> Date: Fri, 2 Apr 2010 11:28:36 -0400 X-Google-Sender-Auth: 61474804afd52de3 Received: by 10.143.153.24 with SMTP id f24mr815821wfo.292.1270222116535; Fri, 02 Apr 2010 08:28:36 -0700 (PDT) Message-ID: From: Charles Shen To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 03 Apr 2010 14:46:02 -0700 Cc: sip-overload-bounces@ietf.org, DISPATCH , "sip-overload@ietf.org" , Lars Eggert , Volker Hilt Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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, 02 Apr 2010 15:28:06 -0000 On Fri, Apr 2, 2010 at 11:11 AM, Janet P Gunn wrote: > > > >> >> [sip-overload] Proposed SIP Overload Control Charter >> >> Volker Hilt >> > > This text > >> 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. > > seems to imply that there are ONLY TWO complementary approaches. > > There are, in fact, a much larger number of possible approaches. > > Filters based on the SOURCE domain, telephone number prefix or for a > specific user are the most obvious omission, "Filters based on the SOURCE domain, telephone number prefix or for a specific user" are still part of (and included in) the filter-based approach. Maybe what we are talking about is either a single user or a group of users specified by URIs (e.g., SIP, Tel), and the grouping can be based on domains or telephone number prefixes? Thanks Charles > but I am sure there are many > more. > > Perhaps better wording would be > > "At least two complementary approaches exist for handling overload > situations:..." > > Janet > > > > > >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > From pkyzivat@cisco.com Mon Apr 5 13:32:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3421E3A6965 for ; Mon, 5 Apr 2010 13:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.897 X-Spam-Level: X-Spam-Status: No, score=-8.897 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtsim7xkQi8C for ; Mon, 5 Apr 2010 13:32:26 -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 1C4E528C19F for ; Mon, 5 Apr 2010 13:29:31 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,367,1267401600"; d="scan'208";a="99091508" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2010 20:29:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35KTRxx023235; Mon, 5 Apr 2010 20:29:27 GMT Message-ID: <4BBA481E.7050608@cisco.com> Date: Mon, 05 Apr 2010 16:29:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mary Barnes , Cullen Jennings References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com> <4B72BE4A.6030508@ericsson.com> In-Reply-To: <4B72BE4A.6030508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: [dispatch] Expert review of draft-avasarala-dispatch-comm-div-notification-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, 05 Apr 2010 20:32:28 -0000 I was asked to be expert reviewer for this document. I earlier reviewed version -03, and this is an updated review of -04. Some of the issues I raised previously have been resolved, but not all. RFC 5727 calls for me to judge it just like a standards track document, and doing so leads to most of the remaining issues. I don't think I have raised any fundamentally new issues since the previous pass, though I have tried to restate the remaining ones in context of the new document and the intermediate discussions we have had. I continue to think this is mostly a matter of getting the text right, rather than altering the fundamental aspects of the proposed package. Mostly this is a matter of insufficient text, leaving many ambiguities. Thanks, Paul ========================================================================== I was requested to do an expert review of draft-avasarala-dispatch-comm-div-notification-04.txt > 1. A Designated Expert (as defined in RFC5226) must review the > proposal for applicability to SIP and conformance with these > guidelines. The Designated Expert will send email to the IESG on > this determination. The expert reviewer can cite one or more of > the guidelines that have not been followed in his/her opinion. I'm doing that below. > 2. The proposed extension MUST NOT define an event template-package. It does not. > 3. The function of the proposed package MUST NOT overlap with > current or planned chartered packages. I am aware of no chartered work on this subject. The draft itself has been debated at length on the dispatch wg mailing list, but with a relatively small number of people actively involved. Some, including me, have stated that a service resembling the one proposed might be of general utility. But there have been no volunteers to do the work of generalizing this. So I conclude that there are currently no plans for chartered work on such a package. > 4. The event package MUST NOT redefine or contradict the normative > behavior of SIP events [RFC3265], SIP [RFC3261], or related > standards track extensions. (See Section 4) I did not identify any issues in this regard. > 5. The proposed package MUST NOT undermine SIP security in any > sense. The Internet Draft proposing the new package MUST address > security issues in detail as if it were a Standards Track > document. Security issues need to be discussed for arbitrary > usage scenarios (including the general Internet case). The document identifies the specific security issues presented by this package. It specifies that authentication and authorization must be done, but leaves the means for authorization out of scope. While a bit thin, this may be sufficient for the area of applicability. > 6. The proposed package MUST be clearly documented in an > (Individual) Informational RFC, and registered with IANA. The document under review will satisfy this requirement. > The package MUST document all the package considerations required > in Section 4 of SIP events [RFC3265]. I will comment on the individual parts of section 4 below: > 4.1. Appropriateness of Usage In my opinion this is an entirely appropriate use of sip and event packages. > 4.2. Event Template-packages N/A - template package not defined. > 4.3. Amount of State to be Conveyed > 4.3.1. Complete State Information > 4.3.2. State Deltas This version of the document is improved - it now discusses the retention of state about some number of past diversions. But it does not discuss *what* state information is captured from a diversion. This is *implied* by the specification of the xml document that conveys this information in NOTIFY requests. This is tenuous. There should be an explicit specification of the state maintained, and how it is mapped onto the notification body. There is no normative requirement to include this information in the document, so I can't insist on it. But without this, it will be difficult to adequately address Notifier generation of NOTIFY requests. > 4.4. Event Package Responsibilities > 4.4.1. Event Package Name OK. > 4.4.2. Event Package Parameters OK. > 4.4.3. SUBSCRIBE Bodies ISSUE: The schema for the body type allows parts of types and . It appears that only should appear in a SUBSCRIBE request, but this is not specified. There should either be text specifying that this part must not be present, or else text explaining what is to happen if it is present. > 4.4.4. Subscription Duration > > It is RECOMMENDED that event packages give a suggested range of times > considered reasonable for the duration of a subscription. Such > packages MUST also define a default "Expires" value to be used if > none is specified. OK. > 4.4.5. NOTIFY Bodies ISSUE: The schema for the body type allows parts of types and . It appears that only should appear in a NOTIFY request, but this is not specified. There should either be text specifying that this part must not be present, or else text explaining its significance in a NOTIFY. > 4.4.6. Notifier processing of SUBSCRIBE requests ISSUE: There is no text stating that the notifier must retain the information from the body of the subscribe for use in generation of NOTIFY requests. Since that is certainly required, it should be stated. ISSUE: There is no specification of what to do if the subscribe body contains . If that's valid, then the behavior should be specified. If its not valid, that should have been specified in 4.4.3. > 4.4.7. Notifier generation of NOTIFY requests > > This section of an event package describes the process by which the > notifier generates and sends a NOTIFY request. This includes > detailed information about what events cause a NOTIFY to be sent, ISSUE: the triggers for sending NOTIFY are imprecisely specified. This is *partially* covered, in that it it states that a NOTIFY will "typically" be sent when "a communication diversion is enacted on behalf of the user", but the atypical situation is not discussed. There is also "A notifier MAY send a NOTIFY at any time", which appears to be inappropriate - apparently the only other time to send such a notification is immediately following a SUBSCRIBE request. ISSUE: There is no discussion of how the body from the SUBSCRIBE request affects the decision about when to send NOTIFY requests. This is too under-specified to be considered complete. What I would expect to see here is, roughly: - when a new (or refresh) SUBSCRIBE is received, compute the state information in the notify (see below), and send regardless of whether it is empty or not. - when a communication diversion occurs, selected attributes (TBS) of the diverted message and the diversion itself are captured and saved as new diversion state. - the addition of this new state may (or may not) result in discarding some old state. (Details TBS, related to the value N.) - for each subscriber, compute the state information in the notify (see below). If the resulting body is non-empty, send the NOTIFY. If empty, do not send the notify. > how to compute the state information in the NOTIFY, ISSUE: I don't find this information anywhere. While an implementor may attempt to infer it from the descriptions of the subscribe and notify bodies, that doesn't constitute a specification. ISSUE: The subscribe body is intended to be used as a filter on which events/state are reported. The subscribe body contains data to be used in the filtering process, but the decision process for filtering is not specified. For instance, both a User-name and a User-URI may be provided. It is implied, rather than stated, that the User-name field is matched against the user portion of some URI, whereas the User-URI field is matched against a complete URI. Also, there are a variety of field types, and no indication how matches of multiple fields are combined. (I.e. AND or OR.) I would expect to see a description of how the content of the subscribe body is applied to the saved diversion state to format a notify body. Also, how to construct the notify body if there is no subscribe body. Also, the representation of an "empty" body when there is no saved diversion state or the subscribe body results in all of the saved information being withheld from the subscriber. > how to generate > neutral or fake state information to hide authorization delays and > decisions from users, and whether state information is complete or > deltas for notifications; see section 4.3. Such a section is > required. ISSUE: This is not discussed. AFAICT, there is no need for fake information - this can simply be stated. Neutral information is presumably what is sent in a NOTIFY when there is no saved diversion state, or all saved state is filtered out by the subscribe body. Apparently the intent in that case is for a NOTIFY with no body. That should be made clear. > 4.4.8. Subscriber processing of NOTIFY requests This section is very thin - it specifies nothing. But if you want to leave this undefined I won't object, because there appear to be no normative requirements. > 4.4.9. Handling of forked requests OK, not permitted. > 4.4.10. Rate of notifications OK - specified. > 4.4.11. State Agents Its my understanding that this event package is not intended to employ state agents (as that term is defined in RFC 3265). Hence this section should simply state that state agents are not used. > 4.4.12. Examples The only provided example is a sample of a notification body. Flow diagrams and message detail, as called out in 3265, would be very useful. Specifically, this document would be improved if it included examples of at least: - initial subscribe when there have been no diversions - the occurrence of a diversion and the resulting notification to existing subscribers. - another subscription by another subscriber while there is retained state from a prior diversion, and the resulting notification(s). - another diversion occurrence, its impact on saved state, and on what the existing subscribers receive as notifications. - a subscription with a filter that screens out some but not all of the diversions in the saved state. Having such examples might have shortened the discussion of this draft significantly. But this is not mandatory according to 3265, so I cannot require that you provide it. NIT: Section 8.2 is entitled "Sample Notification Body", but it contains subsections entitled "Instance of communication diversion subscription document" and "Instance of communication diversion notification document". While the latter would be a notification body, the former would presumably be a subscription body. I suggest you rename the section to be more clear. > 4.4.13. Use of URIs to Retrieve State OK - not used. > 7. If determined by the Designated Expert or the chairs or ADs of > the DISPATCH WG, an applicability statement in the Informational > RFC MUST clearly document the useful scope of the proposal, and > explain its limitations and why it is not suitable for the > general use of SIP in the Internet. The Applicability Statement in the document adequately documents the scope. From laura.liess.dt@googlemail.com Tue Apr 6 06:32:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1263A695B for ; Tue, 6 Apr 2010 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=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 ebDMlE-XwMir for ; Tue, 6 Apr 2010 06:31:58 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 06FC13A6959 for ; Tue, 6 Apr 2010 06:31:57 -0700 (PDT) Received: by pwj2 with SMTP id 2so2440751pwj.31 for ; Tue, 06 Apr 2010 06:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YB+Svg1FZbqD5/cWo78NB9OoeNIhd82i6pJPOeRXaHU=; b=cSf0IZPJvelWpGAUwMjimN44D1NtHt0dCipt2V0xYsxoXP4U4gm1c8A9WhIetWqvL7 mOOK2S/C1xYCRGVIPTJeS1SnfyR9+mYDURqJz1yeIl6kgNyhwuf3jBLu7HZ/fIBR5nvu K/g3q6rJTWiqAowF89GCDpKj8ZAIm40uMa/Bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Pk6MUC5GzR1hUyvsxpuijglVNIspgg3oaCqRMi+QtWy9rwgIPtgGEowht0mmXWq2aE dmXLJipz35JdlAA6j4SJAB2KJuSlQNC8/d4izV9+wZyDOtfpfbO4sKDeC1xJrYg0Tsun ScWxnEIYWgPcUpgyOEi+fF54BkNx+g0xgpIyg= MIME-Version: 1.0 Received: by 10.142.82.21 with HTTP; Tue, 6 Apr 2010 06:31:52 -0700 (PDT) In-Reply-To: <4BB4E8D0.4030407@cisco.com> References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> <4BB4E8D0.4030407@cisco.com> Date: Tue, 6 Apr 2010 15:31:52 +0200 Received: by 10.143.132.1 with SMTP id j1mr2619787wfn.142.1270560712857; Tue, 06 Apr 2010 06:31:52 -0700 (PDT) Message-ID: From: Laura Liess To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 06 Apr 2010 13:32:00 -0000 Paul, > I had proposed just clumping those together into a single category (which= I > called reason): > > urn:alert:reason: > > - normal (default) (ring & ringback) > - call-waiting ( ringback) > - forward (ring & ringback) > - auto-callback (ring & ringback) > - recall.hold (ring & ringback) > - recall.transfer (ring & ringback) > - private. (ring & ringback) > > My logic above is: > > - whether this applies to ring or ringback depends on context > (the message it is in) so doesn't have to be part of the naming. > Making this part of the naming just introduces another sort of > error to deal with. ("reason" can only be used in requests, while > "service" can only be used in responses.) > Is there a strong reason partition things that way? I think the proposal to separate urns for ring and ringback came up some months before, either on the mailing list or in some discussion at the IETF, in connection with the urn combinations problem. I am fine with your proposal. In principle, also the call-waiting indication can be sent to caller and callee. We probably have to include a statement in the draft that the receiving UA should make the decision about what to render to the user depending on oth the value of the Alert-Info URN and the kind of message it received (INVITE or 18x-response). The only problem I have here is the naming. Personally, I would prefer to name the whole category you described above as "service", for folowing reasons: - "reason" is somehow to broad. In principle, it easily may happen that people add to this category also other "reason"-indications which have nothing to do with services and are orthogonal to the indications we have now in this category. But as a combination rule, we would like to have no more than one urn from same category. The name "service" would be more restrictive. - All items of this category indicate that some service was initiated. - Implementors, testers, operating guys are more familiar with call-waiting, forward or transfer as being a service than being a reason. But if this name is not at acceptable for you, I would like at least to come back to your proposal in your mail from April 1 and treat "call-waiting" as a separate "service" category. > > - for many (but perhaps not all) it might be useful in both > directions, though the particular alert used would differ. > > For instance, its useful to inform both the holder and the holdee of a > hold-recall. > > (Note that I also changed the naming to recall.hold and recall.transfer > because the are both "recall" functions, and it might be convenient for s= ome > devices to alert them both the same. I'm still debating with myself wheth= er > auto-callback should be recall.auto.) This makes sense to me. (I just used the old names in my mail.) Only I would choose recall.callback instead of recall.auto. I think it is more intuitive. Thanks a lot Laura 2010/4/1 Paul Kyzivat : > > > Laura Liess wrote: >>> >>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> How to name things is a second order issue. If its just a matter of >>> "service" vs. "reason" then I don't care very much. (I'm not especially >>> attached to "reason", but I also find "service" somewhat confusing for >>> the purpose.) >>> >>> The orthogonality is more important. The way I partitioned the data is >>> just a first cut, and I'm entirely open to alternative ways of doing >>> that. But I would hate to see the categorization warped just to fit one >>> preexisting use. IMO it would make more sense to special-case that one = - >>> perhaps treat it as a separate category of its own. >> >> I agree. I went through the items we currently have in the category >> "service" (or "reason"). We have there "transfer-recall", "auto-callback= " >> and "hold-recall", which are sent in an INVITE and indicate to the calle= e >> the "reason" for the incoming call. We could put them in the "reason" >> category. We also have "call-waiting" and "forward", which are sent in a= n >> 180 Ringing and indicate to the caller that some network service was >> applied >> to the call at the calee's side. We could put them in the "service" >> category. >> Would this partitioning suit your vision ? > > I had proposed just clumping those together into a single category (which= I > called reason): > > urn:alert:reason: > > - normal (default) =A0 =A0 =A0 =A0(ring & ringback) > - call-waiting =A0 =A0 =A0 =A0 =A0 =A0( =A0 =A0 =A0 ringback) > - forward =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ring & ringback) > - auto-callback =A0 =A0 =A0 =A0 =A0 (ring & ringback) > - recall.hold =A0 =A0 =A0 =A0 =A0 =A0 (ring & ringback) > - recall.transfer =A0 =A0 =A0 =A0 (ring & ringback) > - private. =A0(ring & ringback) > > My logic above is: > > - whether this applies to ring or ringback depends on context > =A0(the message it is in) so doesn't have to be part of the naming. > =A0Making this part of the naming just introduces another sort of > =A0error to deal with. ("reason" can only be used in requests, while > =A0"service" can only be used in responses.) > =A0Is there a strong reason partition things that way? > > - for many (but perhaps not all) it might be useful in both > =A0directions, though the particular alert used would differ. > > For instance, its useful to inform both the holder and the holdee of a > hold-recall. > > (Note that I also changed the naming to recall.hold and recall.transfer > because the are both "recall" functions, and it might be convenient for s= ome > devices to alert them both the same. I'm still debating with myself wheth= er > auto-callback should be recall.auto.) > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Thanks a lot >> Laura >>> >>> =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0Paul >>> >>>> Thanks a lot >>>> Laura >>>> >>>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Gesendet: Donnerstag, 25. M=E4rz 2010 19:51 >>>> An: Laura Liess >>>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerold >> >> Pinker >>>> >>>> Betreff: Re: [dispatch] FW: I-D >>>> Action:draft-liess-dispatch-alert-info-urns-01.txt >>>> >>>> I've been thinking about how the "namespace" of alert-info URNs might = be >>>> reorganized. My goals in doing so are: >>>> - allow the different "aspects" of the alert to be specified >>>> - make it clear what the combination rules are for these >>>> - allow for comparable expressiveness for rings and ringbacks >>>> - provide room for extension >>>> >>>> The following is a rough outline of a what I have in mind: >>>> >>>> The urn syntax is as in the current draft, *except*: >>>> >>>> alert-category =A0=3D "reason" / "priority" / "source" / >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "duration" / "delay" / "locale" / >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extension-category >>>> extension-category =3D token >>>> >>>> The principle for choosing these categories is that they are orthogona= l. >>>> Hence there is a single rule for well-formedness of Alert-Info: >>>> there can be at most one instance of each alert-category, and in >>>> principle any such combination is valid. (Though some may be silly or >>>> uninteresting.) >>>> >>>> The above doesn't distinguish ring from ringback. That is to be >>>> determined from context - when present in a request it describes the >>>> ring. When present in a response it describes the ringback. Again, in >>>> principle any combination can be used for either ring or ringback, >>>> though some combinations may be silly or uninteresting. >>>> >>>> The exact way in which the various categories are combined for renderi= ng >>>> is left as an implementation issue. The implementation is free to igno= re >>>> any or all at its whim. >>>> >>>> Its my intent that things previously discussed in the draft can all be >>>> mapped onto these categories. Here is my swag at doing so: >>>> >>>> urn:alert:reason: >>>> >>>> - normal (default) >>>> - call-waiting >>>> - forward >>>> - auto-callback >>>> - recall.hold >>>> - recall.transfer >>>> - private. >>>> >>>> urn:alert:priority: >>>> >>>> - normal (default) >>>> - low >>>> - high >>>> - crisis >>>> - private. >>>> >>>> urn:alert:source: >>>> >>>> - unclassified (default) >>>> - internal >>>> - external >>>> - friend >>>> - family >>>> - private. >>>> >>>> urn:alert:duration: >>>> >>>> - normal (default) >>>> - short (or could be "zip") >>>> - long (for completeness, or omit if unneeded) >>>> - private. >>>> >>>> urn:alert:delay: >>>> >>>> - none (default) >>>> - yes (not sure what to put here) >>>> - private. >>>> >>>> urn:alert:locale: >>>> >>>> - default (default) >>>> - country. >>>> - private. >>>> >>>> In the above the "private." syntax is for extensions >>>> specific to independent organizations. The is in the fo= rm >>>> of a "reverse FQDN" such as is used for Java package names. This gives= a >>>> way of assigning unique names without the need for a new registry. The >>>> namespace for each alert category is independent. Those assigning new >>>> names must ensure they are in a position to assign names uniquely for >>>> the FQDN they choose. >>>> >>>> (I have considerable reservation about introducing such an uncontrolle= d >>>> extension mechanism. I see how it can provide a lot of flexibility in >>>> providing tailored user experiences. But it can also lead to vendor lo= ck >>>> in if a device is only capable of supporting a particular vendor's >>>> specific extensions. So I think this needs a lot of discussion.) >>>> >>>> For example, I might want to define: >>>> >>>> urn:alert:source:private.com.cisco.customer >>>> >>>> If I were to do so, I should first ensure that I speak for cisco.com >>>> when coining this. >>>> >>>> Additions to the values above other than via the "private" mechanism >>>> would be by standards action. The same for adding new categories. >>>> (There could be a "private" mechanism for categories too. But I'm not = at >>>> all confident that is a good thing.) >>>> >>>> I'm not quite sure about "call-waiting" as a "reason" - it doesn't see= m >>>> quite right. The reason could still be any of those other things. For >>>> the ring indication its far from clear to me that it is needed at all = - >>>> the recipient already knows it is on a call, and doesn't need to be to= ld >>>> that. It may make more sense for the ringback - in that case you are >>>> being told something about the state of the other party. Perhaps this >>>> should be replaced by something about the state of the party sending t= he >>>> message. E.g. >>>> >>>> urn:alert:state: >>>> >>>> - unknown >>>> - waiting (in a request, means the caller is waiting >>>> =A0 =A0 =A0 =A0 =A0 =A0for the call to complete. The normal case.) >>>> - on-a-call (in a response, means the called party >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0is on another call - the call waiting case. >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0But could apply to a caller as well.) >>>> - away (in a request, means the call has been generated >>>> =A0 =A0 =A0 =A0 automatically and the user will be summoned if/when >>>> =A0 =A0 =A0 =A0 the call completes. This is the converse of waiting) >>>> >>>> (This "state" is really a form of presence. Whether its good to encode >>>> it here, rather than actually transmitting pidf, is an interesting >>>> question.) >>>> >>>> How all of this might be mapped onto actual renderings is probably not >>>> something that should be standardized, but it might be worth including >>>> some possibilities as examples. One that comes to mind is: >>>> >>>> (Assuming all rendering are audio): >>>> >>>> - the device has a set of possible clips it can render >>>> - each is attributed with the values it matches for each >>>> =A0 category above. (none, one, several, or all for each >>>> =A0 category.) >>>> >>>> The device just finds the maximal match and renders that one. >>>> >>>> This might be augmented if there are different sorts of renderings - >>>> e.g. audio, visual, tactile (vibrarion). In that case it might seek ou= t >>>> a match for each sort and render them all. >>>> >>>> =A0 =A0 =A0 =A0Thanks, >>>> =A0 =A0 =A0 =A0Paul >>>> >>>> >> >> > From pkyzivat@cisco.com Tue Apr 6 07:13:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FC93A685D for ; Tue, 6 Apr 2010 07:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_50=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jGhcuHAdvT8 for ; Tue, 6 Apr 2010 07:13:16 -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 9F8423A67F4 for ; Tue, 6 Apr 2010 07:13:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIbeuktAZnwM/2dsb2JhbACbSnGhMJh4gk4BDYItBA X-IronPort-AV: E=Sophos;i="4.51,372,1267401600"; d="scan'208";a="99301876" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2010 14:13:05 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o36ED5gH020696; Tue, 6 Apr 2010 14:13:05 GMT Message-ID: <4BBB4171.2010801@cisco.com> Date: Tue, 06 Apr 2010 10:13:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> <4BB4E8D0.4030407@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 06 Apr 2010 14:13:23 -0000 Laura - responses inline. Laura Liess wrote: > Paul, > > >> I had proposed just clumping those together into a single category (which I >> called reason): >> >> urn:alert:reason: >> >> - normal (default) (ring & ringback) >> - call-waiting ( ringback) >> - forward (ring & ringback) >> - auto-callback (ring & ringback) >> - recall.hold (ring & ringback) >> - recall.transfer (ring & ringback) >> - private. (ring & ringback) >> >> My logic above is: >> >> - whether this applies to ring or ringback depends on context >> (the message it is in) so doesn't have to be part of the naming. >> Making this part of the naming just introduces another sort of >> error to deal with. ("reason" can only be used in requests, while >> "service" can only be used in responses.) >> Is there a strong reason partition things that way? > > I think the proposal to separate urns for ring and ringback came up > some months before, either on the mailing list or in some discussion > at the IETF, in connection with the urn combinations problem. I am > fine with your proposal. In principle, also the call-waiting > indication can be sent to caller and callee. We probably have to > include a statement in the draft that the receiving UA should make the > decision about what to render to the user depending on oth the value > of the Alert-Info URN and the kind of message it received (INVITE or > 18x-response). Yes, that makes sense. Also, *what* is rendered, and what device it is rendered on, will typically vary depending on this distinction. (The headset vs. the ringer or speaker.) That should all be mentioned. > The only problem I have here is the naming. Personally, I would prefer > to name the whole category you described above as "service", for > folowing reasons: > - "reason" is somehow to broad. In principle, it easily may happen > that people add to this category also other "reason"-indications which > have nothing to do with services and are orthogonal to the indications > we have now in this category. But as a combination rule, we would like > to have no more than one urn from same category. The name "service" > would be more restrictive. > - All items of this category indicate that some service was initiated. > - Implementors, testers, operating guys are more familiar with > call-waiting, forward or transfer as being a service than being a > reason. I am not very attached to the name "reason". While I'm not fond of the name "service", I don't strongly object to it either, and if that is an important choice for you I can accept it. > But if this name is not at acceptable for you, I would like at least > to come back to your proposal in your mail from April 1 and treat > "call-waiting" as a separate "service" category. I can especially accept "service" if it means all these things are in the same category. >> - for many (but perhaps not all) it might be useful in both >> directions, though the particular alert used would differ. >> >> For instance, its useful to inform both the holder and the holdee of a >> hold-recall. >> >> (Note that I also changed the naming to recall.hold and recall.transfer >> because the are both "recall" functions, and it might be convenient for some >> devices to alert them both the same. I'm still debating with myself whether >> auto-callback should be recall.auto.) > > This makes sense to me. (I just used the old names in my mail.) Only > I would choose recall.callback instead of recall.auto. I think it is > more intuitive. Sounds good to me. Thanks, Paul > Thanks a lot > Laura > > > 2010/4/1 Paul Kyzivat : >> >> Laura Liess wrote: >>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> How to name things is a second order issue. If its just a matter of >>>> "service" vs. "reason" then I don't care very much. (I'm not especially >>>> attached to "reason", but I also find "service" somewhat confusing for >>>> the purpose.) >>>> >>>> The orthogonality is more important. The way I partitioned the data is >>>> just a first cut, and I'm entirely open to alternative ways of doing >>>> that. But I would hate to see the categorization warped just to fit one >>>> preexisting use. IMO it would make more sense to special-case that one - >>>> perhaps treat it as a separate category of its own. >>> I agree. I went through the items we currently have in the category >>> "service" (or "reason"). We have there "transfer-recall", "auto-callback" >>> and "hold-recall", which are sent in an INVITE and indicate to the callee >>> the "reason" for the incoming call. We could put them in the "reason" >>> category. We also have "call-waiting" and "forward", which are sent in an >>> 180 Ringing and indicate to the caller that some network service was >>> applied >>> to the call at the calee's side. We could put them in the "service" >>> category. >>> Would this partitioning suit your vision ? >> I had proposed just clumping those together into a single category (which I >> called reason): >> >> urn:alert:reason: >> >> - normal (default) (ring & ringback) >> - call-waiting ( ringback) >> - forward (ring & ringback) >> - auto-callback (ring & ringback) >> - recall.hold (ring & ringback) >> - recall.transfer (ring & ringback) >> - private. (ring & ringback) >> >> My logic above is: >> >> - whether this applies to ring or ringback depends on context >> (the message it is in) so doesn't have to be part of the naming. >> Making this part of the naming just introduces another sort of >> error to deal with. ("reason" can only be used in requests, while >> "service" can only be used in responses.) >> Is there a strong reason partition things that way? >> >> - for many (but perhaps not all) it might be useful in both >> directions, though the particular alert used would differ. >> >> For instance, its useful to inform both the holder and the holdee of a >> hold-recall. >> >> (Note that I also changed the naming to recall.hold and recall.transfer >> because the are both "recall" functions, and it might be convenient for some >> devices to alert them both the same. I'm still debating with myself whether >> auto-callback should be recall.auto.) >> >> Thanks, >> Paul >> >>> Thanks a lot >>> Laura >>>> Thanks, >>>> Paul >>>> >>>>> Thanks a lot >>>>> Laura >>>>> >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Gesendet: Donnerstag, 25. März 2010 19:51 >>>>> An: Laura Liess >>>>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerold >>> Pinker >>>>> Betreff: Re: [dispatch] FW: I-D >>>>> Action:draft-liess-dispatch-alert-info-urns-01.txt >>>>> >>>>> I've been thinking about how the "namespace" of alert-info URNs might be >>>>> reorganized. My goals in doing so are: >>>>> - allow the different "aspects" of the alert to be specified >>>>> - make it clear what the combination rules are for these >>>>> - allow for comparable expressiveness for rings and ringbacks >>>>> - provide room for extension >>>>> >>>>> The following is a rough outline of a what I have in mind: >>>>> >>>>> The urn syntax is as in the current draft, *except*: >>>>> >>>>> alert-category = "reason" / "priority" / "source" / >>>>> "duration" / "delay" / "locale" / >>>>> extension-category >>>>> extension-category = token >>>>> >>>>> The principle for choosing these categories is that they are orthogonal. >>>>> Hence there is a single rule for well-formedness of Alert-Info: >>>>> there can be at most one instance of each alert-category, and in >>>>> principle any such combination is valid. (Though some may be silly or >>>>> uninteresting.) >>>>> >>>>> The above doesn't distinguish ring from ringback. That is to be >>>>> determined from context - when present in a request it describes the >>>>> ring. When present in a response it describes the ringback. Again, in >>>>> principle any combination can be used for either ring or ringback, >>>>> though some combinations may be silly or uninteresting. >>>>> >>>>> The exact way in which the various categories are combined for rendering >>>>> is left as an implementation issue. The implementation is free to ignore >>>>> any or all at its whim. >>>>> >>>>> Its my intent that things previously discussed in the draft can all be >>>>> mapped onto these categories. Here is my swag at doing so: >>>>> >>>>> urn:alert:reason: >>>>> >>>>> - normal (default) >>>>> - call-waiting >>>>> - forward >>>>> - auto-callback >>>>> - recall.hold >>>>> - recall.transfer >>>>> - private. >>>>> >>>>> urn:alert:priority: >>>>> >>>>> - normal (default) >>>>> - low >>>>> - high >>>>> - crisis >>>>> - private. >>>>> >>>>> urn:alert:source: >>>>> >>>>> - unclassified (default) >>>>> - internal >>>>> - external >>>>> - friend >>>>> - family >>>>> - private. >>>>> >>>>> urn:alert:duration: >>>>> >>>>> - normal (default) >>>>> - short (or could be "zip") >>>>> - long (for completeness, or omit if unneeded) >>>>> - private. >>>>> >>>>> urn:alert:delay: >>>>> >>>>> - none (default) >>>>> - yes (not sure what to put here) >>>>> - private. >>>>> >>>>> urn:alert:locale: >>>>> >>>>> - default (default) >>>>> - country. >>>>> - private. >>>>> >>>>> In the above the "private." syntax is for extensions >>>>> specific to independent organizations. The is in the form >>>>> of a "reverse FQDN" such as is used for Java package names. This gives a >>>>> way of assigning unique names without the need for a new registry. The >>>>> namespace for each alert category is independent. Those assigning new >>>>> names must ensure they are in a position to assign names uniquely for >>>>> the FQDN they choose. >>>>> >>>>> (I have considerable reservation about introducing such an uncontrolled >>>>> extension mechanism. I see how it can provide a lot of flexibility in >>>>> providing tailored user experiences. But it can also lead to vendor lock >>>>> in if a device is only capable of supporting a particular vendor's >>>>> specific extensions. So I think this needs a lot of discussion.) >>>>> >>>>> For example, I might want to define: >>>>> >>>>> urn:alert:source:private.com.cisco.customer >>>>> >>>>> If I were to do so, I should first ensure that I speak for cisco.com >>>>> when coining this. >>>>> >>>>> Additions to the values above other than via the "private" mechanism >>>>> would be by standards action. The same for adding new categories. >>>>> (There could be a "private" mechanism for categories too. But I'm not at >>>>> all confident that is a good thing.) >>>>> >>>>> I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem >>>>> quite right. The reason could still be any of those other things. For >>>>> the ring indication its far from clear to me that it is needed at all - >>>>> the recipient already knows it is on a call, and doesn't need to be told >>>>> that. It may make more sense for the ringback - in that case you are >>>>> being told something about the state of the other party. Perhaps this >>>>> should be replaced by something about the state of the party sending the >>>>> message. E.g. >>>>> >>>>> urn:alert:state: >>>>> >>>>> - unknown >>>>> - waiting (in a request, means the caller is waiting >>>>> for the call to complete. The normal case.) >>>>> - on-a-call (in a response, means the called party >>>>> is on another call - the call waiting case. >>>>> But could apply to a caller as well.) >>>>> - away (in a request, means the call has been generated >>>>> automatically and the user will be summoned if/when >>>>> the call completes. This is the converse of waiting) >>>>> >>>>> (This "state" is really a form of presence. Whether its good to encode >>>>> it here, rather than actually transmitting pidf, is an interesting >>>>> question.) >>>>> >>>>> How all of this might be mapped onto actual renderings is probably not >>>>> something that should be standardized, but it might be worth including >>>>> some possibilities as examples. One that comes to mind is: >>>>> >>>>> (Assuming all rendering are audio): >>>>> >>>>> - the device has a set of possible clips it can render >>>>> - each is attributed with the values it matches for each >>>>> category above. (none, one, several, or all for each >>>>> category.) >>>>> >>>>> The device just finds the maximal match and renders that one. >>>>> >>>>> This might be augmented if there are different sorts of renderings - >>>>> e.g. audio, visual, tactile (vibrarion). In that case it might seek out >>>>> a match for each sort and render them all. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>> > From R.Jesske@telekom.de Thu Apr 8 00:46:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E171D3A68F8 for ; Thu, 8 Apr 2010 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 Xn02IED5eATX for ; Thu, 8 Apr 2010 00:46:04 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id A76243A6807 for ; Thu, 8 Apr 2010 00:45:59 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 08 Apr 2010 09:45:50 +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, 8 Apr 2010 09:45:50 +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_01CAD6EF.8254EBCE" Date: Thu, 8 Apr 2010 09:45:54 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD405E0DB56@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dw== From: To: X-OriginalArrivalTime: 08 Apr 2010 07:45:50.0843 (UTC) FILETIME=[827FECB0:01CAD6EF] Subject: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-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, 08 Apr 2010 07:46:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD6EF.8254EBCE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, During the discussion concerning the Reason header field in Responses I = was asked to split the document into an requirements part and an = protocol part. So please feel free to comment on the drafts.=20 http://64.170.98.42/html/draft-jesske-dispatch-reason-in-responses-02 http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-responses-00= Best regards Roland Jesske Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628-2766 (Tel.) +49 521 9210-3753 (Fax) +49 171 8618-445 (Mobil) E-Mail: r.jesske@telekom.de www.telekom.com =20 Erleben, was verbindet.=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht = jede E-Mail drucken. ------_=_NextPart_001_01CAD6EF.8254EBCE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reason In responses = (draft-jesske-dispatch-reason-in-responses-02)

Dear all,
During the discussion concerning the = Reason header field in Responses I was asked to split the document into = an requirements part and an protocol part.

So please feel free to comment on the = drafts.

http://64.170.98.42/html/draft-jesske-dispatch-reason-in-r= esponses-02

http://64.170.98.42/html/draft-jesske-dispatch-req-reason-= in-responses-00

Best = regards

Roland = Jesske


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 = Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobil)
E-Mail: r.jesske@telekom.de
www.telekom.com 

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn = (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn = (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

Gro=DFe Ver=E4nderungen fangen klein an – Ressourcen schonen und nicht = jede E-Mail drucken.


------_=_NextPart_001_01CAD6EF.8254EBCE-- From laura.liess.dt@googlemail.com Thu Apr 8 06:50:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9EB28C11F for ; Thu, 8 Apr 2010 06:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=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 1YTXPc0nfXNP for ; Thu, 8 Apr 2010 06:49:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DF19F3A68C1 for ; Thu, 8 Apr 2010 06:49:53 -0700 (PDT) Received: by wwb34 with SMTP id 34so5225wwb.31 for ; Thu, 08 Apr 2010 06:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b4ZtapUgfS0wGyWG1NejUxxOQXbDwVvLaena2TuE9Ho=; b=Zpa31ByyoSrVFye7m8+OZGlQTXSjzKrghBKnkNAY2bGhJg9js0jyREgQNQZK5cp1Ol Pghe/OyT16HM2FkDgIfrV8SMqxnYlMdneFeZx6pnr3vDUlWcB9eAig5jXQ/A9dnHNqEd MkNi425S6LjlbAclzQe8nad7N8LSKmT2rEkAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VI/rGuL4bkCxhGr5awCh5N76yrFOLyBfgi7tuVbtxyML4QXIcmQo61FCdp9S86uCpp eIbeN8uTz83fdbvVjwcMn+vv24jtVcWW3dH+OQ5QVbW9nTspijQgfR6E6WIyJjyXM00a 6U6fbsAWDqPYbyXWw5dsyqw0ZZSnt/bXVlco4= MIME-Version: 1.0 Received: by 10.216.169.85 with HTTP; Thu, 8 Apr 2010 06:49:47 -0700 (PDT) In-Reply-To: <4BBB4171.2010801@cisco.com> References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> <4BB4E8D0.4030407@cisco.com> <4BBB4171.2010801@cisco.com> Date: Thu, 8 Apr 2010 15:49:47 +0200 Received: by 10.216.183.143 with SMTP id q15mr53953wem.208.1270734587474; Thu, 08 Apr 2010 06:49:47 -0700 (PDT) Message-ID: From: Laura Liess To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 08 Apr 2010 13:50:05 -0000 Paul, I seems to me that we reached a consensus :-). I hope I understood correctly all your comments. Just to avoid some possible misunderstandings, I would like to write down my understanding of what we agreed on: alert-category =3D "service" / "priority" / "source" / "duration" / "delay" / "locale" / extension-category extension-category =3D token The categories are orthogonal. Any Alert-Info URN defined in this specification is syntacticaly valid for ring and for ringback and can be used in an INVITE or in a 18x response. There can be at most one instance of each alert-category in an Alert-Info header. In principle any combination of Alert-Info URNs with different "alert-category" is valid and can be used for either ring or ringback, though some combinations may not make sense. The receiving UA should make the decision about what to render to the user and what device it is rendered on depending on the value of the Alert-Info URN and the kind of the received message (INVITE or 18x-response). Typically, the same UA will do the rendering of a particular Alert-Info URN received in an INVITE differently from the rendering of the same Alert-Info URN received in a 18x response. The exact way in which the various categories are combined for rendering is left as an implementation issue. The implementation is free to ignore any or all received Alert-Info URNs. Values for alert-indications: urn:alert:service: - normal (default) - call-waiting - forward - recall.callback - recall.hold - recall.transfer - private. urn:alert:priority: - normal (default) - low - high - private. urn:alert:source: - unclassified (default) - internal - external - friend - family - private. urn:alert:duration: - normal (default) - short (or "zip") **/ Comment on this: We should check this with Alan, but I think "short" - long - private. urn:alert:delay: - none (default) - yes - private. urn:alert:locale: - default (default) - country. - private. The "private." syntax is for extensions specific to independent organizations. The is in the form of a "reverse FQDN" such as is used for Java package names. This gives a way of assigning unique names without the need for a new registry. The namespace for each alert category is independent. Those assigning new names must ensure they are in a position to assign names uniquely for the FQDN they choose. For example, Cisco might want to define: urn:alert:source:private.com.cisco.customer Adding new categories and adding alert-indication values other than via the "private" mechanism is standards action. Is this OK ? Thanks a lot Laura 2010/4/6 Paul Kyzivat : > Laura - responses inline. > > Laura Liess wrote: >> >> Paul, >> >> >>> I had proposed just clumping those together into a single category (whi= ch >>> I >>> called reason): >>> >>> urn:alert:reason: >>> >>> - normal (default) =A0 =A0 =A0 =A0(ring & ringback) >>> - call-waiting =A0 =A0 =A0 =A0 =A0 =A0( =A0 =A0 =A0 ringback) >>> - forward =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ring & ringback) >>> - auto-callback =A0 =A0 =A0 =A0 =A0 (ring & ringback) >>> - recall.hold =A0 =A0 =A0 =A0 =A0 =A0 (ring & ringback) >>> - recall.transfer =A0 =A0 =A0 =A0 (ring & ringback) >>> - private. =A0(ring & ringback) >>> >>> My logic above is: >>> >>> - whether this applies to ring or ringback depends on context >>> =A0(the message it is in) so doesn't have to be part of the naming. >>> =A0Making this part of the naming just introduces another sort of >>> =A0error to deal with. ("reason" can only be used in requests, while >>> =A0"service" can only be used in responses.) >>> =A0Is there a strong reason partition things that way? >> >> I think the proposal to separate urns for ring and ringback came up >> some months before, either on the mailing list or in some discussion >> at the IETF, in connection with the urn combinations problem. I am >> fine with your proposal. In principle, also the call-waiting >> indication can be sent to caller and callee. We probably have to >> include a statement in the draft that the receiving UA should make the >> decision about what to render to the user depending on oth the value >> of the Alert-Info URN and the kind of message it received (INVITE or >> 18x-response). > > Yes, that makes sense. Also, *what* is rendered, and what device it is > rendered on, will typically vary depending on this distinction. (The head= set > vs. the ringer or speaker.) That should all be mentioned. > >> The only problem I have here is the naming. Personally, I would prefer >> to name the whole category you described above as "service", for >> folowing reasons: >> - "reason" is somehow to broad. In principle, =A0it easily may happen >> that people add to this category also other "reason"-indications which >> have nothing to do with services and are orthogonal to the indications >> we have now in this category. But as a combination rule, we would like >> to have no more than one urn from same category. The name "service" >> would be more restrictive. >> - All items of this category indicate that some service was initiated. >> - Implementors, testers, operating guys are more familiar with >> call-waiting, forward or transfer as being a service than being a >> reason. > > I am not very attached to the name "reason". While I'm not fond of the na= me > "service", I don't strongly object to it either, and if that is an import= ant > choice for you I can accept it. > >> But if this name is not at acceptable for you, I would like at least >> to come back to your proposal in your mail from =A0April 1 and treat >> "call-waiting" as a separate "service" category. > > I can especially accept "service" if it means all these things are in the > same category. > >>> - for many (but perhaps not all) it might be useful in both >>> =A0directions, though the particular alert used would differ. >>> >>> For instance, its useful to inform both the holder and the holdee of a >>> hold-recall. >>> >>> (Note that I also changed the naming to recall.hold and recall.transfer >>> because the are both "recall" functions, and it might be convenient for >>> some >>> devices to alert them both the same. I'm still debating with myself >>> whether >>> auto-callback should be recall.auto.) >> >> This makes sense to me. (I just used the old names in my mail.) =A0Only >> I would choose recall.callback instead of recall.auto. I think it is >> more intuitive. > > Sounds good to me. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Thanks =A0a lot >> Laura >> >> >> 2010/4/1 Paul Kyzivat : >>> >>> Laura Liess wrote: >>>>> >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> How to name things is a second order issue. If its just a matter of >>>>> "service" vs. "reason" then I don't care very much. (I'm not especial= ly >>>>> attached to "reason", but I also find "service" somewhat confusing fo= r >>>>> the purpose.) >>>>> >>>>> The orthogonality is more important. The way I partitioned the data i= s >>>>> just a first cut, and I'm entirely open to alternative ways of doing >>>>> that. But I would hate to see the categorization warped just to fit o= ne >>>>> preexisting use. IMO it would make more sense to special-case that on= e >>>>> - >>>>> perhaps treat it as a separate category of its own. >>>> >>>> I agree. I went through the items we currently have in the category >>>> "service" (or "reason"). We have there "transfer-recall", >>>> "auto-callback" >>>> and "hold-recall", which are sent in an INVITE and indicate to the >>>> callee >>>> the "reason" for the incoming call. We could put them in the "reason" >>>> category. We also have "call-waiting" and "forward", which are sent in >>>> an >>>> 180 Ringing and indicate to the caller that some network service was >>>> applied >>>> to the call at the calee's side. We could put them in the "service" >>>> category. >>>> Would this partitioning suit your vision ? >>> >>> I had proposed just clumping those together into a single category (whi= ch >>> I >>> called reason): >>> >>> urn:alert:reason: >>> >>> - normal (default) =A0 =A0 =A0 =A0(ring & ringback) >>> - call-waiting =A0 =A0 =A0 =A0 =A0 =A0( =A0 =A0 =A0 ringback) >>> - forward =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ring & ringback) >>> - auto-callback =A0 =A0 =A0 =A0 =A0 (ring & ringback) >>> - recall.hold =A0 =A0 =A0 =A0 =A0 =A0 (ring & ringback) >>> - recall.transfer =A0 =A0 =A0 =A0 (ring & ringback) >>> - private. =A0(ring & ringback) >>> >>> My logic above is: >>> >>> - whether this applies to ring or ringback depends on context >>> =A0(the message it is in) so doesn't have to be part of the naming. >>> =A0Making this part of the naming just introduces another sort of >>> =A0error to deal with. ("reason" can only be used in requests, while >>> =A0"service" can only be used in responses.) >>> =A0Is there a strong reason partition things that way? >>> >>> - for many (but perhaps not all) it might be useful in both >>> =A0directions, though the particular alert used would differ. >>> >>> For instance, its useful to inform both the holder and the holdee of a >>> hold-recall. >>> >>> (Note that I also changed the naming to recall.hold and recall.transfer >>> because the are both "recall" functions, and it might be convenient for >>> some >>> devices to alert them both the same. I'm still debating with myself >>> whether >>> auto-callback should be recall.auto.) >>> >>> =A0 =A0 =A0 Thanks, >>> =A0 =A0 =A0 Paul >>> >>>> Thanks a lot >>>> Laura >>>>> >>>>> =A0 =A0 =A0 Thanks, >>>>> =A0 =A0 =A0 Paul >>>>> >>>>>> Thanks a lot >>>>>> Laura >>>>>> >>>>>> >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Gesendet: Donnerstag, 25. M=E4rz 2010 19:51 >>>>>> An: Laura Liess >>>>>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerol= d >>>> >>>> Pinker >>>>>> >>>>>> Betreff: Re: [dispatch] FW: I-D >>>>>> Action:draft-liess-dispatch-alert-info-urns-01.txt >>>>>> >>>>>> I've been thinking about how the "namespace" of alert-info URNs migh= t >>>>>> be >>>>>> reorganized. My goals in doing so are: >>>>>> - allow the different "aspects" of the alert to be specified >>>>>> - make it clear what the combination rules are for these >>>>>> - allow for comparable expressiveness for rings and ringbacks >>>>>> - provide room for extension >>>>>> >>>>>> The following is a rough outline of a what I have in mind: >>>>>> >>>>>> The urn syntax is as in the current draft, *except*: >>>>>> >>>>>> alert-category =A0=3D "reason" / "priority" / "source" / >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"duration" / "delay" / "locale" / >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0extension-category >>>>>> extension-category =3D token >>>>>> >>>>>> The principle for choosing these categories is that they are >>>>>> orthogonal. >>>>>> Hence there is a single rule for well-formedness of Alert-Info: >>>>>> there can be at most one instance of each alert-category, and in >>>>>> principle any such combination is valid. (Though some may be silly o= r >>>>>> uninteresting.) >>>>>> >>>>>> The above doesn't distinguish ring from ringback. That is to be >>>>>> determined from context - when present in a request it describes the >>>>>> ring. When present in a response it describes the ringback. Again, i= n >>>>>> principle any combination can be used for either ring or ringback, >>>>>> though some combinations may be silly or uninteresting. >>>>>> >>>>>> The exact way in which the various categories are combined for >>>>>> rendering >>>>>> is left as an implementation issue. The implementation is free to >>>>>> ignore >>>>>> any or all at its whim. >>>>>> >>>>>> Its my intent that things previously discussed in the draft can all = be >>>>>> mapped onto these categories. Here is my swag at doing so: >>>>>> >>>>>> urn:alert:reason: >>>>>> >>>>>> - normal (default) >>>>>> - call-waiting >>>>>> - forward >>>>>> - auto-callback >>>>>> - recall.hold >>>>>> - recall.transfer >>>>>> - private. >>>>>> >>>>>> urn:alert:priority: >>>>>> >>>>>> - normal (default) >>>>>> - low >>>>>> - high >>>>>> - crisis >>>>>> - private. >>>>>> >>>>>> urn:alert:source: >>>>>> >>>>>> - unclassified (default) >>>>>> - internal >>>>>> - external >>>>>> - friend >>>>>> - family >>>>>> - private. >>>>>> >>>>>> urn:alert:duration: >>>>>> >>>>>> - normal (default) >>>>>> - short (or could be "zip") >>>>>> - long (for completeness, or omit if unneeded) >>>>>> - private. >>>>>> >>>>>> urn:alert:delay: >>>>>> >>>>>> - none (default) >>>>>> - yes (not sure what to put here) >>>>>> - private. >>>>>> >>>>>> urn:alert:locale: >>>>>> >>>>>> - default (default) >>>>>> - country. >>>>>> - private. >>>>>> >>>>>> In the above the "private." syntax is for extensions >>>>>> specific to independent organizations. The is in the >>>>>> form >>>>>> of a "reverse FQDN" such as is used for Java package names. This giv= es >>>>>> a >>>>>> way of assigning unique names without the need for a new registry. T= he >>>>>> namespace for each alert category is independent. Those assigning ne= w >>>>>> names must ensure they are in a position to assign names uniquely fo= r >>>>>> the FQDN they choose. >>>>>> >>>>>> (I have considerable reservation about introducing such an >>>>>> uncontrolled >>>>>> extension mechanism. I see how it can provide a lot of flexibility i= n >>>>>> providing tailored user experiences. But it can also lead to vendor >>>>>> lock >>>>>> in if a device is only capable of supporting a particular vendor's >>>>>> specific extensions. So I think this needs a lot of discussion.) >>>>>> >>>>>> For example, I might want to define: >>>>>> >>>>>> urn:alert:source:private.com.cisco.customer >>>>>> >>>>>> If I were to do so, I should first ensure that I speak for cisco.com >>>>>> when coining this. >>>>>> >>>>>> Additions to the values above other than via the "private" mechanism >>>>>> would be by standards action. The same for adding new categories. >>>>>> (There could be a "private" mechanism for categories too. But I'm no= t >>>>>> at >>>>>> all confident that is a good thing.) >>>>>> >>>>>> I'm not quite sure about "call-waiting" as a "reason" - it doesn't >>>>>> seem >>>>>> quite right. The reason could still be any of those other things. Fo= r >>>>>> the ring indication its far from clear to me that it is needed at al= l >>>>>> - >>>>>> the recipient already knows it is on a call, and doesn't need to be >>>>>> told >>>>>> that. It may make more sense for the ringback - in that case you are >>>>>> being told something about the state of the other party. Perhaps thi= s >>>>>> should be replaced by something about the state of the party sending >>>>>> the >>>>>> message. E.g. >>>>>> >>>>>> urn:alert:state: >>>>>> >>>>>> - unknown >>>>>> - waiting (in a request, means the caller is waiting >>>>>> =A0 =A0 =A0 =A0 =A0 for the call to complete. The normal case.) >>>>>> - on-a-call (in a response, means the called party >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 is on another call - the call waiting case. >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 But could apply to a caller as well.) >>>>>> - away (in a request, means the call has been generated >>>>>> =A0 =A0 =A0 =A0automatically and the user will be summoned if/when >>>>>> =A0 =A0 =A0 =A0the call completes. This is the converse of waiting) >>>>>> >>>>>> (This "state" is really a form of presence. Whether its good to enco= de >>>>>> it here, rather than actually transmitting pidf, is an interesting >>>>>> question.) >>>>>> >>>>>> How all of this might be mapped onto actual renderings is probably n= ot >>>>>> something that should be standardized, but it might be worth includi= ng >>>>>> some possibilities as examples. One that comes to mind is: >>>>>> >>>>>> (Assuming all rendering are audio): >>>>>> >>>>>> - the device has a set of possible clips it can render >>>>>> - each is attributed with the values it matches for each >>>>>> =A0category above. (none, one, several, or all for each >>>>>> =A0category.) >>>>>> >>>>>> The device just finds the maximal match and renders that one. >>>>>> >>>>>> This might be augmented if there are different sorts of renderings - >>>>>> e.g. audio, visual, tactile (vibrarion). In that case it might seek >>>>>> out >>>>>> a match for each sort and render them all. >>>>>> >>>>>> =A0 =A0 =A0 Thanks, >>>>>> =A0 =A0 =A0 Paul >>>>>> >>>>>> >>>> >> > From pkyzivat@cisco.com Thu Apr 8 07:10:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3913A692F for ; Thu, 8 Apr 2010 07:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.772 X-Spam-Level: X-Spam-Status: No, score=-8.772 tagged_above=-999 required=5 tests=[AWL=-1.373, BAYES_50=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gil3LB8HaGYO for ; Thu, 8 Apr 2010 07:10:42 -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 A0F983A690A for ; Thu, 8 Apr 2010 07:10:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFqAvUtAZnwM/2dsb2JhbACbMXGgUZklgk4BDYItBA X-IronPort-AV: E=Sophos;i="4.52,170,1270425600"; d="scan'208";a="99906711" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2010 14:10:37 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o38EAbPZ002743; Thu, 8 Apr 2010 14:10:37 GMT Message-ID: <4BBDE3DE.1050902@cisco.com> Date: Thu, 08 Apr 2010 10:10:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> <4BB4E8D0.4030407@cisco.com> <4BBB4171.2010801@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 08 Apr 2010 14:10:46 -0000 Laura, This all sounds good to me. I expect others may want to see some refinements, such as the adding or removal of specific values, renaming of specific values, etc. But to me the main thing is to have established the orthogonality, the rules for combining, and the extensibility mechanism. I hope now get some feedback from others. Thanks, Paul Laura Liess wrote: > Paul, > > I seems to me that we reached a consensus :-). I hope I understood > correctly all your comments. Just to avoid some possible > misunderstandings, I would like to write down my understanding of what > we agreed on: > > > > alert-category = "service" / "priority" / "source" / > "duration" / "delay" / "locale" / > extension-category > extension-category = token > > The categories are orthogonal. Any Alert-Info URN defined in this > specification is syntacticaly valid for ring and for ringback and can > be used in an INVITE or in a 18x response. > There can be at most one instance of each alert-category in an > Alert-Info header. In principle any combination of Alert-Info URNs > with different "alert-category" is valid and can be used for either > ring or ringback, though some combinations may not make sense. > The receiving UA should make the decision about what to render to the > user and what device it is rendered on depending on the value of the > Alert-Info URN and the kind of the received message (INVITE or > 18x-response). Typically, the same UA will do the rendering of a > particular Alert-Info URN received in an INVITE differently from the > rendering of the same Alert-Info URN received in a 18x response. > > The exact way in which the various categories are combined for > rendering is left as an implementation issue. The implementation is > free to ignore any or all received Alert-Info URNs. > > > Values for alert-indications: > > urn:alert:service: > > - normal (default) > - call-waiting > - forward > - recall.callback > - recall.hold > - recall.transfer > - private. > > urn:alert:priority: > > - normal (default) > - low > - high > - private. > > urn:alert:source: > > - unclassified (default) > - internal > - external > - friend > - family > - private. > > urn:alert:duration: > > - normal (default) > - short (or "zip") **/ Comment on this: We should check this with > Alan, but I think "short" > - long > - private. > > urn:alert:delay: > > - none (default) > - yes > - private. > > urn:alert:locale: > > - default (default) > - country. > - private. > > The "private." syntax is for extensions specific to > independent organizations. The is in the form of a > "reverse FQDN" such as is used for Java package names. This gives a > way of assigning unique names without the need for a new registry. The > namespace for each alert category is independent. Those assigning new > names must ensure they are in a position to assign names uniquely for > the FQDN they choose. > > For example, Cisco might want to define: > > urn:alert:source:private.com.cisco.customer > > Adding new categories and adding alert-indication values other than > via the "private" mechanism is standards action. > > Is this OK ? > > > Thanks a lot > Laura > > > > 2010/4/6 Paul Kyzivat : >> Laura - responses inline. >> >> Laura Liess wrote: >>> Paul, >>> >>> >>>> I had proposed just clumping those together into a single category (which >>>> I >>>> called reason): >>>> >>>> urn:alert:reason: >>>> >>>> - normal (default) (ring & ringback) >>>> - call-waiting ( ringback) >>>> - forward (ring & ringback) >>>> - auto-callback (ring & ringback) >>>> - recall.hold (ring & ringback) >>>> - recall.transfer (ring & ringback) >>>> - private. (ring & ringback) >>>> >>>> My logic above is: >>>> >>>> - whether this applies to ring or ringback depends on context >>>> (the message it is in) so doesn't have to be part of the naming. >>>> Making this part of the naming just introduces another sort of >>>> error to deal with. ("reason" can only be used in requests, while >>>> "service" can only be used in responses.) >>>> Is there a strong reason partition things that way? >>> I think the proposal to separate urns for ring and ringback came up >>> some months before, either on the mailing list or in some discussion >>> at the IETF, in connection with the urn combinations problem. I am >>> fine with your proposal. In principle, also the call-waiting >>> indication can be sent to caller and callee. We probably have to >>> include a statement in the draft that the receiving UA should make the >>> decision about what to render to the user depending on oth the value >>> of the Alert-Info URN and the kind of message it received (INVITE or >>> 18x-response). >> Yes, that makes sense. Also, *what* is rendered, and what device it is >> rendered on, will typically vary depending on this distinction. (The headset >> vs. the ringer or speaker.) That should all be mentioned. >> >>> The only problem I have here is the naming. Personally, I would prefer >>> to name the whole category you described above as "service", for >>> folowing reasons: >>> - "reason" is somehow to broad. In principle, it easily may happen >>> that people add to this category also other "reason"-indications which >>> have nothing to do with services and are orthogonal to the indications >>> we have now in this category. But as a combination rule, we would like >>> to have no more than one urn from same category. The name "service" >>> would be more restrictive. >>> - All items of this category indicate that some service was initiated. >>> - Implementors, testers, operating guys are more familiar with >>> call-waiting, forward or transfer as being a service than being a >>> reason. >> I am not very attached to the name "reason". While I'm not fond of the name >> "service", I don't strongly object to it either, and if that is an important >> choice for you I can accept it. >> >>> But if this name is not at acceptable for you, I would like at least >>> to come back to your proposal in your mail from April 1 and treat >>> "call-waiting" as a separate "service" category. >> I can especially accept "service" if it means all these things are in the >> same category. >> >>>> - for many (but perhaps not all) it might be useful in both >>>> directions, though the particular alert used would differ. >>>> >>>> For instance, its useful to inform both the holder and the holdee of a >>>> hold-recall. >>>> >>>> (Note that I also changed the naming to recall.hold and recall.transfer >>>> because the are both "recall" functions, and it might be convenient for >>>> some >>>> devices to alert them both the same. I'm still debating with myself >>>> whether >>>> auto-callback should be recall.auto.) >>> This makes sense to me. (I just used the old names in my mail.) Only >>> I would choose recall.callback instead of recall.auto. I think it is >>> more intuitive. >> Sounds good to me. >> >> Thanks, >> Paul >> >>> Thanks a lot >>> Laura >>> >>> >>> 2010/4/1 Paul Kyzivat : >>>> Laura Liess wrote: >>>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> How to name things is a second order issue. If its just a matter of >>>>>> "service" vs. "reason" then I don't care very much. (I'm not especially >>>>>> attached to "reason", but I also find "service" somewhat confusing for >>>>>> the purpose.) >>>>>> >>>>>> The orthogonality is more important. The way I partitioned the data is >>>>>> just a first cut, and I'm entirely open to alternative ways of doing >>>>>> that. But I would hate to see the categorization warped just to fit one >>>>>> preexisting use. IMO it would make more sense to special-case that one >>>>>> - >>>>>> perhaps treat it as a separate category of its own. >>>>> I agree. I went through the items we currently have in the category >>>>> "service" (or "reason"). We have there "transfer-recall", >>>>> "auto-callback" >>>>> and "hold-recall", which are sent in an INVITE and indicate to the >>>>> callee >>>>> the "reason" for the incoming call. We could put them in the "reason" >>>>> category. We also have "call-waiting" and "forward", which are sent in >>>>> an >>>>> 180 Ringing and indicate to the caller that some network service was >>>>> applied >>>>> to the call at the calee's side. We could put them in the "service" >>>>> category. >>>>> Would this partitioning suit your vision ? >>>> I had proposed just clumping those together into a single category (which >>>> I >>>> called reason): >>>> >>>> urn:alert:reason: >>>> >>>> - normal (default) (ring & ringback) >>>> - call-waiting ( ringback) >>>> - forward (ring & ringback) >>>> - auto-callback (ring & ringback) >>>> - recall.hold (ring & ringback) >>>> - recall.transfer (ring & ringback) >>>> - private. (ring & ringback) >>>> >>>> My logic above is: >>>> >>>> - whether this applies to ring or ringback depends on context >>>> (the message it is in) so doesn't have to be part of the naming. >>>> Making this part of the naming just introduces another sort of >>>> error to deal with. ("reason" can only be used in requests, while >>>> "service" can only be used in responses.) >>>> Is there a strong reason partition things that way? >>>> >>>> - for many (but perhaps not all) it might be useful in both >>>> directions, though the particular alert used would differ. >>>> >>>> For instance, its useful to inform both the holder and the holdee of a >>>> hold-recall. >>>> >>>> (Note that I also changed the naming to recall.hold and recall.transfer >>>> because the are both "recall" functions, and it might be convenient for >>>> some >>>> devices to alert them both the same. I'm still debating with myself >>>> whether >>>> auto-callback should be recall.auto.) >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Thanks a lot >>>>> Laura >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Thanks a lot >>>>>>> Laura >>>>>>> >>>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> Gesendet: Donnerstag, 25. März 2010 19:51 >>>>>>> An: Laura Liess >>>>>>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerold >>>>> Pinker >>>>>>> Betreff: Re: [dispatch] FW: I-D >>>>>>> Action:draft-liess-dispatch-alert-info-urns-01.txt >>>>>>> >>>>>>> I've been thinking about how the "namespace" of alert-info URNs might >>>>>>> be >>>>>>> reorganized. My goals in doing so are: >>>>>>> - allow the different "aspects" of the alert to be specified >>>>>>> - make it clear what the combination rules are for these >>>>>>> - allow for comparable expressiveness for rings and ringbacks >>>>>>> - provide room for extension >>>>>>> >>>>>>> The following is a rough outline of a what I have in mind: >>>>>>> >>>>>>> The urn syntax is as in the current draft, *except*: >>>>>>> >>>>>>> alert-category = "reason" / "priority" / "source" / >>>>>>> "duration" / "delay" / "locale" / >>>>>>> extension-category >>>>>>> extension-category = token >>>>>>> >>>>>>> The principle for choosing these categories is that they are >>>>>>> orthogonal. >>>>>>> Hence there is a single rule for well-formedness of Alert-Info: >>>>>>> there can be at most one instance of each alert-category, and in >>>>>>> principle any such combination is valid. (Though some may be silly or >>>>>>> uninteresting.) >>>>>>> >>>>>>> The above doesn't distinguish ring from ringback. That is to be >>>>>>> determined from context - when present in a request it describes the >>>>>>> ring. When present in a response it describes the ringback. Again, in >>>>>>> principle any combination can be used for either ring or ringback, >>>>>>> though some combinations may be silly or uninteresting. >>>>>>> >>>>>>> The exact way in which the various categories are combined for >>>>>>> rendering >>>>>>> is left as an implementation issue. The implementation is free to >>>>>>> ignore >>>>>>> any or all at its whim. >>>>>>> >>>>>>> Its my intent that things previously discussed in the draft can all be >>>>>>> mapped onto these categories. Here is my swag at doing so: >>>>>>> >>>>>>> urn:alert:reason: >>>>>>> >>>>>>> - normal (default) >>>>>>> - call-waiting >>>>>>> - forward >>>>>>> - auto-callback >>>>>>> - recall.hold >>>>>>> - recall.transfer >>>>>>> - private. >>>>>>> >>>>>>> urn:alert:priority: >>>>>>> >>>>>>> - normal (default) >>>>>>> - low >>>>>>> - high >>>>>>> - crisis >>>>>>> - private. >>>>>>> >>>>>>> urn:alert:source: >>>>>>> >>>>>>> - unclassified (default) >>>>>>> - internal >>>>>>> - external >>>>>>> - friend >>>>>>> - family >>>>>>> - private. >>>>>>> >>>>>>> urn:alert:duration: >>>>>>> >>>>>>> - normal (default) >>>>>>> - short (or could be "zip") >>>>>>> - long (for completeness, or omit if unneeded) >>>>>>> - private. >>>>>>> >>>>>>> urn:alert:delay: >>>>>>> >>>>>>> - none (default) >>>>>>> - yes (not sure what to put here) >>>>>>> - private. >>>>>>> >>>>>>> urn:alert:locale: >>>>>>> >>>>>>> - default (default) >>>>>>> - country. >>>>>>> - private. >>>>>>> >>>>>>> In the above the "private." syntax is for extensions >>>>>>> specific to independent organizations. The is in the >>>>>>> form >>>>>>> of a "reverse FQDN" such as is used for Java package names. This gives >>>>>>> a >>>>>>> way of assigning unique names without the need for a new registry. The >>>>>>> namespace for each alert category is independent. Those assigning new >>>>>>> names must ensure they are in a position to assign names uniquely for >>>>>>> the FQDN they choose. >>>>>>> >>>>>>> (I have considerable reservation about introducing such an >>>>>>> uncontrolled >>>>>>> extension mechanism. I see how it can provide a lot of flexibility in >>>>>>> providing tailored user experiences. But it can also lead to vendor >>>>>>> lock >>>>>>> in if a device is only capable of supporting a particular vendor's >>>>>>> specific extensions. So I think this needs a lot of discussion.) >>>>>>> >>>>>>> For example, I might want to define: >>>>>>> >>>>>>> urn:alert:source:private.com.cisco.customer >>>>>>> >>>>>>> If I were to do so, I should first ensure that I speak for cisco.com >>>>>>> when coining this. >>>>>>> >>>>>>> Additions to the values above other than via the "private" mechanism >>>>>>> would be by standards action. The same for adding new categories. >>>>>>> (There could be a "private" mechanism for categories too. But I'm not >>>>>>> at >>>>>>> all confident that is a good thing.) >>>>>>> >>>>>>> I'm not quite sure about "call-waiting" as a "reason" - it doesn't >>>>>>> seem >>>>>>> quite right. The reason could still be any of those other things. For >>>>>>> the ring indication its far from clear to me that it is needed at all >>>>>>> - >>>>>>> the recipient already knows it is on a call, and doesn't need to be >>>>>>> told >>>>>>> that. It may make more sense for the ringback - in that case you are >>>>>>> being told something about the state of the other party. Perhaps this >>>>>>> should be replaced by something about the state of the party sending >>>>>>> the >>>>>>> message. E.g. >>>>>>> >>>>>>> urn:alert:state: >>>>>>> >>>>>>> - unknown >>>>>>> - waiting (in a request, means the caller is waiting >>>>>>> for the call to complete. The normal case.) >>>>>>> - on-a-call (in a response, means the called party >>>>>>> is on another call - the call waiting case. >>>>>>> But could apply to a caller as well.) >>>>>>> - away (in a request, means the call has been generated >>>>>>> automatically and the user will be summoned if/when >>>>>>> the call completes. This is the converse of waiting) >>>>>>> >>>>>>> (This "state" is really a form of presence. Whether its good to encode >>>>>>> it here, rather than actually transmitting pidf, is an interesting >>>>>>> question.) >>>>>>> >>>>>>> How all of this might be mapped onto actual renderings is probably not >>>>>>> something that should be standardized, but it might be worth including >>>>>>> some possibilities as examples. One that comes to mind is: >>>>>>> >>>>>>> (Assuming all rendering are audio): >>>>>>> >>>>>>> - the device has a set of possible clips it can render >>>>>>> - each is attributed with the values it matches for each >>>>>>> category above. (none, one, several, or all for each >>>>>>> category.) >>>>>>> >>>>>>> The device just finds the maximal match and renders that one. >>>>>>> >>>>>>> This might be augmented if there are different sorts of renderings - >>>>>>> e.g. audio, visual, tactile (vibrarion). In that case it might seek >>>>>>> out >>>>>>> a match for each sort and render them all. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> > From john.elwell@siemens-enterprise.com Fri Apr 9 03:17:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F74B3A6919 for ; Fri, 9 Apr 2010 03:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_64=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 oLo4iHceUCjq for ; Fri, 9 Apr 2010 03:17:19 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1A2FA3A67FD for ; Fri, 9 Apr 2010 03:17:11 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1496089; Fri, 9 Apr 2010 12:17:07 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E6ABB23F0278; Fri, 9 Apr 2010 12:17:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Apr 2010 12:17:07 +0200 From: "Elwell, John" To: Laura Liess , Paul Kyzivat Date: Fri, 9 Apr 2010 12:17:05 +0200 Thread-Topic: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt Thread-Index: AcrXImX/d8ZDYSGNQ0K8BngH9n7h8QAqqTvw Message-ID: References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> <4BB4E8D0.4030407@cisco.com> <4BBB4171.2010801@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 09 Apr 2010 10:17:21 -0000 This sounds like quite a comprehensive proposal. Perhaps it would benefit f= rom a little more being said on the handling of unknown or unsupported valu= es, and whether implementations are free to ignore categories not of intere= st. But that can wait until we have a draft. John > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Laura Liess > Sent: 08 April 2010 14:50 > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] FW: I-D > Action:draft-liess-dispatch-alert-info-urns-01.txt > > Paul, > > I seems to me that we reached a consensus :-). I hope I understood > correctly all your comments. Just to avoid some possible > misunderstandings, I would like to write down my understanding of what > we agreed on: > > > > alert-category =3D "service" / "priority" / "source" / > "duration" / "delay" / "locale" / > extension-category > extension-category =3D token > > The categories are orthogonal. Any Alert-Info URN defined in this > specification is syntacticaly valid for ring and for ringback and can > be used in an INVITE or in a 18x response. > There can be at most one instance of each alert-category in an > Alert-Info header. In principle any combination of Alert-Info URNs > with different "alert-category" is valid and can be used for either > ring or ringback, though some combinations may not make sense. > The receiving UA should make the decision about what to render to the > user and what device it is rendered on depending on the value of the > Alert-Info URN and the kind of the received message (INVITE or > 18x-response). Typically, the same UA will do the rendering of a > particular Alert-Info URN received in an INVITE differently from the > rendering of the same Alert-Info URN received in a 18x response. > > The exact way in which the various categories are combined for > rendering is left as an implementation issue. The implementation is > free to ignore any or all received Alert-Info URNs. > > > Values for alert-indications: > > urn:alert:service: > > - normal (default) > - call-waiting > - forward > - recall.callback > - recall.hold > - recall.transfer > - private. > > urn:alert:priority: > > - normal (default) > - low > - high > - private. > > urn:alert:source: > > - unclassified (default) > - internal > - external > - friend > - family > - private. > > urn:alert:duration: > > - normal (default) > - short (or "zip") **/ Comment on this: We should check this with > Alan, but I think "short" > - long > - private. > > urn:alert:delay: > > - none (default) > - yes > - private. > > urn:alert:locale: > > - default (default) > - country. > - private. > > The "private." syntax is for extensions specific to > independent organizations. The is in the form of a > "reverse FQDN" such as is used for Java package names. This gives a > way of assigning unique names without the need for a new registry. The > namespace for each alert category is independent. Those assigning new > names must ensure they are in a position to assign names uniquely for > the FQDN they choose. > > For example, Cisco might want to define: > > urn:alert:source:private.com.cisco.customer > > Adding new categories and adding alert-indication values other than > via the "private" mechanism is standards action. > > Is this OK ? > > > Thanks a lot > Laura > > > > 2010/4/6 Paul Kyzivat : > > Laura - responses inline. > > > > Laura Liess wrote: > >> > >> Paul, > >> > >> > >>> I had proposed just clumping those together into a single > category (which > >>> I > >>> called reason): > >>> > >>> urn:alert:reason: > >>> > >>> - normal (default) (ring & ringback) > >>> - call-waiting ( ringback) > >>> - forward (ring & ringback) > >>> - auto-callback (ring & ringback) > >>> - recall.hold (ring & ringback) > >>> - recall.transfer (ring & ringback) > >>> - private. (ring & ringback) > >>> > >>> My logic above is: > >>> > >>> - whether this applies to ring or ringback depends on context > >>> (the message it is in) so doesn't have to be part of the naming. > >>> Making this part of the naming just introduces another sort of > >>> error to deal with. ("reason" can only be used in requests, while > >>> "service" can only be used in responses.) > >>> Is there a strong reason partition things that way? > >> > >> I think the proposal to separate urns for ring and ringback came up > >> some months before, either on the mailing list or in some > discussion > >> at the IETF, in connection with the urn combinations problem. I am > >> fine with your proposal. In principle, also the call-waiting > >> indication can be sent to caller and callee. We probably have to > >> include a statement in the draft that the receiving UA > should make the > >> decision about what to render to the user depending on oth > the value > >> of the Alert-Info URN and the kind of message it received > (INVITE or > >> 18x-response). > > > > Yes, that makes sense. Also, *what* is rendered, and what > device it is > > rendered on, will typically vary depending on this > distinction. (The headset > > vs. the ringer or speaker.) That should all be mentioned. > > > >> The only problem I have here is the naming. Personally, I > would prefer > >> to name the whole category you described above as "service", for > >> folowing reasons: > >> - "reason" is somehow to broad. In principle, it easily may happen > >> that people add to this category also other > "reason"-indications which > >> have nothing to do with services and are orthogonal to the > indications > >> we have now in this category. But as a combination rule, > we would like > >> to have no more than one urn from same category. The name "service" > >> would be more restrictive. > >> - All items of this category indicate that some service > was initiated. > >> - Implementors, testers, operating guys are more familiar with > >> call-waiting, forward or transfer as being a service than being a > >> reason. > > > > I am not very attached to the name "reason". While I'm not > fond of the name > > "service", I don't strongly object to it either, and if > that is an important > > choice for you I can accept it. > > > >> But if this name is not at acceptable for you, I would > like at least > >> to come back to your proposal in your mail from April 1 and treat > >> "call-waiting" as a separate "service" category. > > > > I can especially accept "service" if it means all these > things are in the > > same category. > > > >>> - for many (but perhaps not all) it might be useful in both > >>> directions, though the particular alert used would differ. > >>> > >>> For instance, its useful to inform both the holder and > the holdee of a > >>> hold-recall. > >>> > >>> (Note that I also changed the naming to recall.hold and > recall.transfer > >>> because the are both "recall" functions, and it might be > convenient for > >>> some > >>> devices to alert them both the same. I'm still debating > with myself > >>> whether > >>> auto-callback should be recall.auto.) > >> > >> This makes sense to me. (I just used the old names in my > mail.) Only > >> I would choose recall.callback instead of recall.auto. I > think it is > >> more intuitive. > > > > Sounds good to me. > > > > Thanks, > > Paul > > > >> Thanks a lot > >> Laura > >> > >> > >> 2010/4/1 Paul Kyzivat : > >>> > >>> Laura Liess wrote: > >>>>> > >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> How to name things is a second order issue. If its just > a matter of > >>>>> "service" vs. "reason" then I don't care very much. > (I'm not especially > >>>>> attached to "reason", but I also find "service" > somewhat confusing for > >>>>> the purpose.) > >>>>> > >>>>> The orthogonality is more important. The way I > partitioned the data is > >>>>> just a first cut, and I'm entirely open to alternative > ways of doing > >>>>> that. But I would hate to see the categorization warped > just to fit one > >>>>> preexisting use. IMO it would make more sense to > special-case that one > >>>>> - > >>>>> perhaps treat it as a separate category of its own. > >>>> > >>>> I agree. I went through the items we currently have in > the category > >>>> "service" (or "reason"). We have there "transfer-recall", > >>>> "auto-callback" > >>>> and "hold-recall", which are sent in an INVITE and > indicate to the > >>>> callee > >>>> the "reason" for the incoming call. We could put them in > the "reason" > >>>> category. We also have "call-waiting" and "forward", > which are sent in > >>>> an > >>>> 180 Ringing and indicate to the caller that some network > service was > >>>> applied > >>>> to the call at the calee's side. We could put them in > the "service" > >>>> category. > >>>> Would this partitioning suit your vision ? > >>> > >>> I had proposed just clumping those together into a single > category (which > >>> I > >>> called reason): > >>> > >>> urn:alert:reason: > >>> > >>> - normal (default) (ring & ringback) > >>> - call-waiting ( ringback) > >>> - forward (ring & ringback) > >>> - auto-callback (ring & ringback) > >>> - recall.hold (ring & ringback) > >>> - recall.transfer (ring & ringback) > >>> - private. (ring & ringback) > >>> > >>> My logic above is: > >>> > >>> - whether this applies to ring or ringback depends on context > >>> (the message it is in) so doesn't have to be part of the naming. > >>> Making this part of the naming just introduces another sort of > >>> error to deal with. ("reason" can only be used in requests, while > >>> "service" can only be used in responses.) > >>> Is there a strong reason partition things that way? > >>> > >>> - for many (but perhaps not all) it might be useful in both > >>> directions, though the particular alert used would differ. > >>> > >>> For instance, its useful to inform both the holder and > the holdee of a > >>> hold-recall. > >>> > >>> (Note that I also changed the naming to recall.hold and > recall.transfer > >>> because the are both "recall" functions, and it might be > convenient for > >>> some > >>> devices to alert them both the same. I'm still debating > with myself > >>> whether > >>> auto-callback should be recall.auto.) > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Thanks a lot > >>>> Laura > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> Thanks a lot > >>>>>> Laura > >>>>>> > >>>>>> > >>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Gesendet: Donnerstag, 25. M=E4rz 2010 19:51 > >>>>>> An: Laura Liess > >>>>>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; > Liess Laura; Gerold > >>>> > >>>> Pinker > >>>>>> > >>>>>> Betreff: Re: [dispatch] FW: I-D > >>>>>> Action:draft-liess-dispatch-alert-info-urns-01.txt > >>>>>> > >>>>>> I've been thinking about how the "namespace" of > alert-info URNs might > >>>>>> be > >>>>>> reorganized. My goals in doing so are: > >>>>>> - allow the different "aspects" of the alert to be specified > >>>>>> - make it clear what the combination rules are for these > >>>>>> - allow for comparable expressiveness for rings and ringbacks > >>>>>> - provide room for extension > >>>>>> > >>>>>> The following is a rough outline of a what I have in mind: > >>>>>> > >>>>>> The urn syntax is as in the current draft, *except*: > >>>>>> > >>>>>> alert-category =3D "reason" / "priority" / "source" / > >>>>>> "duration" / "delay" / "locale" / > >>>>>> extension-category > >>>>>> extension-category =3D token > >>>>>> > >>>>>> The principle for choosing these categories is that they are > >>>>>> orthogonal. > >>>>>> Hence there is a single rule for well-formedness of Alert-Info: > >>>>>> there can be at most one instance of each > alert-category, and in > >>>>>> principle any such combination is valid. (Though some > may be silly or > >>>>>> uninteresting.) > >>>>>> > >>>>>> The above doesn't distinguish ring from ringback. That is to be > >>>>>> determined from context - when present in a request it > describes the > >>>>>> ring. When present in a response it describes the > ringback. Again, in > >>>>>> principle any combination can be used for either ring > or ringback, > >>>>>> though some combinations may be silly or uninteresting. > >>>>>> > >>>>>> The exact way in which the various categories are combined for > >>>>>> rendering > >>>>>> is left as an implementation issue. The implementation > is free to > >>>>>> ignore > >>>>>> any or all at its whim. > >>>>>> > >>>>>> Its my intent that things previously discussed in the > draft can all be > >>>>>> mapped onto these categories. Here is my swag at doing so: > >>>>>> > >>>>>> urn:alert:reason: > >>>>>> > >>>>>> - normal (default) > >>>>>> - call-waiting > >>>>>> - forward > >>>>>> - auto-callback > >>>>>> - recall.hold > >>>>>> - recall.transfer > >>>>>> - private. > >>>>>> > >>>>>> urn:alert:priority: > >>>>>> > >>>>>> - normal (default) > >>>>>> - low > >>>>>> - high > >>>>>> - crisis > >>>>>> - private. > >>>>>> > >>>>>> urn:alert:source: > >>>>>> > >>>>>> - unclassified (default) > >>>>>> - internal > >>>>>> - external > >>>>>> - friend > >>>>>> - family > >>>>>> - private. > >>>>>> > >>>>>> urn:alert:duration: > >>>>>> > >>>>>> - normal (default) > >>>>>> - short (or could be "zip") > >>>>>> - long (for completeness, or omit if unneeded) > >>>>>> - private. > >>>>>> > >>>>>> urn:alert:delay: > >>>>>> > >>>>>> - none (default) > >>>>>> - yes (not sure what to put here) > >>>>>> - private. > >>>>>> > >>>>>> urn:alert:locale: > >>>>>> > >>>>>> - default (default) > >>>>>> - country. > >>>>>> - private. > >>>>>> > >>>>>> In the above the "private." syntax is > for extensions > >>>>>> specific to independent organizations. The > is in the > >>>>>> form > >>>>>> of a "reverse FQDN" such as is used for Java package > names. This gives > >>>>>> a > >>>>>> way of assigning unique names without the need for a > new registry. The > >>>>>> namespace for each alert category is independent. > Those assigning new > >>>>>> names must ensure they are in a position to assign > names uniquely for > >>>>>> the FQDN they choose. > >>>>>> > >>>>>> (I have considerable reservation about introducing such an > >>>>>> uncontrolled > >>>>>> extension mechanism. I see how it can provide a lot of > flexibility in > >>>>>> providing tailored user experiences. But it can also > lead to vendor > >>>>>> lock > >>>>>> in if a device is only capable of supporting a > particular vendor's > >>>>>> specific extensions. So I think this needs a lot of > discussion.) > >>>>>> > >>>>>> For example, I might want to define: > >>>>>> > >>>>>> urn:alert:source:private.com.cisco.customer > >>>>>> > >>>>>> If I were to do so, I should first ensure that I speak > for cisco.com > >>>>>> when coining this. > >>>>>> > >>>>>> Additions to the values above other than via the > "private" mechanism > >>>>>> would be by standards action. The same for adding new > categories. > >>>>>> (There could be a "private" mechanism for categories > too. But I'm not > >>>>>> at > >>>>>> all confident that is a good thing.) > >>>>>> > >>>>>> I'm not quite sure about "call-waiting" as a "reason" > - it doesn't > >>>>>> seem > >>>>>> quite right. The reason could still be any of those > other things. For > >>>>>> the ring indication its far from clear to me that it > is needed at all > >>>>>> - > >>>>>> the recipient already knows it is on a call, and > doesn't need to be > >>>>>> told > >>>>>> that. It may make more sense for the ringback - in > that case you are > >>>>>> being told something about the state of the other > party. Perhaps this > >>>>>> should be replaced by something about the state of the > party sending > >>>>>> the > >>>>>> message. E.g. > >>>>>> > >>>>>> urn:alert:state: > >>>>>> > >>>>>> - unknown > >>>>>> - waiting (in a request, means the caller is waiting > >>>>>> for the call to complete. The normal case.) > >>>>>> - on-a-call (in a response, means the called party > >>>>>> is on another call - the call waiting case. > >>>>>> But could apply to a caller as well.) > >>>>>> - away (in a request, means the call has been generated > >>>>>> automatically and the user will be summoned if/when > >>>>>> the call completes. This is the converse of waiting) > >>>>>> > >>>>>> (This "state" is really a form of presence. Whether > its good to encode > >>>>>> it here, rather than actually transmitting pidf, is an > interesting > >>>>>> question.) > >>>>>> > >>>>>> How all of this might be mapped onto actual renderings > is probably not > >>>>>> something that should be standardized, but it might be > worth including > >>>>>> some possibilities as examples. One that comes to mind is: > >>>>>> > >>>>>> (Assuming all rendering are audio): > >>>>>> > >>>>>> - the device has a set of possible clips it can render > >>>>>> - each is attributed with the values it matches for each > >>>>>> category above. (none, one, several, or all for each > >>>>>> category.) > >>>>>> > >>>>>> The device just finds the maximal match and renders that one. > >>>>>> > >>>>>> This might be augmented if there are different sorts > of renderings - > >>>>>> e.g. audio, visual, tactile (vibrarion). In that case > it might seek > >>>>>> out > >>>>>> a match for each sort and render them all. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> > >>>> > >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Fri Apr 9 08:00:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5613428C0F3 for ; Fri, 9 Apr 2010 08:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLBa-imEgkHP for ; Fri, 9 Apr 2010 08:00:51 -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 968403A67A7 for ; Fri, 9 Apr 2010 08:00:50 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ7dvkutJV2a/2dsb2JhbACbPHGheJkzgk4BDYItBA X-IronPort-AV: E=Sophos;i="4.52,178,1270425600"; d="scan'208";a="100258878" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2010 15:00:45 +0000 Received: from [161.44.182.95] (dhcp-161-44-182-95.cisco.com [161.44.182.95]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o39F0iG7017268; Fri, 9 Apr 2010 15:00:45 GMT Message-ID: <4BBF4117.5030906@cisco.com> Date: Fri, 09 Apr 2010 11:00:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> <4BAC15AB.8090308@cisco.com> <4bb4b76f.04c2f10a.32b2.ffff9deb@mx.google.com> <4BB4E8D0.4030407@cisco.com> <4BBB4171.2010801@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" , Laura Liess Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.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, 09 Apr 2010 15:00:53 -0000 Elwell, John wrote: > This sounds like quite a comprehensive proposal. Perhaps it would benefit from a little more being said on the handling of unknown or unsupported values, and whether implementations are free to ignore categories not of interest. But that can wait until we have a draft. My opinion on this is that the receiving UA is free to ignore any values it doesn't understand or simply prefers to ignore. Its all advisory. Thanks, Paul > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Laura Liess >> Sent: 08 April 2010 14:50 >> To: Paul Kyzivat >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] FW: I-D >> Action:draft-liess-dispatch-alert-info-urns-01.txt >> >> Paul, >> >> I seems to me that we reached a consensus :-). I hope I understood >> correctly all your comments. Just to avoid some possible >> misunderstandings, I would like to write down my understanding of what >> we agreed on: >> >> >> >> alert-category = "service" / "priority" / "source" / >> "duration" / "delay" / "locale" / >> extension-category >> extension-category = token >> >> The categories are orthogonal. Any Alert-Info URN defined in this >> specification is syntacticaly valid for ring and for ringback and can >> be used in an INVITE or in a 18x response. >> There can be at most one instance of each alert-category in an >> Alert-Info header. In principle any combination of Alert-Info URNs >> with different "alert-category" is valid and can be used for either >> ring or ringback, though some combinations may not make sense. >> The receiving UA should make the decision about what to render to the >> user and what device it is rendered on depending on the value of the >> Alert-Info URN and the kind of the received message (INVITE or >> 18x-response). Typically, the same UA will do the rendering of a >> particular Alert-Info URN received in an INVITE differently from the >> rendering of the same Alert-Info URN received in a 18x response. >> >> The exact way in which the various categories are combined for >> rendering is left as an implementation issue. The implementation is >> free to ignore any or all received Alert-Info URNs. >> >> >> Values for alert-indications: >> >> urn:alert:service: >> >> - normal (default) >> - call-waiting >> - forward >> - recall.callback >> - recall.hold >> - recall.transfer >> - private. >> >> urn:alert:priority: >> >> - normal (default) >> - low >> - high >> - private. >> >> urn:alert:source: >> >> - unclassified (default) >> - internal >> - external >> - friend >> - family >> - private. >> >> urn:alert:duration: >> >> - normal (default) >> - short (or "zip") **/ Comment on this: We should check this with >> Alan, but I think "short" >> - long >> - private. >> >> urn:alert:delay: >> >> - none (default) >> - yes >> - private. >> >> urn:alert:locale: >> >> - default (default) >> - country. >> - private. >> >> The "private." syntax is for extensions specific to >> independent organizations. The is in the form of a >> "reverse FQDN" such as is used for Java package names. This gives a >> way of assigning unique names without the need for a new registry. The >> namespace for each alert category is independent. Those assigning new >> names must ensure they are in a position to assign names uniquely for >> the FQDN they choose. >> >> For example, Cisco might want to define: >> >> urn:alert:source:private.com.cisco.customer >> >> Adding new categories and adding alert-indication values other than >> via the "private" mechanism is standards action. >> >> Is this OK ? >> >> >> Thanks a lot >> Laura >> >> >> >> 2010/4/6 Paul Kyzivat : >>> Laura - responses inline. >>> >>> Laura Liess wrote: >>>> Paul, >>>> >>>> >>>>> I had proposed just clumping those together into a single >> category (which >>>>> I >>>>> called reason): >>>>> >>>>> urn:alert:reason: >>>>> >>>>> - normal (default) (ring & ringback) >>>>> - call-waiting ( ringback) >>>>> - forward (ring & ringback) >>>>> - auto-callback (ring & ringback) >>>>> - recall.hold (ring & ringback) >>>>> - recall.transfer (ring & ringback) >>>>> - private. (ring & ringback) >>>>> >>>>> My logic above is: >>>>> >>>>> - whether this applies to ring or ringback depends on context >>>>> (the message it is in) so doesn't have to be part of the naming. >>>>> Making this part of the naming just introduces another sort of >>>>> error to deal with. ("reason" can only be used in requests, while >>>>> "service" can only be used in responses.) >>>>> Is there a strong reason partition things that way? >>>> I think the proposal to separate urns for ring and ringback came up >>>> some months before, either on the mailing list or in some >> discussion >>>> at the IETF, in connection with the urn combinations problem. I am >>>> fine with your proposal. In principle, also the call-waiting >>>> indication can be sent to caller and callee. We probably have to >>>> include a statement in the draft that the receiving UA >> should make the >>>> decision about what to render to the user depending on oth >> the value >>>> of the Alert-Info URN and the kind of message it received >> (INVITE or >>>> 18x-response). >>> Yes, that makes sense. Also, *what* is rendered, and what >> device it is >>> rendered on, will typically vary depending on this >> distinction. (The headset >>> vs. the ringer or speaker.) That should all be mentioned. >>> >>>> The only problem I have here is the naming. Personally, I >> would prefer >>>> to name the whole category you described above as "service", for >>>> folowing reasons: >>>> - "reason" is somehow to broad. In principle, it easily may happen >>>> that people add to this category also other >> "reason"-indications which >>>> have nothing to do with services and are orthogonal to the >> indications >>>> we have now in this category. But as a combination rule, >> we would like >>>> to have no more than one urn from same category. The name "service" >>>> would be more restrictive. >>>> - All items of this category indicate that some service >> was initiated. >>>> - Implementors, testers, operating guys are more familiar with >>>> call-waiting, forward or transfer as being a service than being a >>>> reason. >>> I am not very attached to the name "reason". While I'm not >> fond of the name >>> "service", I don't strongly object to it either, and if >> that is an important >>> choice for you I can accept it. >>> >>>> But if this name is not at acceptable for you, I would >> like at least >>>> to come back to your proposal in your mail from April 1 and treat >>>> "call-waiting" as a separate "service" category. >>> I can especially accept "service" if it means all these >> things are in the >>> same category. >>> >>>>> - for many (but perhaps not all) it might be useful in both >>>>> directions, though the particular alert used would differ. >>>>> >>>>> For instance, its useful to inform both the holder and >> the holdee of a >>>>> hold-recall. >>>>> >>>>> (Note that I also changed the naming to recall.hold and >> recall.transfer >>>>> because the are both "recall" functions, and it might be >> convenient for >>>>> some >>>>> devices to alert them both the same. I'm still debating >> with myself >>>>> whether >>>>> auto-callback should be recall.auto.) >>>> This makes sense to me. (I just used the old names in my >> mail.) Only >>>> I would choose recall.callback instead of recall.auto. I >> think it is >>>> more intuitive. >>> Sounds good to me. >>> >>> Thanks, >>> Paul >>> >>>> Thanks a lot >>>> Laura >>>> >>>> >>>> 2010/4/1 Paul Kyzivat : >>>>> Laura Liess wrote: >>>>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> How to name things is a second order issue. If its just >> a matter of >>>>>>> "service" vs. "reason" then I don't care very much. >> (I'm not especially >>>>>>> attached to "reason", but I also find "service" >> somewhat confusing for >>>>>>> the purpose.) >>>>>>> >>>>>>> The orthogonality is more important. The way I >> partitioned the data is >>>>>>> just a first cut, and I'm entirely open to alternative >> ways of doing >>>>>>> that. But I would hate to see the categorization warped >> just to fit one >>>>>>> preexisting use. IMO it would make more sense to >> special-case that one >>>>>>> - >>>>>>> perhaps treat it as a separate category of its own. >>>>>> I agree. I went through the items we currently have in >> the category >>>>>> "service" (or "reason"). We have there "transfer-recall", >>>>>> "auto-callback" >>>>>> and "hold-recall", which are sent in an INVITE and >> indicate to the >>>>>> callee >>>>>> the "reason" for the incoming call. We could put them in >> the "reason" >>>>>> category. We also have "call-waiting" and "forward", >> which are sent in >>>>>> an >>>>>> 180 Ringing and indicate to the caller that some network >> service was >>>>>> applied >>>>>> to the call at the calee's side. We could put them in >> the "service" >>>>>> category. >>>>>> Would this partitioning suit your vision ? >>>>> I had proposed just clumping those together into a single >> category (which >>>>> I >>>>> called reason): >>>>> >>>>> urn:alert:reason: >>>>> >>>>> - normal (default) (ring & ringback) >>>>> - call-waiting ( ringback) >>>>> - forward (ring & ringback) >>>>> - auto-callback (ring & ringback) >>>>> - recall.hold (ring & ringback) >>>>> - recall.transfer (ring & ringback) >>>>> - private. (ring & ringback) >>>>> >>>>> My logic above is: >>>>> >>>>> - whether this applies to ring or ringback depends on context >>>>> (the message it is in) so doesn't have to be part of the naming. >>>>> Making this part of the naming just introduces another sort of >>>>> error to deal with. ("reason" can only be used in requests, while >>>>> "service" can only be used in responses.) >>>>> Is there a strong reason partition things that way? >>>>> >>>>> - for many (but perhaps not all) it might be useful in both >>>>> directions, though the particular alert used would differ. >>>>> >>>>> For instance, its useful to inform both the holder and >> the holdee of a >>>>> hold-recall. >>>>> >>>>> (Note that I also changed the naming to recall.hold and >> recall.transfer >>>>> because the are both "recall" functions, and it might be >> convenient for >>>>> some >>>>> devices to alert them both the same. I'm still debating >> with myself >>>>> whether >>>>> auto-callback should be recall.auto.) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Thanks a lot >>>>>> Laura >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Thanks a lot >>>>>>>> Laura >>>>>>>> >>>>>>>> >>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> Gesendet: Donnerstag, 25. März 2010 19:51 >>>>>>>> An: Laura Liess >>>>>>>> Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; >> Liess Laura; Gerold >>>>>> Pinker >>>>>>>> Betreff: Re: [dispatch] FW: I-D >>>>>>>> Action:draft-liess-dispatch-alert-info-urns-01.txt >>>>>>>> >>>>>>>> I've been thinking about how the "namespace" of >> alert-info URNs might >>>>>>>> be >>>>>>>> reorganized. My goals in doing so are: >>>>>>>> - allow the different "aspects" of the alert to be specified >>>>>>>> - make it clear what the combination rules are for these >>>>>>>> - allow for comparable expressiveness for rings and ringbacks >>>>>>>> - provide room for extension >>>>>>>> >>>>>>>> The following is a rough outline of a what I have in mind: >>>>>>>> >>>>>>>> The urn syntax is as in the current draft, *except*: >>>>>>>> >>>>>>>> alert-category = "reason" / "priority" / "source" / >>>>>>>> "duration" / "delay" / "locale" / >>>>>>>> extension-category >>>>>>>> extension-category = token >>>>>>>> >>>>>>>> The principle for choosing these categories is that they are >>>>>>>> orthogonal. >>>>>>>> Hence there is a single rule for well-formedness of Alert-Info: >>>>>>>> there can be at most one instance of each >> alert-category, and in >>>>>>>> principle any such combination is valid. (Though some >> may be silly or >>>>>>>> uninteresting.) >>>>>>>> >>>>>>>> The above doesn't distinguish ring from ringback. That is to be >>>>>>>> determined from context - when present in a request it >> describes the >>>>>>>> ring. When present in a response it describes the >> ringback. Again, in >>>>>>>> principle any combination can be used for either ring >> or ringback, >>>>>>>> though some combinations may be silly or uninteresting. >>>>>>>> >>>>>>>> The exact way in which the various categories are combined for >>>>>>>> rendering >>>>>>>> is left as an implementation issue. The implementation >> is free to >>>>>>>> ignore >>>>>>>> any or all at its whim. >>>>>>>> >>>>>>>> Its my intent that things previously discussed in the >> draft can all be >>>>>>>> mapped onto these categories. Here is my swag at doing so: >>>>>>>> >>>>>>>> urn:alert:reason: >>>>>>>> >>>>>>>> - normal (default) >>>>>>>> - call-waiting >>>>>>>> - forward >>>>>>>> - auto-callback >>>>>>>> - recall.hold >>>>>>>> - recall.transfer >>>>>>>> - private. >>>>>>>> >>>>>>>> urn:alert:priority: >>>>>>>> >>>>>>>> - normal (default) >>>>>>>> - low >>>>>>>> - high >>>>>>>> - crisis >>>>>>>> - private. >>>>>>>> >>>>>>>> urn:alert:source: >>>>>>>> >>>>>>>> - unclassified (default) >>>>>>>> - internal >>>>>>>> - external >>>>>>>> - friend >>>>>>>> - family >>>>>>>> - private. >>>>>>>> >>>>>>>> urn:alert:duration: >>>>>>>> >>>>>>>> - normal (default) >>>>>>>> - short (or could be "zip") >>>>>>>> - long (for completeness, or omit if unneeded) >>>>>>>> - private. >>>>>>>> >>>>>>>> urn:alert:delay: >>>>>>>> >>>>>>>> - none (default) >>>>>>>> - yes (not sure what to put here) >>>>>>>> - private. >>>>>>>> >>>>>>>> urn:alert:locale: >>>>>>>> >>>>>>>> - default (default) >>>>>>>> - country. >>>>>>>> - private. >>>>>>>> >>>>>>>> In the above the "private." syntax is >> for extensions >>>>>>>> specific to independent organizations. The >> is in the >>>>>>>> form >>>>>>>> of a "reverse FQDN" such as is used for Java package >> names. This gives >>>>>>>> a >>>>>>>> way of assigning unique names without the need for a >> new registry. The >>>>>>>> namespace for each alert category is independent. >> Those assigning new >>>>>>>> names must ensure they are in a position to assign >> names uniquely for >>>>>>>> the FQDN they choose. >>>>>>>> >>>>>>>> (I have considerable reservation about introducing such an >>>>>>>> uncontrolled >>>>>>>> extension mechanism. I see how it can provide a lot of >> flexibility in >>>>>>>> providing tailored user experiences. But it can also >> lead to vendor >>>>>>>> lock >>>>>>>> in if a device is only capable of supporting a >> particular vendor's >>>>>>>> specific extensions. So I think this needs a lot of >> discussion.) >>>>>>>> For example, I might want to define: >>>>>>>> >>>>>>>> urn:alert:source:private.com.cisco.customer >>>>>>>> >>>>>>>> If I were to do so, I should first ensure that I speak >> for cisco.com >>>>>>>> when coining this. >>>>>>>> >>>>>>>> Additions to the values above other than via the >> "private" mechanism >>>>>>>> would be by standards action. The same for adding new >> categories. >>>>>>>> (There could be a "private" mechanism for categories >> too. But I'm not >>>>>>>> at >>>>>>>> all confident that is a good thing.) >>>>>>>> >>>>>>>> I'm not quite sure about "call-waiting" as a "reason" >> - it doesn't >>>>>>>> seem >>>>>>>> quite right. The reason could still be any of those >> other things. For >>>>>>>> the ring indication its far from clear to me that it >> is needed at all >>>>>>>> - >>>>>>>> the recipient already knows it is on a call, and >> doesn't need to be >>>>>>>> told >>>>>>>> that. It may make more sense for the ringback - in >> that case you are >>>>>>>> being told something about the state of the other >> party. Perhaps this >>>>>>>> should be replaced by something about the state of the >> party sending >>>>>>>> the >>>>>>>> message. E.g. >>>>>>>> >>>>>>>> urn:alert:state: >>>>>>>> >>>>>>>> - unknown >>>>>>>> - waiting (in a request, means the caller is waiting >>>>>>>> for the call to complete. The normal case.) >>>>>>>> - on-a-call (in a response, means the called party >>>>>>>> is on another call - the call waiting case. >>>>>>>> But could apply to a caller as well.) >>>>>>>> - away (in a request, means the call has been generated >>>>>>>> automatically and the user will be summoned if/when >>>>>>>> the call completes. This is the converse of waiting) >>>>>>>> >>>>>>>> (This "state" is really a form of presence. Whether >> its good to encode >>>>>>>> it here, rather than actually transmitting pidf, is an >> interesting >>>>>>>> question.) >>>>>>>> >>>>>>>> How all of this might be mapped onto actual renderings >> is probably not >>>>>>>> something that should be standardized, but it might be >> worth including >>>>>>>> some possibilities as examples. One that comes to mind is: >>>>>>>> >>>>>>>> (Assuming all rendering are audio): >>>>>>>> >>>>>>>> - the device has a set of possible clips it can render >>>>>>>> - each is attributed with the values it matches for each >>>>>>>> category above. (none, one, several, or all for each >>>>>>>> category.) >>>>>>>> >>>>>>>> The device just finds the maximal match and renders that one. >>>>>>>> >>>>>>>> This might be augmented if there are different sorts >> of renderings - >>>>>>>> e.g. audio, visual, tactile (vibrarion). In that case >> it might seek >>>>>>>> out >>>>>>>> a match for each sort and render them all. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From ranjit@motorola.com Mon Apr 12 22:42:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E260A28C197 for ; Mon, 12 Apr 2010 22:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 0uD7ATCqdiim for ; Mon, 12 Apr 2010 22:42:44 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 7569D28C1B8 for ; Mon, 12 Apr 2010 22:42:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1271137357!102324524!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 11887 invoked from network); 13 Apr 2010 05:42:38 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-8.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2010 05:42:38 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o3D5gbId023893 for ; Mon, 12 Apr 2010 22:42:37 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o3D5gbGO027459 for ; Tue, 13 Apr 2010 00:42:37 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o3D5gZxF027446 for ; Tue, 13 Apr 2010 00:42:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 13:42:13 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A44D0DE@ZMY16EXM66.ds.mot.com> In-Reply-To: <4BBA481E.7050608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Expert review ofdraft-avasarala-dispatch-comm-div-notification-04 thread-index: AcrU/yWivt8AlIUZSservGaXGogm/AFy9ceg References: <4B72716A.90006@ericsson.com> <4B72BC3D.20701@cisco.com><4B72BE4A.6030508@ericsson.com> <4BBA481E.7050608@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" , "Mary Barnes" , "Cullen Jennings" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] Expert review ofdraft-avasarala-dispatch-comm-div-notification-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, 13 Apr 2010 05:42:48 -0000 Hi Paul My comments .=20 Updated -05 version: http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-05 .txt Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, April 06, 2010 1:59 AM To: Mary Barnes; Cullen Jennings Cc: dispatch@ietf.org Subject: [dispatch] Expert review ofdraft-avasarala-dispatch-comm-div-notification-04 I was asked to be expert reviewer for this document. I earlier reviewed version -03, and this is an updated review of -04. Some of the issues I raised previously have been resolved, but not all. RFC 5727 calls for me to judge it just like a standards track document, and doing so leads to most of the remaining issues. I don't think I have raised any fundamentally new issues since the previous pass, though I have tried to restate the remaining ones in context of the new document and the intermediate discussions we have had. I continue to think this is mostly a matter of getting the text right, rather than altering the fundamental aspects of the proposed package.=20 Mostly this is a matter of insufficient text, leaving many ambiguities. Thanks, Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D I was requested to do an expert review of draft-avasarala-dispatch-comm-div-notification-04.txt > 1. A Designated Expert (as defined in RFC5226) must review the > proposal for applicability to SIP and conformance with these > guidelines. The Designated Expert will send email to the IESG on > this determination. The expert reviewer can cite one or more of > the guidelines that have not been followed in his/her opinion. I'm doing that below. > 2. The proposed extension MUST NOT define an event template-package. It does not. > 3. The function of the proposed package MUST NOT overlap with > current or planned chartered packages. I am aware of no chartered work on this subject. The draft itself has been debated at length on the dispatch wg mailing list, but with a relatively small number of people actively involved. Some, including me, have stated that a service resembling the one proposed might be of general utility. But there have been no volunteers to do the work of generalizing this. So I conclude that there are currently no plans for chartered work on such a package. > 4. The event package MUST NOT redefine or contradict the normative > behavior of SIP events [RFC3265], SIP [RFC3261], or related > standards track extensions. (See Section 4) I did not identify any issues in this regard. > 5. The proposed package MUST NOT undermine SIP security in any > sense. The Internet Draft proposing the new package MUST address > security issues in detail as if it were a Standards Track > document. Security issues need to be discussed for arbitrary > usage scenarios (including the general Internet case). The document identifies the specific security issues presented by this package. It specifies that authentication and authorization must be done, but leaves the means for authorization out of scope. While a bit thin, this may be sufficient for the area of applicability. > 6. The proposed package MUST be clearly documented in an > (Individual) Informational RFC, and registered with IANA.=20 The document under review will satisfy this requirement. > The package MUST document all the package considerations required > in Section 4 of SIP events [RFC3265]. I will comment on the individual parts of section 4 below: > 4.1. Appropriateness of Usage In my opinion this is an entirely appropriate use of sip and event packages. > 4.2. Event Template-packages N/A - template package not defined. > 4.3. Amount of State to be Conveyed > 4.3.1. Complete State Information > 4.3.2. State Deltas This version of the document is improved - it now discusses the retention of state about some number of past diversions. But it does not discuss *what* state information is captured from a diversion. This is *implied* by the specification of the xml document that conveys this information in NOTIFY requests. This is tenuous. There should be an explicit specification of the state maintained, and how it is mapped onto the notification body. There is no normative requirement to include this information in the document, so I can't insist on it. But without this, it will be difficult to adequately address Notifier generation of NOTIFY requests. . I have added 2 attributes (1) Number of communication diversions that occurred till time - N (2) Number of communication diversion notifications sent to the user till time - M. Both these attributes would be maintained as part of state information and would be updated whenever a diversion occurs and a notification is sent. These attributes get computed every time a diversion occurs and before sending the notification information.=20 > 4.4. Event Package Responsibilities > 4.4.1. Event Package Name OK. > 4.4.2. Event Package Parameters OK. > 4.4.3. SUBSCRIBE Bodies ISSUE: The schema for the body type allows parts of types and . It appears that only should appear in a SUBSCRIBE request, but this is not specified. There should either be text specifying that this part must not be present, or else text explaining what is to happen if it is present. . Updated the section in -05 version. > 4.4.4. Subscription Duration >=20 > It is RECOMMENDED that event packages give a suggested range of times > considered reasonable for the duration of a subscription. Such > packages MUST also define a default "Expires" value to be used if > none is specified. OK. > 4.4.5. NOTIFY Bodies ISSUE: The schema for the body type allows parts of types and . It appears that only should appear in a NOTIFY request, but this is not specified. There should either be text specifying that this part must not be present, or else text explaining its significance in a NOTIFY. . Updated in -05 version of the document. > 4.4.6. Notifier processing of SUBSCRIBE requests ISSUE: There is no text stating that the notifier must retain the information from the body of the subscribe for use in generation of NOTIFY requests. Since that is certainly required, it should be stated. ISSUE: There is no specification of what to do if the subscribe body contains . If that's valid, then the behavior should be specified. If its not valid, that should have been specified in 4.4.3. . Updated the information in -05 version. > 4.4.7. Notifier generation of NOTIFY requests > > This section of an event package describes the process by which the > notifier generates and sends a NOTIFY request. This includes > detailed information about what events cause a NOTIFY to be sent, ISSUE: the triggers for sending NOTIFY are imprecisely specified. This is *partially* covered, in that it it states that a NOTIFY will "typically" be sent when "a communication diversion is enacted on behalf of the user", but the atypical situation is not discussed. There is also "A notifier MAY send a NOTIFY at any time", which appears to be inappropriate - apparently the only other time to send such a notification is immediately following a SUBSCRIBE request. ISSUE: There is no discussion of how the body from the SUBSCRIBE request affects the decision about when to send NOTIFY requests. This is too under-specified to be considered complete. . Updated in -05 version. What I would expect to see here is, roughly: - when a new (or refresh) SUBSCRIBE is received, compute the state information in the notify (see below), and send regardless of whether it is empty or not. - when a communication diversion occurs, selected attributes (TBS) of the diverted message and the diversion itself are captured and saved as new diversion state. - the addition of this new state may (or may not) result in discarding some old state. (Details TBS, related to the value N.) - for each subscriber, compute the state information in the notify (see below). If the resulting body is non-empty, send the NOTIFY. If empty, do not send the notify. > how to compute the state information in the NOTIFY, ISSUE: I don't find this information anywhere. While an implementor may attempt to infer it from the descriptions of the subscribe and notify bodies, that doesn't constitute a specification. ISSUE: The subscribe body is intended to be used as a filter on which events/state are reported. The subscribe body contains data to be used in the filtering process, but the decision process for filtering is not specified. For instance, both a User-name and a User-URI may be provided. It is implied, rather than stated, that the User-name field is matched against the user portion of some URI, whereas the User-URI field is matched against a complete URI. Also, there are a variety of field types, and no indication how matches of multiple fields are combined. (I.e. AND or OR.) I would expect to see a description of how the content of the subscribe body is applied to the saved diversion state to format a notify body.=20 Also, how to construct the notify body if there is no subscribe body. Also, the representation of an "empty" body when there is no saved diversion state or the subscribe body results in all of the saved information being withheld from the subscriber. > how to generate > neutral or fake state information to hide authorization delays and > decisions from users, and whether state information is complete or > deltas for notifications; see section 4.3. Such a section is > required. ISSUE: This is not discussed. . Updated in -05 version AFAICT, there is no need for fake information - this can simply be stated. Neutral information is presumably what is sent in a NOTIFY when there is no saved diversion state, or all saved state is filtered out by the subscribe body. Apparently the intent in that case is for a NOTIFY with no body. That should be made clear. > 4.4.8. Subscriber processing of NOTIFY requests This section is very thin - it specifies nothing. But if you want to leave this undefined I won't object, because there appear to be no normative requirements. > 4.4.9. Handling of forked requests OK, not permitted. > 4.4.10. Rate of notifications OK - specified. > 4.4.11. State Agents Its my understanding that this event package is not intended to employ state agents (as that term is defined in RFC 3265). Hence this section should simply state that state agents are not used. > 4.4.12. Examples The only provided example is a sample of a notification body. Flow diagrams and message detail, as called out in 3265, would be very useful. Specifically, this document would be improved if it included examples of at least: - initial subscribe when there have been no diversions - the occurrence of a diversion and the resulting notification to existing subscribers. - another subscription by another subscriber while there is retained state from a prior diversion, and the resulting notification(s). - another diversion occurrence, its impact on saved state, and on what the existing subscribers receive as notifications. - a subscription with a filter that screens out some but not all of the diversions in the saved state. Having such examples might have shortened the discussion of this draft significantly. But this is not mandatory according to 3265, so I cannot require that you provide it. NIT: Section 8.2 is entitled "Sample Notification Body", but it contains subsections entitled "Instance of communication diversion subscription document" and "Instance of communication diversion notification document". While the latter would be a notification body, the former would presumably be a subscription body. I suggest you rename the section to be more clear. . Updated in -05 version > 4.4.13. Use of URIs to Retrieve State OK - not used. > 7. If determined by the Designated Expert or the chairs or ADs of > the DISPATCH WG, an applicability statement in the Informational > RFC MUST clearly document the useful scope of the proposal, and > explain its limitations and why it is not suitable for the > general use of SIP in the Internet. The Applicability Statement in the document adequately documents the scope. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From rjsparks@nostrum.com Fri Apr 16 08:57:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FEA3A6817; Fri, 16 Apr 2010 08:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_40=-0.185, 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 STRZ-sUVnTmw; Fri, 16 Apr 2010 08:57:07 -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 633A53A69EA; Fri, 16 Apr 2010 08:57:04 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-51-142.dllstx.fios.verizon.net [173.71.51.142]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3GFupGr024146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Apr 2010 10:56:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <4BB5409E.5080108@alcatel-lucent.com> Date: Fri, 16 Apr 2010 10:56:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> To: Volker Hilt X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 173.71.51.142 is authenticated by a trusted mechanism) Cc: DISPATCH , "sip-overload@ietf.org" , Lars Eggert Subject: Re: [dispatch] Proposed SIP Overload Control 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, 16 Apr 2010 15:57:08 -0000 I have made some tweaks based on the list discussion and conversations = with IESG members. This is my current working text. Please comment if you disagree with the = changes I've made. The changes are in the description of overload in the first paragraph, = changing the term throughput=20 to goodput, and clarifying the discussion of scope and limitations. I've = also added some strawman milestones. Please comment on those dates. SIP Overload Control WG Charter ------------------------------- As with any network element, a Session Initiation Protocol (SIP) 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 complete the processing of all incoming SIP messages within the required time. These resources can include CPU, memory, network bandwidth, = input/output,=20 or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the goodput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate 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 fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be = split into overload control between a user agent and a SIP server and overload = control between SIP servers.=20 Any specification developed by the working group needs to clearly = specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may = have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms = and discuss, for example, when a mechanism requires coordinated deployment = and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some = conditions, or especially if there are cases when a mechanism can reduce goodput = compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their = particular networks. The working group will consider two complementary approaches for=20 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. The 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. Milestones: Sep 2010 Design Considerations to IESG for publication as Informational Dec 2010 Specification for a SIP overload control mechanism based on = implicit/explicit feedback to IESG for publication as Proposed Standard May 2011 Specification for a SIP load filtering mechaism to IESG for = publication as Proposed Standard On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote: > All, >=20 > below is an updated charter proposal for a SIP Overload Control WG. It = has additional text that specifications developed by the proposed WG = need to define scope and limitations (see below). >=20 > Thanks, >=20 > Volker >=20 >=20 >=20 > SIP Overload Control WG Charter > ------------------------------- >=20 > As with any network element, a Session Initiation Protocol (SIP) = 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. >=20 > 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 zero or a small fraction of the > original processing capacity. This is often called congestion = collapse. >=20 > The objective of a SIP overload control mechanism is to enable SIP > servers to operate close to their capacity limit during times of = overload. >=20 > 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 fully prevent overload of a = SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and 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. >=20 > The objective of the proposed working group is to develop mechanisms = for > SIP overload control. The problem domain of SIP overload control can = be split into i) overload control between a user agent and a SIP server = and overload control between SIP servers. A specification developed by = the proposed working group needs to clearly specify its scope. A = specification also needs to clearly state any limitations in performance = or otherwise the proposed overload control mechanism may have. >=20 > 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. >=20 > 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. >=20 >=20 From jgunn6@csc.com Fri Apr 16 09:43:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7593C28C100; Fri, 16 Apr 2010 09:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.474, 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 Ohu6Z-F4pVIF; Fri, 16 Apr 2010 09:43:11 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id A21333A693E; Fri, 16 Apr 2010 09:43:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-171.messagelabs.com!1271436178!17991221!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 2853 invoked from network); 16 Apr 2010 16:42:59 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-6.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Apr 2010 16:42:59 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id o3GGgvLx004174; Fri, 16 Apr 2010 12:42:58 -0400 In-Reply-To: <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> To: Robert Sparks MIME-Version: 1.0 X-KeepSent: 77234340:6D07CD75-85257707:005B114B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 16 Apr 2010 12:42:54 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/16/2010 12:43:44 PM, Serialize complete at 04/16/2010 12:43:44 PM Content-Type: multipart/alternative; boundary="=_alternative 005BD65F85257707_=" X-Mailman-Approved-At: Fri, 16 Apr 2010 09:50:18 -0700 Cc: sip-overload-bounces@ietf.org, pat_mcgregor@msn.com, DISPATCH , "sip-overload@ietf.org" , Richard F Kaczmarek , Lars Eggert , Volker Hilt Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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, 16 Apr 2010 16:43:13 -0000 This is a multipart message in MIME format. --=_alternative 005BD65F85257707_= Content-Type: text/plain; charset="US-ASCII" I know I said it before, but I am going to say it again. First, the "second mechanism" should explicitly mention filtering based on SOURCE "domain, telephone number prefix or specific user", not just DESTINATION. Second, I would like to see an explicit statement that the work will be consistent with the requirements in RFC 5390. Thanks Janet sip-overload-bounces@ietf.org wrote on 04/16/2010 11:56:51 AM: > [image removed] > > Re: [sip-overload] Proposed SIP Overload Control Charter > > Robert Sparks > > to: > > Volker Hilt > > 04/16/2010 11:57 AM > > Sent by: > > sip-overload-bounces@ietf.org > > Cc: > > DISPATCH, "sip-overload@ietf.org", Gonzalo Camarillo, Lars Eggert > > I have made some tweaks based on the list discussion and > conversations with IESG members. > This is my current working text. Please comment if you disagree with > the changes I've made. > > The changes are in the description of overload in the first > paragraph, changing the term throughput > to goodput, and clarifying the discussion of scope and limitations. > I've also added some strawman > milestones. Please comment on those dates. > > SIP Overload Control WG Charter > ------------------------------- > > As with any network element, a Session Initiation Protocol (SIP) 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 complete the > processing of all incoming SIP messages within the required time. > 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 goodput of a network of SIP servers can be > significantly degraded. In fact, overload may lead to a situation in > which the goodput drops down to zero or a small fraction of the > original processing capacity. This is often called congestion collapse. > > The objective of a SIP overload control mechanism is to enable SIP > servers to operate 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 fully prevent overload of a SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP > overload control. The problem domain of SIP overload control can be split into > overload control between a user agent and a SIP server and overload control > between SIP servers. > > Any specification developed by the working group needs to clearly specify its > scope. A specification also needs to clearly state any limitations, in > performance or otherwise, the specified overload control mechanism > may have. In > particular, the working group shall carefully define the deployment > considerations for the effective operation of the specified mechanisms and > discuss, for example, when a mechanism requires coordinated deployment and > operation (if all servers need to deploy the same mechanism, certain > configuration values need to be identical on all servers, etc), when a > mechanism can become less effective or ineffective under some conditions, or > especially if there are cases when a mechanism can reduce goodput compared to > no overload protection. The intent of these considerations is to allow > potential deployers to make the best use of these mechanism in theirparticular > networks. > > The working group will consider two complementary approaches 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. > > The 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. > > Milestones: > > Sep 2010 Design Considerations to IESG for publication as Informational > Dec 2010 Specification for a SIP overload control mechanism based on > implicit/explicit feedback to IESG for publication as Proposed Standard > May 2011 Specification for a SIP load filtering mechaism to IESG for > publication as Proposed Standard > > > On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote: > > > All, > > > > below is an updated charter proposal for a SIP Overload Control > WG. It has additional text that specifications developed by the > proposed WG need to define scope and limitations (see below). > > > > Thanks, > > > > Volker > > > > > > > > SIP Overload Control WG Charter > > ------------------------------- > > > > As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the > > original processing capacity. This is often called congestion collapse. > > > > The objective of a SIP overload control mechanism is to enable SIP > > servers to operate 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 fully prevent overload of a SIP > > server and it cannot prevent congestion collapse. In fact, its on/off > > behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control > can be split into i) overload control between a user agent and a SIP > server and overload control between SIP servers. A specification > developed by the proposed working group needs to clearly specify its > scope. A specification also needs to clearly state any limitations > in performance or otherwise the proposed overload control mechanism may have. > > > > 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. > > > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 005BD65F85257707_= Content-Type: text/html; charset="US-ASCII"

I know I said it before, but I am going to say it again.

First, the "second mechanism" should explicitly mention filtering based on SOURCE "domain, telephone number prefix or specific user", not just DESTINATION.

Second, I would like to see an explicit statement that the work will be consistent with the requirements in RFC 5390.

Thanks

Janet


sip-overload-bounces@ietf.org wrote on 04/16/2010 11:56:51 AM:

> [image removed]
>
> Re: [sip-overload] Proposed SIP Overload Control Charter
>
> Robert Sparks
>
> to:
>
> Volker Hilt
>
> 04/16/2010 11:57 AM
>
> Sent by:
>
> sip-overload-bounces@ietf.org
>
> Cc:
>
> DISPATCH, "sip-overload@ietf.org", Gonzalo Camarillo, Lars Eggert
>
> I have made some tweaks based on the list discussion and
> conversations with IESG members.
> This is my current working text. Please comment if you disagree with
> the changes I've made.
>
> The changes are in the description of overload in the first
> paragraph, changing the term throughput
> to goodput, and clarifying the discussion of scope and limitations.
> I've also added some strawman
> milestones. Please comment on those dates.
>
> SIP Overload Control WG Charter
> -------------------------------
>
> As with any network element, a Session Initiation Protocol (SIP) 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 complete the
> processing of all incoming SIP messages within the required time.
> 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 goodput of a network of SIP servers can be
> significantly degraded.  In fact, overload may lead to a situation in
> which the goodput drops down to zero or a small fraction of the
> original processing capacity.  This is often called congestion collapse.
>
> The objective of a SIP overload control mechanism is to enable SIP
> servers to operate 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 fully prevent overload of a SIP
> server and it cannot prevent congestion collapse.  In fact, its on/off
> behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP
> overload control. The problem domain of SIP overload control can be split into
> overload control between a user agent and a SIP server and overload control
> between SIP servers.
>
> Any specification developed by the working group needs to clearly specify its
> scope. A specification also needs to clearly state any limitations, in
> performance or otherwise, the specified overload control mechanism
> may have.  In
> particular, the working group shall carefully define the deployment
> considerations for the effective operation of the specified mechanisms and
> discuss, for example, when a mechanism requires coordinated deployment and
> operation (if all servers need to deploy the same mechanism, certain
> configuration values need to be identical on all servers, etc), when a
> mechanism can become less effective or ineffective under some conditions, or
> especially if there are cases when a mechanism can reduce goodput compared to
> no overload protection. The intent of these considerations is to allow
> potential deployers to make the best use of these mechanism in theirparticular
> networks.
>
> The working group will consider two complementary approaches 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.
>
> The 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.
>
> Milestones:
>
> Sep 2010 Design Considerations to IESG for publication as Informational
> Dec 2010 Specification for a SIP overload control mechanism based on
> implicit/explicit feedback to IESG for publication as Proposed Standard
> May 2011 Specification for a SIP load filtering mechaism to IESG for
> publication as Proposed Standard
>
>
> On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote:
>
> > All,
> >
> > below is an updated charter proposal for a SIP Overload Control
> WG. It has additional text that specifications developed by the
> proposed WG need to define scope and limitations (see below).
> >
> > Thanks,
> >
> > Volker
> >
> >
> >
> > SIP Overload Control WG Charter
> > -------------------------------
> >
> > As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the
> > original processing capacity.  This is often called congestion collapse.
> >
> > The objective of a SIP overload control mechanism is to enable SIP
> > servers to operate 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 fully prevent overload of a SIP
> > server and it cannot prevent congestion collapse.  In fact, its on/off
> > behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control
> can be split into i) overload control between a user agent and a SIP
> server and overload control between SIP servers. A specification
> developed by the proposed working group needs to clearly specify its
> scope. A specification also needs to clearly state any limitations
> in performance or otherwise the proposed overload control mechanism may have.
> >
> > 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.
> >
> >
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 005BD65F85257707_=-- From volker.hilt@alcatel-lucent.com Fri Apr 16 11:50:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240E628C0D9; Fri, 16 Apr 2010 11:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzJ49jDJeDpU; Fri, 16 Apr 2010 11:50:35 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 73DFA3A6A9D; Fri, 16 Apr 2010 11:50:35 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o3GIoPmX015162; Fri, 16 Apr 2010 13:50:25 -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 o3GIoLKC008973; Fri, 16 Apr 2010 13:50:24 -0500 (CDT) Received: from [135.112.131.79] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 16 Apr 2010 13:50:23 -0500 Message-ID: <4BC8B1CF.3000303@bell-labs.com> Date: Fri, 16 Apr 2010 14:51:59 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Robert Sparks References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> In-Reply-To: <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.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.33 Cc: DISPATCH , "sip-overload@ietf.org" , Gonzalo, Lars Eggert Subject: Re: [dispatch] Proposed SIP Overload Control 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, 16 Apr 2010 18:50:37 -0000 I think the updated charter and the milestones look good. Volker On 4/16/2010 11:56 AM, Robert Sparks wrote: > I have made some tweaks based on the list discussion and conversations with IESG members. > This is my current working text. Please comment if you disagree with the changes I've made. > > The changes are in the description of overload in the first paragraph, changing the term throughput > to goodput, and clarifying the discussion of scope and limitations. I've also added some strawman > milestones. Please comment on those dates. > > SIP Overload Control WG Charter > ------------------------------- > > As with any network element, a Session Initiation Protocol (SIP) 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 complete the > processing of all incoming SIP messages within the required time. > 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 goodput of a network of SIP servers can be > significantly degraded. In fact, overload may lead to a situation in > which the goodput drops down to zero or a small fraction of the > original processing capacity. This is often called congestion collapse. > > The objective of a SIP overload control mechanism is to enable SIP > servers to operate 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 fully prevent overload of a SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP > overload control. The problem domain of SIP overload control can be split into > overload control between a user agent and a SIP server and overload control > between SIP servers. > > Any specification developed by the working group needs to clearly specify its > scope. A specification also needs to clearly state any limitations, in > performance or otherwise, the specified overload control mechanism may have. In > particular, the working group shall carefully define the deployment > considerations for the effective operation of the specified mechanisms and > discuss, for example, when a mechanism requires coordinated deployment and > operation (if all servers need to deploy the same mechanism, certain > configuration values need to be identical on all servers, etc), when a > mechanism can become less effective or ineffective under some conditions, or > especially if there are cases when a mechanism can reduce goodput compared to > no overload protection. The intent of these considerations is to allow > potential deployers to make the best use of these mechanism in their particular > networks. > > The working group will consider two complementary approaches 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. > > The 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. > > Milestones: > > Sep 2010 Design Considerations to IESG for publication as Informational > Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard > May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard > > > On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote: > >> All, >> >> below is an updated charter proposal for a SIP Overload Control WG. It has additional text that specifications developed by the proposed WG need to define scope and limitations (see below). >> >> Thanks, >> >> Volker >> >> >> >> SIP Overload Control WG Charter >> ------------------------------- >> >> As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the >> original processing capacity. This is often called congestion collapse. >> >> The objective of a SIP overload control mechanism is to enable SIP >> servers to operate 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 fully prevent overload of a SIP >> server and it cannot prevent congestion collapse. In fact, its on/off >> behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control can be split into i) overload control between a user agent and a SIP server and overload control between SIP servers. A specification developed by the proposed working group needs to clearly specify its scope. A specification also needs to clearly state any limitations in performance or otherwise the proposed overload control mechanism may have. >> >> 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 volker.hilt@alcatel-lucent.com Fri Apr 16 12:57:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995FD3A6855; Fri, 16 Apr 2010 12:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=1.700, 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 eh7IGocMUBiW; Fri, 16 Apr 2010 12:57:05 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 9C76828C1A3; Fri, 16 Apr 2010 12:57:04 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o3GJuqOa009619; Fri, 16 Apr 2010 14:56:52 -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 o3GJupq6013016; Fri, 16 Apr 2010 14:56:52 -0500 (CDT) Received: from [135.112.131.79] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 16 Apr 2010 14:56:51 -0500 Message-ID: <4BC8C163.9070202@alcatel-lucent.com> Date: Fri, 16 Apr 2010 15:58:27 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Robert Sparks References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> In-Reply-To: <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.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.35 Cc: DISPATCH , "sip-overload@ietf.org" , Gonzalo, Lars Eggert Subject: Re: [dispatch] Proposed SIP Overload Control 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, 16 Apr 2010 19:57:06 -0000 On 4/16/2010 11:56 AM, Robert Sparks wrote: > I have made some tweaks based on the list discussion and conversations with IESG members. > This is my current working text. Please comment if you disagree with the changes I've made. > > The changes are in the description of overload in the first paragraph, changing the term throughput > to goodput, and clarifying the discussion of scope and limitations. I've also added some strawman > milestones. Please comment on those dates. > > SIP Overload Control WG Charter > ------------------------------- > > As with any network element, a Session Initiation Protocol (SIP) 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 complete the > processing of all incoming SIP messages within the required time. > 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 goodput of a network of SIP servers can be > significantly degraded. In fact, overload may lead to a situation in > which the goodput drops down to zero or a small fraction of the > original processing capacity. This is often called congestion collapse. > > The objective of a SIP overload control mechanism is to enable SIP > servers to operate 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 fully prevent overload of a SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP > overload control. The problem domain of SIP overload control can be split into > overload control between a user agent and a SIP server and overload control > between SIP servers. > > Any specification developed by the working group needs to clearly specify its > scope. A specification also needs to clearly state any limitations, in > performance or otherwise, the specified overload control mechanism may have. In > particular, the working group shall carefully define the deployment > considerations for the effective operation of the specified mechanisms and > discuss, for example, when a mechanism requires coordinated deployment and > operation (if all servers need to deploy the same mechanism, certain > configuration values need to be identical on all servers, etc), when a > mechanism can become less effective or ineffective under some conditions, or > especially if there are cases when a mechanism can reduce goodput compared to > no overload protection. The intent of these considerations is to allow > potential deployers to make the best use of these mechanism in their particular > networks. > > The working group will consider two complementary approaches 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. > > The 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. > > Milestones: > > Sep 2010 Design Considerations to IESG for publication as Informational > Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard > May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard > > > On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote: > >> All, >> >> below is an updated charter proposal for a SIP Overload Control WG. It has additional text that specifications developed by the proposed WG need to define scope and limitations (see below). >> >> Thanks, >> >> Volker >> >> >> >> SIP Overload Control WG Charter >> ------------------------------- >> >> As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the >> original processing capacity. This is often called congestion collapse. >> >> The objective of a SIP overload control mechanism is to enable SIP >> servers to operate 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 fully prevent overload of a SIP >> server and it cannot prevent congestion collapse. In fact, its on/off >> behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control can be split into i) overload control between a user agent and a SIP server and overload control between SIP servers. A specification developed by the proposed working group needs to clearly specify its scope. A specification also needs to clearly state any limitations in performance or otherwise the proposed overload control mechanism may have. >> >> 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 volker.hilt@alcatel-lucent.com Fri Apr 16 13:00:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B4A3A68AA; Fri, 16 Apr 2010 13:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.850, 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 Y2-v6c-eRXLt; Fri, 16 Apr 2010 13:00:47 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5DA893A69D0; Fri, 16 Apr 2010 13:00:47 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o3GK0acb017644; Fri, 16 Apr 2010 15:00:36 -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 o3GJxtNT015860; Fri, 16 Apr 2010 15:00:36 -0500 (CDT) Received: from [135.112.131.79] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 16 Apr 2010 15:00:36 -0500 Message-ID: <4BC8C243.3040405@alcatel-lucent.com> Date: Fri, 16 Apr 2010 16:02:11 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Robert Sparks , DISPATCH , "sip-overload@ietf.org" , Lars Eggert , Gonzalo Camarillo References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> In-Reply-To: <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.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.33 Subject: Re: [dispatch] Proposed SIP Overload Control 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, 16 Apr 2010 20:00:49 -0000 An slight update to the charter Robert has sent out to address Janet's comment. Volker SIP Overload Control WG Charter ------------------------------- As with any network element, a Session Initiation Protocol (SIP) 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 complete the processing of all incoming SIP messages within the required time. 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 goodput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate 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 fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers. Any specification developed by the working group needs to clearly specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms and discuss, for example, when a mechanism requires coordinated deployment and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some conditions, or especially if there are cases when a mechanism can reduce goodput compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their particular networks. The working group will consider two complementary approaches 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 source or 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. The 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. Milestones: Sep 2010 Design Considerations to IESG for publication as Informational Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard On 4/16/2010 11:56 AM, Robert Sparks wrote: > I have made some tweaks based on the list discussion and conversations with IESG members. > This is my current working text. Please comment if you disagree with the changes I've made. > > The changes are in the description of overload in the first paragraph, changing the term throughput > to goodput, and clarifying the discussion of scope and limitations. I've also added some strawman > milestones. Please comment on those dates. > > SIP Overload Control WG Charter > ------------------------------- > > As with any network element, a Session Initiation Protocol (SIP) 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 complete the > processing of all incoming SIP messages within the required time. > 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 goodput of a network of SIP servers can be > significantly degraded. In fact, overload may lead to a situation in > which the goodput drops down to zero or a small fraction of the > original processing capacity. This is often called congestion collapse. > > The objective of a SIP overload control mechanism is to enable SIP > servers to operate 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 fully prevent overload of a SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP > overload control. The problem domain of SIP overload control can be split into > overload control between a user agent and a SIP server and overload control > between SIP servers. > > Any specification developed by the working group needs to clearly specify its > scope. A specification also needs to clearly state any limitations, in > performance or otherwise, the specified overload control mechanism may have. In > particular, the working group shall carefully define the deployment > considerations for the effective operation of the specified mechanisms and > discuss, for example, when a mechanism requires coordinated deployment and > operation (if all servers need to deploy the same mechanism, certain > configuration values need to be identical on all servers, etc), when a > mechanism can become less effective or ineffective under some conditions, or > especially if there are cases when a mechanism can reduce goodput compared to > no overload protection. The intent of these considerations is to allow > potential deployers to make the best use of these mechanism in their particular > networks. > > The working group will consider two complementary approaches 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. > > The 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. > > Milestones: > > Sep 2010 Design Considerations to IESG for publication as Informational > Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard > May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard > > > On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote: > >> All, >> >> below is an updated charter proposal for a SIP Overload Control WG. It has additional text that specifications developed by the proposed WG need to define scope and limitations (see below). >> >> Thanks, >> >> Volker >> >> >> >> SIP Overload Control WG Charter >> ------------------------------- >> >> As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the >> original processing capacity. This is often called congestion collapse. >> >> The objective of a SIP overload control mechanism is to enable SIP >> servers to operate 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 fully prevent overload of a SIP >> server and it cannot prevent congestion collapse. In fact, its on/off >> behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control can be split into i) overload control between a user agent and a SIP server and overload control between SIP servers. A specification developed by the proposed working group needs to clearly specify its scope. A specification also needs to clearly state any limitations in performance or otherwise the proposed overload control mechanism may have. >> >> 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 jgunn6@csc.com Fri Apr 16 16:20:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26933A6A74; Fri, 16 Apr 2010 16:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.427, 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 Izly72P+8k7I; Fri, 16 Apr 2010 16:20:22 -0700 (PDT) Received: from mail168.messagelabs.com (mail168.messagelabs.com [216.82.253.195]) by core3.amsl.com (Postfix) with ESMTP id 7174F3A68D9; Fri, 16 Apr 2010 16:20:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-168.messagelabs.com!1271460003!20576079!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 14996 invoked from network); 16 Apr 2010 23:20:04 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-12.tower-168.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Apr 2010 23:20:04 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id o3GNK2mc007849; Fri, 16 Apr 2010 19:20:02 -0400 In-Reply-To: <4BC8C243.3040405@alcatel-lucent.com> References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> <4BC8C243.3040405@alcatel-lucent.com> To: Volker Hilt MIME-Version: 1.0 X-KeepSent: B89D5A3C:35037DD0-85257707:008027C1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 16 Apr 2010 19:19:53 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/16/2010 07:20:49 PM, Serialize complete at 04/16/2010 07:20:49 PM Content-Type: multipart/alternative; boundary="=_alternative 00802E6D85257707_=" Cc: sip-overload-bounces@ietf.org, DISPATCH , "sip-overload@ietf.org" , Lars Eggert Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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, 16 Apr 2010 23:20:27 -0000 This is a multipart message in MIME format. --=_alternative 00802E6D85257707_= Content-Type: text/plain; charset="US-ASCII" Works for me Janet sip-overload-bounces@ietf.org wrote on 04/16/2010 04:02:11 PM: > [image removed] > > Re: [sip-overload] Proposed SIP Overload Control Charter > > Volker Hilt > > to: > > Robert Sparks, DISPATCH, sip-overload@ietf.org, Lars Eggert , > Gonzalo Camarillo > > 04/16/2010 04:00 PM > > Sent by: > > sip-overload-bounces@ietf.org > > An slight update to the charter Robert has sent out to address Janet's > comment. > > Volker > > > > SIP Overload Control WG Charter > ------------------------------- > > As with any network element, a Session Initiation Protocol (SIP) 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 complete the > processing of all incoming SIP messages within the required time. 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 goodput of a network of SIP servers can be > significantly degraded. In fact, overload may lead to a situation in > which the goodput drops down to zero or a small fraction of the original > processing capacity. This is often called congestion collapse. > > The objective of a SIP overload control mechanism is to enable SIP > servers to operate 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 fully prevent overload of a SIP > server and it cannot prevent congestion collapse. In fact, its on/off > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP > overload control. The problem domain of SIP overload control can be > split into overload control between a user agent and a SIP server and > overload control between SIP servers. > > Any specification developed by the working group needs to clearly > specify its scope. A specification also needs to clearly state any > limitations, in performance or otherwise, the specified overload control > mechanism may have. In particular, the working group shall carefully > define the deployment considerations for the effective operation of the > specified mechanisms and discuss, for example, when a mechanism requires > coordinated deployment and operation (if all servers need to deploy the > same mechanism, certain configuration values need to be identical on all > servers, etc), when a mechanism can become less effective or ineffective > under some conditions, or especially if there are cases when a mechanism > can reduce goodput compared to no overload protection. The intent of > these considerations is to allow potential deployers to make the best > use of these mechanism in their particular > networks. > > The working group will consider two complementary approaches 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 source or 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. > > The 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. > > Milestones: > > Sep 2010 Design Considerations to IESG for publication as Informational > Dec 2010 Specification for a SIP overload control mechanism based on > implicit/explicit feedback to IESG for publication as Proposed Standard > May 2011 Specification for a SIP load filtering mechaism to IESG for > publication as Proposed Standard > > > > > > On 4/16/2010 11:56 AM, Robert Sparks wrote: > > I have made some tweaks based on the list discussion and > conversations with IESG members. > > This is my current working text. Please comment if you disagree > with the changes I've made. > > > > The changes are in the description of overload in the first > paragraph, changing the term throughput > > to goodput, and clarifying the discussion of scope and > limitations. I've also added some strawman > > milestones. Please comment on those dates. > > > > SIP Overload Control WG Charter > > ------------------------------- > > > > As with any network element, a Session Initiation Protocol (SIP) 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 complete the > > processing of all incoming SIP messages within the required time. > > 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 goodput of a network of SIP servers can be > > significantly degraded. In fact, overload may lead to a situation in > > which the goodput drops down to zero or a small fraction of the > > original processing capacity. This is often called congestion collapse. > > > > The objective of a SIP overload control mechanism is to enable SIP > > servers to operate 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 fully prevent overload of a SIP > > server and it cannot prevent congestion collapse. In fact, its on/off > > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP > > overload control. The problem domain of SIP overload control can > be split into > > overload control between a user agent and a SIP server and overload control > > between SIP servers. > > > > Any specification developed by the working group needs to clearly > specify its > > scope. A specification also needs to clearly state any limitations, in > > performance or otherwise, the specified overload control mechanism > may have. In > > particular, the working group shall carefully define the deployment > > considerations for the effective operation of the specified mechanisms and > > discuss, for example, when a mechanism requires coordinated deployment and > > operation (if all servers need to deploy the same mechanism, certain > > configuration values need to be identical on all servers, etc), when a > > mechanism can become less effective or ineffective under some conditions, or > > especially if there are cases when a mechanism can reduce goodput > compared to > > no overload protection. The intent of these considerations is to allow > > potential deployers to make the best use of these mechanism in > their particular > > networks. > > > > The working group will consider two complementary approaches 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. > > > > The 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. > > > > Milestones: > > > > Sep 2010 Design Considerations to IESG for publication as Informational > > Dec 2010 Specification for a SIP overload control mechanism based > on implicit/explicit feedback to IESG for publication as Proposed Standard > > May 2011 Specification for a SIP load filtering mechaism to IESG > for publication as Proposed Standard > > > > > > On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote: > > > >> All, > >> > >> below is an updated charter proposal for a SIP Overload Control > WG. It has additional text that specifications developed by the > proposed WG need to define scope and limitations (see below). > >> > >> Thanks, > >> > >> Volker > >> > >> > >> > >> SIP Overload Control WG Charter > >> ------------------------------- > >> > >> As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the > >> original processing capacity. This is often called congestion collapse. > >> > >> The objective of a SIP overload control mechanism is to enable SIP > >> servers to operate 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 fully prevent overload of a SIP > >> server and it cannot prevent congestion collapse. In fact, its on/off > >> behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control > can be split into i) overload control between a user agent and a SIP > server and overload control between SIP servers. A specification > developed by the proposed working group needs to clearly specify its > scope. A specification also needs to clearly state any limitations > in performance or otherwise the proposed overload control mechanism may have. > >> > >> 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. > >> > >> > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 00802E6D85257707_= Content-Type: text/html; charset="US-ASCII"

Works for me

Janet

sip-overload-bounces@ietf.org wrote on 04/16/2010 04:02:11 PM:

> [image removed]
>
> Re: [sip-overload] Proposed SIP Overload Control Charter
>
> Volker Hilt
>
> to:
>
> Robert Sparks, DISPATCH, sip-overload@ietf.org, Lars Eggert ,
> Gonzalo Camarillo
>
> 04/16/2010 04:00 PM
>
> Sent by:
>
> sip-overload-bounces@ietf.org
>
> An slight update to the charter Robert has sent out to address Janet's
> comment.
>
> Volker
>
>
>
> SIP Overload Control WG Charter
> -------------------------------
>
> As with any network element, a Session Initiation Protocol (SIP) 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 complete the
> processing of all incoming SIP messages within the required time. 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 goodput of a network of SIP servers can be
> significantly degraded.  In fact, overload may lead to a situation in
> which the goodput drops down to zero or a small fraction of the original
> processing capacity.  This is often called congestion collapse.
>
> The objective of a SIP overload control mechanism is to enable SIP
> servers to operate 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 fully prevent overload of a SIP
> server and it cannot prevent congestion collapse.  In fact, its on/off
> behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP
> overload control. The problem domain of SIP overload control can be
> split into overload control between a user agent and a SIP server and
> overload control between SIP servers.
>
> Any specification developed by the working group needs to clearly
> specify its scope. A specification also needs to clearly state any
> limitations, in performance or otherwise, the specified overload control
> mechanism may have.  In particular, the working group shall carefully
> define the deployment considerations for the effective operation of the
> specified mechanisms and discuss, for example, when a mechanism requires
> coordinated deployment and operation (if all servers need to deploy the
> same mechanism, certain configuration values need to be identical on all
> servers, etc), when a mechanism can become less effective or ineffective
> under some conditions, or especially if there are cases when a mechanism
> can reduce goodput compared to no overload protection. The intent of
> these considerations is to allow potential deployers to make the best
> use of these mechanism in their particular
> networks.
>
> The working group will consider two complementary approaches 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 source or 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.
>
> The 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.
>
> Milestones:
>
> Sep 2010 Design Considerations to IESG for publication as Informational
> Dec 2010 Specification for a SIP overload control mechanism based on
> implicit/explicit feedback to IESG for publication as Proposed Standard
> May 2011 Specification for a SIP load filtering mechaism to IESG for
> publication as Proposed Standard
>
>
>
>
>
> On 4/16/2010 11:56 AM, Robert Sparks wrote:
> > I have made some tweaks based on the list discussion and
> conversations with IESG members.
> > This is my current working text. Please comment if you disagree
> with the changes I've made.
> >
> > The changes are in the description of overload in the first
> paragraph, changing the term throughput
> > to goodput, and clarifying the discussion of scope and
> limitations. I've also added some strawman
> > milestones. Please comment on those dates.
> >
> > SIP Overload Control WG Charter
> > -------------------------------
> >
> > As with any network element, a Session Initiation Protocol (SIP) 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 complete the
> > processing of all incoming SIP messages within the required time.
> > 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 goodput of a network of SIP servers can be
> > significantly degraded.  In fact, overload may lead to a situation in
> > which the goodput drops down to zero or a small fraction of the
> > original processing capacity.  This is often called congestion collapse.
> >
> > The objective of a SIP overload control mechanism is to enable SIP
> > servers to operate 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 fully prevent overload of a SIP
> > server and it cannot prevent congestion collapse.  In fact, its on/off
> > behavior may cause traffic to oscillate and 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 working group is to develop mechanisms for SIP
> > overload control. The problem domain of SIP overload control can
> be split into
> > overload control between a user agent and a SIP server and overload control
> > between SIP servers.
> >
> > Any specification developed by the working group needs to clearly
> specify its
> > scope. A specification also needs to clearly state any limitations, in
> > performance or otherwise, the specified overload control mechanism
> may have.  In
> > particular, the working group shall carefully define the deployment
> > considerations for the effective operation of the specified mechanisms and
> > discuss, for example, when a mechanism requires coordinated deployment and
> > operation (if all servers need to deploy the same mechanism, certain
> > configuration values need to be identical on all servers, etc), when a
> > mechanism can become less effective or ineffective under some conditions, or
> > especially if there are cases when a mechanism can reduce goodput
> compared to
> > no overload protection. The intent of these considerations is to allow
> > potential deployers to make the best use of these mechanism in
> their particular
> > networks.
> >
> > The working group will consider two complementary approaches 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.
> >
> > The 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.
> >
> > Milestones:
> >
> > Sep 2010 Design Considerations to IESG for publication as Informational
> > Dec 2010 Specification for a SIP overload control mechanism based
> on implicit/explicit feedback to IESG for publication as Proposed Standard
> > May 2011 Specification for a SIP load filtering mechaism to IESG
> for publication as Proposed Standard
> >
> >
> > On Apr 1, 2010, at 7:55 PM, Volker Hilt wrote:
> >
> >> All,
> >>
> >> below is an updated charter proposal for a SIP Overload Control
> WG. It has additional text that specifications developed by the
> proposed WG need to define scope and limitations (see below).
> >>
> >> Thanks,
> >>
> >> Volker
> >>
> >>
> >>
> >> SIP Overload Control WG Charter
> >> -------------------------------
> >>
> >> As with any network element, a Session Initiation Protocol (SIP) 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 zero or a small fraction of the
> >> original processing capacity.  This is often called congestion collapse.
> >>
> >> The objective of a SIP overload control mechanism is to enable SIP
> >> servers to operate 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 fully prevent overload of a SIP
> >> server and it cannot prevent congestion collapse.  In fact, its on/off
> >> behavior may cause traffic to oscillate and 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. The problem domain of SIP overload control
> can be split into i) overload control between a user agent and a SIP
> server and overload control between SIP servers. A specification
> developed by the proposed working group needs to clearly specify its
> scope. A specification also needs to clearly state any limitations
> in performance or otherwise the proposed overload control mechanism may have.
> >>
> >> 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.
> >>
> >>
> >
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 00802E6D85257707_=-- From HKaplan@acmepacket.com Sat Apr 17 11:42:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F713A6885 for ; Sat, 17 Apr 2010 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 jLXrMNMWO2sQ for ; Sat, 17 Apr 2010 11:42:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2A22A3A683E for ; Sat, 17 Apr 2010 11:42: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, 17 Apr 2010 14:42:36 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Apr 2010 14:42:35 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Sat, 17 Apr 2010 14:42:34 -0400 Thread-Topic: New version: draft-kaplan-dispatch-session-id-01 Thread-Index: AcreXb7Q5DD6aULJRWS+CUS2KnpSWQ== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> 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] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 18:42:45 -0000 Howdy, Based on discussions at IETF-76, I have submitted an updated draft-kaplan-d= ispatch-session-id-01. Pursuant to the changed rules for SIP header field registration in RFC 5727= , I have changed the draft to be Informational and I'm fine with going the = Individual submission path instead of a WG, if there is no interest for thi= s to be DISPATCHed elsewhere. I believe this document complies with the in= tent of RFC 5727. Comments/concerns/flames are appreciated. =20 The main changes since last version: - changed it to be Informational, and put in text for rfc5727. - removed the specific hash algorithm for the generated value, to make it e= asier for folks to just use a random number/algorithm - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary numbe= r can be generated/recorded/used - relaxed the requirements on B2BUA's so that the generation of it is optio= nal, but pass-through/copy is still mandatory > -----Original Message----- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Session Identifier for the Session Initiation Protocol= (SIP) Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-session-id-01.txt Pages : 11 Date : 2010-04-17 There is a need for having a globally unique session identifier for the sam= e SIP session, which can be consistently maintained across Proxies, B2BUAs = and other SIP middle-boxes, for the purpose of Troubleshooting. This draft= proposes a new SIP header to carry such a value: Session-ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From laura.liess.dt@googlemail.com Tue Apr 20 05:28:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8379F3A6B84 for ; Tue, 20 Apr 2010 05:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=1.600, 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 Q7HJCoxrvqNM for ; Tue, 20 Apr 2010 05:28:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 152B73A6BAC for ; Tue, 20 Apr 2010 05:27:12 -0700 (PDT) Received: by wwi18 with SMTP id 18so1339717wwi.31 for ; Tue, 20 Apr 2010 05:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y1hqhqSn/LshXsLisDUWpINEUIREgJIOYUTbUkSfgtg=; b=QGXYtH/0PWR2o3e9r/AqAnxuHDIxE8OOY0Fsk4GSS3Zn4Yok62yAKnKmCSMKyCzdC1 KrsBWPezezkW24ZeF/Uh8gcdDo9il6/c70Pd24g52+72gF78nB1E3wPsepQQ5h6sPmOC OpFftUk/0D5K2OUrZ/gu1vtHKNm+zI+CvzRpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KcGg1S5HE50Ks7ZqMTIzWVZmmK+OafCovybNdq7o35h1oi/PPSJj7TGW7yKO1VHDmq aFzMGutW0S1I4xKFTsdLKfiNKGImSs6G7vdORWeTqgE2VF9OoS+ysfH6AzEhDsGsFOMW O3zxRv03COHGYU55B+dRqJAhbNn5ETyFpVDTc= MIME-Version: 1.0 Received: by 10.216.169.85 with HTTP; Tue, 20 Apr 2010 05:27:00 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> Date: Tue, 20 Apr 2010 14:27:00 +0200 Received: by 10.216.158.1 with SMTP id p1mr2292384wek.202.1271766420828; Tue, 20 Apr 2010 05:27:00 -0700 (PDT) Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , =?ISO-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 12:28:38 -0000 Hadriel, I don't think that there is no interest for the draft to be DISPATCHed. We had a lot of discussion on it in the past. It's just that people are busy and the current DISPATCH process requires a lot of overhead (charter, chairs...). In principle, I am OK with any way to get the Session-ID to RFC. Proposed Standard or Informational. As far as I know , other SDOs and also other carriers, not only DT, already use/refer the Session-ID. Comment to the draft: - I am OK with allowing other algorithms than Call-ID hash. However, the description of the hash algorithm in the 00 version was very usefull and avoided problems with different algorithms being used by the B2BUA and monitoring systems. I don't see any reason for not including it as an implementation example. - Chapter 3. Overview, 3-rd paragraph: "Instead this new header field provides an identifier for troubleshooting uses only." Implementations and other SDOs (I know of 3GPP) already use Session-ID for SIP-services as Conferencing, to correlate both legs of a dialog across a B2BUA. There is no other SIP-identifier they can use for this. So my proposal is to allow this in the Session-ID draft. Otherwise we either have inconcistency between IETF and IMS documents. Kind regards Laura 2010/4/17 Hadriel Kaplan : > Howdy, > Based on discussions at IETF-76, I have submitted an updated draft-kaplan= -dispatch-session-id-01. > > Pursuant to the changed rules for SIP header field registration in RFC 57= 27, I have changed the draft to be Informational and I'm fine with going th= e Individual submission path instead of a WG, if there is no interest for t= his to be DISPATCHed elsewhere. =A0I believe this document complies with th= e intent of RFC 5727. > > Comments/concerns/flames are appreciated. > > The main changes since last version: > - changed it to be Informational, and put in text for rfc5727. > - removed the specific hash algorithm for the generated value, to make it= easier for folks to just use a random number/algorithm > - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary num= ber can be generated/recorded/used > - relaxed the requirements on B2BUA's so that the generation of it is opt= ional, but pass-through/copy is still mandatory > >> -----Original Message----- > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Session Identifier for the S= ession Initiation Protocol (SIP) > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-dispatch-session-id= -01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-04-17 > > There is a need for having a globally unique session identifier for the s= ame SIP session, which can be consistently maintained across Proxies, B2BUA= s and other SIP middle-boxes, for the purpose of Troubleshooting. =A0This d= raft proposes a new SIP header to carry such a value: Session-ID. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-01.t= xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.musgrave@magorcorp.com Tue Apr 20 06:09:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEC33A6A34 for ; Tue, 20 Apr 2010 06:09:10 -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 7fliePiXDM5I for ; Tue, 20 Apr 2010 06:09:09 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 216FC3A6905 for ; Tue, 20 Apr 2010 06:09:09 -0700 (PDT) Received: by gwj20 with SMTP id 20so965679gwj.31 for ; Tue, 20 Apr 2010 06:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.178.11 with HTTP; Tue, 20 Apr 2010 06:08:57 -0700 (PDT) In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> Date: Tue, 20 Apr 2010 09:08:57 -0400 Received: by 10.151.28.8 with SMTP id f8mr7512353ybj.90.1271768937167; Tue, 20 Apr 2010 06:08:57 -0700 (PDT) Message-ID: From: Peter Musgrave To: Laura Liess Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Roland Jesske , "dispatch@ietf.org" , =?ISO-8859-1?Q?Martin_H=FClsemann?= , Hadriel Kaplan Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:09:10 -0000 Hi Hadriel, I am interested in the draft. One thing that confused me (and maybe I'm just easily confused) was the term 'out-of-dialog INVITE' in the Example (Section 7). I'm inferring this is an INVITE which starts a dialog (i.e. has no To: tag). I would have referred to this as a dialog-creating INVITE. Is 'out-of-dialog INVITE' a standard term? (I tend to to thing of methods like MESSAGE when I read "out-of-dialog") Peter Musgrave On Tue, Apr 20, 2010 at 8:27 AM, Laura Liess wrote: > Hadriel, > > I don't think that there is no interest for the draft to be > DISPATCHed. We had a lot of discussion on it in the past. It's just > that people are busy and the current DISPATCH process requires a lot > of overhead (charter, chairs...). In principle, I am OK with any way > to get the Session-ID to RFC. Proposed Standard or Informational. =A0As > far as I know , other SDOs and also other carriers, not only DT, > already use/refer the Session-ID. > > Comment to the draft: > - I am OK with allowing other algorithms than Call-ID hash. However, > the description of the hash algorithm in the 00 version was very > usefull and avoided problems with different algorithms being used by > the B2BUA and monitoring systems. I don't see any reason for not > including it as an implementation example. > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new header field > provides an identifier for troubleshooting uses only." > =A0Implementations and other SDOs (I know of 3GPP) already use > Session-ID for SIP-services as Conferencing, to correlate both legs of > a dialog across a B2BUA. There is no other SIP-identifier they can use > for this. So my proposal is to allow this in the Session-ID draft. > Otherwise we either have inconcistency between IETF and IMS documents. > > Kind regards > Laura > > > > > 2010/4/17 Hadriel Kaplan : >> Howdy, >> Based on discussions at IETF-76, I have submitted an updated draft-kapla= n-dispatch-session-id-01. >> >> Pursuant to the changed rules for SIP header field registration in RFC 5= 727, I have changed the draft to be Informational and I'm fine with going t= he Individual submission path instead of a WG, if there is no interest for = this to be DISPATCHed elsewhere. =A0I believe this document complies with t= he intent of RFC 5727. >> >> Comments/concerns/flames are appreciated. >> >> The main changes since last version: >> - changed it to be Informational, and put in text for rfc5727. >> - removed the specific hash algorithm for the generated value, to make i= t easier for folks to just use a random number/algorithm >> - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary nu= mber can be generated/recorded/used >> - relaxed the requirements on B2BUA's so that the generation of it is op= tional, but pass-through/copy is still mandatory >> >>> -----Original Message----- >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Session Identifier for the = Session Initiation Protocol (SIP) >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-dispatch-session-i= d-01.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-04-17 >> >> There is a need for having a globally unique session identifier for the = same SIP session, which can be consistently maintained across Proxies, B2BU= As and other SIP middle-boxes, for the purpose of Troubleshooting. =A0This = draft proposes a new SIP header to carry such a value: Session-ID. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-01.= txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> 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 HKaplan@acmepacket.com Tue Apr 20 21:44:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3946F3A694F for ; Tue, 20 Apr 2010 21:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaGD3UuET3tK for ; Tue, 20 Apr 2010 21:44:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EA4AF3A68A7 for ; Tue, 20 Apr 2010 21:44: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; Wed, 21 Apr 2010 00:44:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 21 Apr 2010 00:44:41 -0400 From: Hadriel Kaplan To: Peter Musgrave , Laura Liess Date: Wed, 21 Apr 2010 00:44:39 -0400 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: Acrgiq/7UuADZ+QIQheAHetqLUymQgAgiSPg Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , =?iso-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 04:44:52 -0000 Hi Peter,=20 Yeah I should probably change that term to dialog-creating, and will do so = for the next rev. (I see and use the term "out-of-dialog request" all the t= ime to refer to any request that's not in a dialog, including dialog-creati= ng INVITE and SUBSCRIBE, but if it confuses people it's easy to change :) -hadriel > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Tuesday, April 20, 2010 9:09 AM > To: Laura Liess >=20 > Hi Hadriel, >=20 > I am interested in the draft. >=20 > One thing that confused me (and maybe I'm just easily confused) was > the term 'out-of-dialog INVITE' in the Example (Section 7). I'm > inferring this is an INVITE which starts a dialog (i.e. has no To: > tag). I would have referred to this as a dialog-creating INVITE. Is > 'out-of-dialog INVITE' a standard term? (I tend to to thing of methods > like MESSAGE when I read "out-of-dialog") >=20 > Peter Musgrave >=20 > On Tue, Apr 20, 2010 at 8:27 AM, Laura Liess > wrote: > > Hadriel, > > > > I don't think that there is no interest for the draft to be > > DISPATCHed. We had a lot of discussion on it in the past. It's just > > that people are busy and the current DISPATCH process requires a lot > > of overhead (charter, chairs...). In principle, I am OK with any way > > to get the Session-ID to RFC. Proposed Standard or Informational. =A0As > > far as I know , other SDOs and also other carriers, not only DT, > > already use/refer the Session-ID. > > > > Comment to the draft: > > - I am OK with allowing other algorithms than Call-ID hash. However, > > the description of the hash algorithm in the 00 version was very > > usefull and avoided problems with different algorithms being used by > > the B2BUA and monitoring systems. I don't see any reason for not > > including it as an implementation example. > > > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new header field > > provides an identifier for troubleshooting uses only." > > =A0Implementations and other SDOs (I know of 3GPP) already use > > Session-ID for SIP-services as Conferencing, to correlate both legs of > > a dialog across a B2BUA. There is no other SIP-identifier they can use > > for this. So my proposal is to allow this in the Session-ID draft. > > Otherwise we either have inconcistency between IETF and IMS documents. > > > > Kind regards > > Laura > > > > > > > > > > 2010/4/17 Hadriel Kaplan : > >> Howdy, > >> Based on discussions at IETF-76, I have submitted an updated draft- > kaplan-dispatch-session-id-01. > >> > >> Pursuant to the changed rules for SIP header field registration in RFC > 5727, I have changed the draft to be Informational and I'm fine with goin= g > the Individual submission path instead of a WG, if there is no interest > for this to be DISPATCHed elsewhere. =A0I believe this document complies > with the intent of RFC 5727. > >> > >> Comments/concerns/flames are appreciated. > >> > >> The main changes since last version: > >> - changed it to be Informational, and put in text for rfc5727. > >> - removed the specific hash algorithm for the generated value, to make > it easier for folks to just use a random number/algorithm > >> - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary > number can be generated/recorded/used > >> - relaxed the requirements on B2BUA's so that the generation of it is > optional, but pass-through/copy is still mandatory > >> > >>> -----Original Message----- > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> > >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Session Identifier for th= e Session > Initiation Protocol (SIP) > >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan > >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-dispatch-session= -id-01.txt > >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 > >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-04-17 > >> > >> There is a need for having a globally unique session identifier for th= e > same SIP session, which can be consistently maintained across Proxies, > B2BUAs and other SIP middle-boxes, for the purpose of > Troubleshooting. =A0This draft proposes a new SIP header to carry such a > value: Session-ID. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- > 01.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From john.elwell@siemens-enterprise.com Wed Apr 21 01:52:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F463A6ABA for ; Wed, 21 Apr 2010 01:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 isO18b28uAkY for ; Wed, 21 Apr 2010 01:52:40 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 63EFD3A6A11 for ; Wed, 21 Apr 2010 01:52:38 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1623221; Wed, 21 Apr 2010 10:52:28 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1E1C923F028E; Wed, 21 Apr 2010 10:52:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 21 Apr 2010 10:52:28 +0200 From: "Elwell, John" To: Hadriel Kaplan , Peter Musgrave , Laura Liess Date: Wed, 21 Apr 2010 10:52:25 +0200 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: Acrgiq/7UuADZ+QIQheAHetqLUymQgAgiSPgAAiqeEA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> 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" , =?iso-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:52:41 -0000 I don't have a problem with "out-of-dialog" request (meaning any request th= at is not mid-dialog). The term "dialog-creating" doesn't work if you want = to include things that don't create dialogs, e.g., PUBLISH, MESSAGE. In thi= s particular draft, if we are only referring to INVITE, I guess it doesn't = matter. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 21 April 2010 05:45 > To: Peter Musgrave; Laura Liess > Cc: dispatch@ietf.org; Martin H=FClsemann; Roland Jesske > Subject: Re: [dispatch] New version:=20 > draft-kaplan-dispatch-session-id-01 >=20 >=20 > Hi Peter,=20 > Yeah I should probably change that term to dialog-creating,=20 > and will do so for the next rev. (I see and use the term=20 > "out-of-dialog request" all the time to refer to any request=20 > that's not in a dialog, including dialog-creating INVITE and=20 > SUBSCRIBE, but if it confuses people it's easy to change :) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > > Sent: Tuesday, April 20, 2010 9:09 AM > > To: Laura Liess > >=20 > > Hi Hadriel, > >=20 > > I am interested in the draft. > >=20 > > One thing that confused me (and maybe I'm just easily confused) was > > the term 'out-of-dialog INVITE' in the Example (Section 7). I'm > > inferring this is an INVITE which starts a dialog (i.e. has no To: > > tag). I would have referred to this as a dialog-creating INVITE. Is > > 'out-of-dialog INVITE' a standard term? (I tend to to thing=20 > of methods > > like MESSAGE when I read "out-of-dialog") > >=20 > > Peter Musgrave > >=20 > > On Tue, Apr 20, 2010 at 8:27 AM, Laura Liess > > wrote: > > > Hadriel, > > > > > > I don't think that there is no interest for the draft to be > > > DISPATCHed. We had a lot of discussion on it in the past.=20 > It's just > > > that people are busy and the current DISPATCH process=20 > requires a lot > > > of overhead (charter, chairs...). In principle, I am OK=20 > with any way > > > to get the Session-ID to RFC. Proposed Standard or=20 > Informational. =A0As > > > far as I know , other SDOs and also other carriers, not only DT, > > > already use/refer the Session-ID. > > > > > > Comment to the draft: > > > - I am OK with allowing other algorithms than Call-ID=20 > hash. However, > > > the description of the hash algorithm in the 00 version was very > > > usefull and avoided problems with different algorithms=20 > being used by > > > the B2BUA and monitoring systems. I don't see any reason for not > > > including it as an implementation example. > > > > > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new=20 > header field > > > provides an identifier for troubleshooting uses only." > > > =A0Implementations and other SDOs (I know of 3GPP) already use > > > Session-ID for SIP-services as Conferencing, to correlate=20 > both legs of > > > a dialog across a B2BUA. There is no other SIP-identifier=20 > they can use > > > for this. So my proposal is to allow this in the Session-ID draft. > > > Otherwise we either have inconcistency between IETF and=20 > IMS documents. > > > > > > Kind regards > > > Laura > > > > > > > > > > > > > > > 2010/4/17 Hadriel Kaplan : > > >> Howdy, > > >> Based on discussions at IETF-76, I have submitted an=20 > updated draft- > > kaplan-dispatch-session-id-01. > > >> > > >> Pursuant to the changed rules for SIP header field=20 > registration in RFC > > 5727, I have changed the draft to be Informational and I'm=20 > fine with going > > the Individual submission path instead of a WG, if there is=20 > no interest > > for this to be DISPATCHed elsewhere. =A0I believe this=20 > document complies > > with the intent of RFC 5727. > > >> > > >> Comments/concerns/flames are appreciated. > > >> > > >> The main changes since last version: > > >> - changed it to be Informational, and put in text for rfc5727. > > >> - removed the specific hash algorithm for the generated=20 > value, to make > > it easier for folks to just use a random number/algorithm > > >> - changed it to be 16-chars of hex ascii (0-9a-f), so a=20 > 64-bit binary > > number can be generated/recorded/used > > >> - relaxed the requirements on B2BUA's so that the=20 > generation of it is > > optional, but pass-through/copy is still mandatory > > >> > > >>> -----Original Message----- > > >> A New Internet-Draft is available from the on-line=20 > Internet-Drafts > > directories. > > >> > > >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Session Identifier for = the Session > > Initiation Protocol (SIP) > > >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan > > >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-dispatch-sessi= on-id-01.txt > > >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 > > >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-04-17 > > >> > > >> There is a need for having a globally unique session=20 > identifier for the > > same SIP session, which can be consistently maintained=20 > across Proxies, > > B2BUAs and other SIP middle-boxes, for the purpose of > > Troubleshooting. =A0This draft proposes a new SIP header to=20 > carry such a > > value: Session-ID. > > >> > > >> A URL for this Internet-Draft is: > > >>=20 > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- > > 01.txt > > >> > > >> Internet-Drafts are also available by anonymous FTP at: > > >> ftp://ftp.ietf.org/internet-drafts/ > > >> > > >> > > >> _______________________________________________ > > >> 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 HKaplan@acmepacket.com Wed Apr 21 06:37:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4709D3A6A85 for ; Wed, 21 Apr 2010 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 EG+dZRQ-56Fs for ; Wed, 21 Apr 2010 06:37:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E6E9428C374 for ; Wed, 21 Apr 2010 06:20:29 -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, 21 Apr 2010 09:20:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 21 Apr 2010 09:20:12 -0400 From: Hadriel Kaplan To: "Elwell, John" , Peter Musgrave , Laura Liess Date: Wed, 21 Apr 2010 09:20:11 -0400 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: Acrgiq/7UuADZ+QIQheAHetqLUymQgAgiSPgAAiqeEAACW0hcA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF41B@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , =?iso-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 13:37:13 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 21, 2010 4:52 AM >=20 > I don't have a problem with "out-of-dialog" request (meaning any request > that is not mid-dialog). The term "dialog-creating" doesn't work if you > want to include things that don't create dialogs, e.g., PUBLISH, MESSAGE. > In this particular draft, if we are only referring to INVITE, I guess it > doesn't matter. It applies to any message, but Peter was talking about the Example section = where I showed an "out-of-dialog INVITE".=20 -hadriel From rjsparks@nostrum.com Wed Apr 21 08:49:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419AC3A6B6F; Wed, 21 Apr 2010 08:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.125, 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 M7kAFBTJsrtT; Wed, 21 Apr 2010 08:49:10 -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 8483228C0E2; Wed, 21 Apr 2010 08:29:01 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3LFSd9s087976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Apr 2010 10:28:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> Date: Wed, 21 Apr 2010 10:28:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com> <4BB5409E.5080108@alcatel-lucent.com> <0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Volker Hilt , DISPATCH , "sip-overload@ietf.org" , Lars Eggert Subject: Re: [dispatch] Proposed SIP Overload Control 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: Wed, 21 Apr 2010 15:49:11 -0000 Please comment on what these dates should actually be=20 RjS > Milestones: >=20 > Sep 2010 Design Considerations to IESG for publication as = Informational > Dec 2010 Specification for a SIP overload control mechanism based on = implicit/explicit feedback to IESG for publication as Proposed Standard > May 2011 Specification for a SIP load filtering mechaism to IESG for = publication as Proposed Standard From jmpolk@cisco.com Wed Apr 21 09:14:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C301C3A6D39 for ; Wed, 21 Apr 2010 09:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yXvIc2ScmJy for ; Wed, 21 Apr 2010 09:14:14 -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 EB37628C418 for ; Wed, 21 Apr 2010 08:49:27 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFC7zkurR7H+/2dsb2JhbACcEXGjV5pHgl+CMASDNA X-IronPort-AV: E=Sophos;i="4.52,250,1270425600"; d="scan'208";a="118536797" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2010 15:49:18 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3LFnHbb019972; Wed, 21 Apr 2010 15:49:18 GMT Message-Id: <201004211549.o3LFnHbb019972@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Apr 2010 10:49:16 -0500 To: "Elwell, John" , Hadriel Kaplan , Peter Musgrave , Laura Liess From: "James M. Polk" In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , =?iso-8859-1?Q?H=FClsemann?= , Roland Jesske , Martin Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:14:15 -0000 At 03:52 AM 4/21/2010, Elwell, John wrote: >I don't have a problem with "out-of-dialog"=20 >request (meaning any request that is not=20 >mid-dialog). The term "dialog-creating" doesn't=20 >work if you want to include things that don't=20 >create dialogs, e.g., PUBLISH, MESSAGE. In this=20 >particular draft, if we are only referring to=20 >INVITE, I guess it doesn't matter. "dialog-creating" INVITE is MUCH preferred over=20 "out-of-dialog" INVITE, as some will not easily=20 understand the latter - and be easily confused=20 when this appears. It's just not that intuitive (at least to me as well). Someone reading "dialog-creating" INVITE could=20 say to themselves "duh, it's an INVITE always creating a dialog?" redundancy is better than something less clear James >John > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > Sent: 21 April 2010 05:45 > > To: Peter Musgrave; Laura Liess > > Cc: dispatch@ietf.org; Martin H=FClsemann; Roland Jesske > > Subject: Re: [dispatch] New version: > > draft-kaplan-dispatch-session-id-01 > > > > > > Hi Peter, > > Yeah I should probably change that term to dialog-creating, > > and will do so for the next rev. (I see and use the term > > "out-of-dialog request" all the time to refer to any request > > that's not in a dialog, including dialog-creating INVITE and > > SUBSCRIBE, but if it confuses people it's easy to change :) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > > > Sent: Tuesday, April 20, 2010 9:09 AM > > > To: Laura Liess > > > > > > Hi Hadriel, > > > > > > I am interested in the draft. > > > > > > One thing that confused me (and maybe I'm just easily confused) was > > > the term 'out-of-dialog INVITE' in the Example (Section 7). I'm > > > inferring this is an INVITE which starts a dialog (i.e. has no To: > > > tag). I would have referred to this as a dialog-creating INVITE. Is > > > 'out-of-dialog INVITE' a standard term? (I tend to to thing > > of methods > > > like MESSAGE when I read "out-of-dialog") > > > > > > Peter Musgrave > > > > > > On Tue, Apr 20, 2010 at 8:27 AM, Laura Liess > > > wrote: > > > > Hadriel, > > > > > > > > I don't think that there is no interest for the draft to be > > > > DISPATCHed. We had a lot of discussion on it in the past. > > It's just > > > > that people are busy and the current DISPATCH process > > requires a lot > > > > of overhead (charter, chairs...). In principle, I am OK > > with any way > > > > to get the Session-ID to RFC. Proposed Standard or > > Informational. As > > > > far as I know , other SDOs and also other carriers, not only DT, > > > > already use/refer the Session-ID. > > > > > > > > Comment to the draft: > > > > - I am OK with allowing other algorithms than Call-ID > > hash. However, > > > > the description of the hash algorithm in the 00 version was very > > > > usefull and avoided problems with different algorithms > > being used by > > > > the B2BUA and monitoring systems. I don't see any reason for not > > > > including it as an implementation example. > > > > > > > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new > > header field > > > > provides an identifier for troubleshooting uses only." > > > > Implementations and other SDOs (I know of 3GPP) already use > > > > Session-ID for SIP-services as Conferencing, to correlate > > both legs of > > > > a dialog across a B2BUA. There is no other SIP-identifier > > they can use > > > > for this. So my proposal is to allow this in the Session-ID draft. > > > > Otherwise we either have inconcistency between IETF and > > IMS documents. > > > > > > > > Kind regards > > > > Laura > > > > > > > > > > > > > > > > > > > > 2010/4/17 Hadriel Kaplan : > > > >> Howdy, > > > >> Based on discussions at IETF-76, I have submitted an > > updated draft- > > > kaplan-dispatch-session-id-01. > > > >> > > > >> Pursuant to the changed rules for SIP header field > > registration in RFC > > > 5727, I have changed the draft to be Informational and I'm > > fine with going > > > the Individual submission path instead of a WG, if there is > > no interest > > > for this to be DISPATCHed elsewhere. I believe this > > document complies > > > with the intent of RFC 5727. > > > >> > > > >> Comments/concerns/flames are appreciated. > > > >> > > > >> The main changes since last version: > > > >> - changed it to be Informational, and put in text for rfc5727. > > > >> - removed the specific hash algorithm for the generated > > value, to make > > > it easier for folks to just use a random number/algorithm > > > >> - changed it to be 16-chars of hex ascii (0-9a-f), so a > > 64-bit binary > > > number can be generated/recorded/used > > > >> - relaxed the requirements on B2BUA's so that the > > generation of it is > > > optional, but pass-through/copy is still mandatory > > > >> > > > >>> -----Original Message----- > > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > directories. > > > >> > > > >> Title : A Session Identifier for the Session > > > Initiation Protocol (SIP) > > > >> Author(s) : H. Kaplan > > > >> Filename : draft-kaplan-dispatch-session-id-01.txt > > > >> Pages : 11 > > > >> Date : 2010-04-17 > > > >> > > > >> There is a need for having a globally unique session > > identifier for the > > > same SIP session, which can be consistently maintained > > across Proxies, > > > B2BUAs and other SIP middle-boxes, for the purpose of > > > Troubleshooting. This draft proposes a new SIP header to > > carry such a > > > value: Session-ID. > > > >> > > > >> A URL for this Internet-Draft is: > > > >> > > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- > > > 01.txt > > > >> > > > >> Internet-Drafts are also available by anonymous FTP at: > > > >> ftp://ftp.ietf.org/internet-drafts/ > > > >> > > > >> > > > >> _______________________________________________ > > > >> dispatch mailing list > > > >> dispatch@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/dispatch > > > >> > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From ietf.hanserik@gmail.com Wed Apr 21 10:07:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6130D3A69FD for ; Wed, 21 Apr 2010 10:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 PnfpSONE5x01 for ; Wed, 21 Apr 2010 10:07:30 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id C38293A6C5F for ; Wed, 21 Apr 2010 09:53:30 -0700 (PDT) Received: by ewy24 with SMTP id 24so2514335ewy.13 for ; Wed, 21 Apr 2010 09:53:18 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jbTRtroV/4/imRezKKtJ588HPd/xlIZ8ddSB5nzMME0=; b=Nha3TD7TQQvvuXkdIHEdISutuEK/3YX+ITcJlruFp4hUm6P2QGNzf9jek/zip2IjOR 9HoEompdtwGXRUTKt0Vc99hBThl/sygV7e2fb2Et0PDTCCN6ZfSw80m3RZytFO+6a46L Ij5Hrm269xduMuWcr0liP0himEx/18l8KvpMc= 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=G/itlr/PsgZ8o8Znb5ykaXcoquJyNz6m2TxOMIkHOrDWb8iyrALBTxSPYqFjQeNhN/ sNxR1BA9dqm78VbYGJ8xOUQWYSmq8sGgenik5eJ1H0ZNcm9ZiDgJqamURbrT60CcW2H6 CE7nvLxT5LFvOar4ubbgyOMnSmprFmcTgLlck= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Wed, 21 Apr 2010 09:53:17 -0700 (PDT) In-Reply-To: <201004211549.o3LFnHbb019972@sj-core-2.cisco.com> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> <201004211549.o3LFnHbb019972@sj-core-2.cisco.com> Date: Wed, 21 Apr 2010 18:53:17 +0200 Received: by 10.213.15.17 with SMTP id i17mr4369576eba.62.1271868797946; Wed, 21 Apr 2010 09:53:17 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "James M. Polk" , Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , Roland Jesske , =?ISO-8859-1?Q?H=FClsemann?= , Martin@core3.amsl.com, Laura Liess Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:07:32 -0000 Since the dark days that RFC3261 seen the light a dialog-creating-INVITE or out-of-dialog INVITE is called an "initial INVITE" and an in-dialog INVITE is called a re-INVITE. I prefer those ancient well understood terms over the new ones used in this conversation. Initial INVITEs create dialogs, that is what they do, re-INVITEs don't. Initial INVITEs belong to the class of "initial requests for a dialog" and hence also to "initial requests", re-INVITEs to the class of "in-dialog requests" or "subsequent requests". The term out-of-dialog request seems problematic as it assumes the existence of a dialog where one might not exist. /Hans Erik van Elburg On Wed, Apr 21, 2010 at 5:49 PM, James M. Polk wrote: > At 03:52 AM 4/21/2010, Elwell, John wrote: >> >> I don't have a problem with "out-of-dialog" request (meaning any request >> that is not mid-dialog). The term "dialog-creating" doesn't work if you = want >> to include things that don't create dialogs, e.g., PUBLISH, MESSAGE. In = this >> particular draft, if we are only referring to INVITE, I guess it doesn't >> matter. > > "dialog-creating" INVITE is MUCH preferred over "out-of-dialog" INVITE, a= s > some will not easily understand the latter - and be easily confused when > this appears. =A0It's just not that intuitive (at least to me as well). > > Someone reading "dialog-creating" INVITE could say to themselves "duh, it= 's > an INVITE always creating a dialog?" > > redundancy is better than something less clear > > James > > >> John >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan >> > Sent: 21 April 2010 05:45 >> > To: Peter Musgrave; Laura Liess >> > Cc: dispatch@ietf.org; Martin H=FClsemann; Roland Jesske >> > Subject: Re: [dispatch] New version: >> > draft-kaplan-dispatch-session-id-01 >> > >> > >> > Hi Peter, >> > Yeah I should probably change that term to dialog-creating, >> > and will do so for the next rev. (I see and use the term >> > "out-of-dialog request" all the time to refer to any request >> > that's not in a dialog, including dialog-creating INVITE and >> > SUBSCRIBE, but if it confuses people it's easy to change :) >> > >> > -hadriel >> > >> > >> > > -----Original Message----- >> > > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >> > > Sent: Tuesday, April 20, 2010 9:09 AM >> > > To: Laura Liess >> > > >> > > Hi Hadriel, >> > > >> > > I am interested in the draft. >> > > >> > > One thing that confused me (and maybe I'm just easily confused) was >> > > the term 'out-of-dialog INVITE' in the Example (Section 7). I'm >> > > inferring this is an INVITE which starts a dialog (i.e. has no To: >> > > tag). I would have referred to this as a dialog-creating INVITE. Is >> > > 'out-of-dialog INVITE' a standard term? (I tend to to thing >> > of methods >> > > like MESSAGE when I read "out-of-dialog") >> > > >> > > Peter Musgrave >> > > >> > > On Tue, Apr 20, 2010 at 8:27 AM, Laura Liess >> > > wrote: >> > > > Hadriel, >> > > > >> > > > I don't think that there is no interest for the draft to be >> > > > DISPATCHed. We had a lot of discussion on it in the past. >> > It's just >> > > > that people are busy and the current DISPATCH process >> > requires a lot >> > > > of overhead (charter, chairs...). In principle, I am OK >> > with any way >> > > > to get the Session-ID to RFC. Proposed Standard or >> > Informational. =A0As >> > > > far as I know , other SDOs and also other carriers, not only DT, >> > > > already use/refer the Session-ID. >> > > > >> > > > Comment to the draft: >> > > > - I am OK with allowing other algorithms than Call-ID >> > hash. However, >> > > > the description of the hash algorithm in the 00 version was very >> > > > usefull and avoided problems with different algorithms >> > being used by >> > > > the B2BUA and monitoring systems. I don't see any reason for not >> > > > including it as an implementation example. >> > > > >> > > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new >> > header field >> > > > provides an identifier for troubleshooting uses only." >> > > > =A0Implementations and other SDOs (I know of 3GPP) already use >> > > > Session-ID for SIP-services as Conferencing, to correlate >> > both legs of >> > > > a dialog across a B2BUA. There is no other SIP-identifier >> > they can use >> > > > for this. So my proposal is to allow this in the Session-ID draft. >> > > > Otherwise we either have inconcistency between IETF and >> > IMS documents. >> > > > >> > > > Kind regards >> > > > Laura >> > > > >> > > > >> > > > >> > > > >> > > > 2010/4/17 Hadriel Kaplan : >> > > >> Howdy, >> > > >> Based on discussions at IETF-76, I have submitted an >> > updated draft- >> > > kaplan-dispatch-session-id-01. >> > > >> >> > > >> Pursuant to the changed rules for SIP header field >> > registration in RFC >> > > 5727, I have changed the draft to be Informational and I'm >> > fine with going >> > > the Individual submission path instead of a WG, if there is >> > no interest >> > > for this to be DISPATCHed elsewhere. =A0I believe this >> > document complies >> > > with the intent of RFC 5727. >> > > >> >> > > >> Comments/concerns/flames are appreciated. >> > > >> >> > > >> The main changes since last version: >> > > >> - changed it to be Informational, and put in text for rfc5727. >> > > >> - removed the specific hash algorithm for the generated >> > value, to make >> > > it easier for folks to just use a random number/algorithm >> > > >> - changed it to be 16-chars of hex ascii (0-9a-f), so a >> > 64-bit binary >> > > number can be generated/recorded/used >> > > >> - relaxed the requirements on B2BUA's so that the >> > generation of it is >> > > optional, but pass-through/copy is still mandatory >> > > >> >> > > >>> -----Original Message----- >> > > >> A New Internet-Draft is available from the on-line >> > Internet-Drafts >> > > directories. >> > > >> >> > > >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Session Identifier f= or the Session >> > > Initiation Protocol (SIP) >> > > >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan >> > > >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-dispatch-se= ssion-id-01.txt >> > > >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 >> > > >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-04-17 >> > > >> >> > > >> There is a need for having a globally unique session >> > identifier for the >> > > same SIP session, which can be consistently maintained >> > across Proxies, >> > > B2BUAs and other SIP middle-boxes, for the purpose of >> > > Troubleshooting. =A0This draft proposes a new SIP header to >> > carry such a >> > > value: Session-ID. >> > > >> >> > > >> A URL for this Internet-Draft is: >> > > >> >> > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- >> > > 01.txt >> > > >> >> > > >> Internet-Drafts are also available by anonymous FTP at: >> > > >> ftp://ftp.ietf.org/internet-drafts/ >> > > >> >> > > >> >> > > >> _______________________________________________ >> > > >> dispatch mailing list >> > > >> dispatch@ietf.org >> > > >> https://www.ietf.org/mailman/listinfo/dispatch >> > > >> >> > > > _______________________________________________ >> > > > dispatch mailing list >> > > > dispatch@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/dispatch >> > > > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jmpolk@cisco.com Wed Apr 21 14:10:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0848C3A6AF7 for ; Wed, 21 Apr 2010 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8cHqEhK1Y9c for ; Wed, 21 Apr 2010 14:10:53 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AFDE83A68F1 for ; Wed, 21 Apr 2010 14:10:52 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAMHz0urR7H+/2dsb2JhbACcE3GjM5o3gl+CMASDNA X-IronPort-AV: E=Sophos;i="4.52,252,1270425600"; d="scan'208";a="186490411" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2010 21:10:42 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3LLAf4a003108; Wed, 21 Apr 2010 21:10:42 GMT Message-Id: <201004212110.o3LLAf4a003108@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Apr 2010 16:10:41 -0500 To: Hans Erik van Elburg , Hadriel Kaplan From: "James M. Polk" In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A79FCF3D0@mail> <201004211549.o3LFnHbb019972@sj-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , Roland Jesske , =?iso-8859-1?Q?H=FClsemann?= , Martin@core3.amsl.com, Laura Liess Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 21:10:56 -0000 At 11:53 AM 4/21/2010, Hans Erik van Elburg wrote: >Since the dark days that RFC3261 seen the light a >dialog-creating-INVITE or out-of-dialog INVITE is called an "initial >INVITE" and an in-dialog INVITE is called a re-INVITE. I prefer those >ancient well understood terms over the new ones used in this >conversation. > >Initial INVITEs create dialogs, that is what they do, re-INVITEs don't. these "old terms" work too ;-) I was just evaluating Hadriel's two new terms... James >Initial INVITEs belong to the class of "initial requests for a dialog" >and hence also to "initial requests", re-INVITEs to the class of >"in-dialog requests" or "subsequent requests". > >The term out-of-dialog request seems problematic as it assumes the >existence of a dialog where one might not exist. > >/Hans Erik van Elburg > >On Wed, Apr 21, 2010 at 5:49 PM, James M. Polk wrote: > > At 03:52 AM 4/21/2010, Elwell, John wrote: > >> > >> I don't have a problem with "out-of-dialog" request (meaning any= request > >> that is not mid-dialog). The term=20 > "dialog-creating" doesn't work if you want > >> to include things that don't create dialogs,=20 > e.g., PUBLISH, MESSAGE. In this > >> particular draft, if we are only referring to INVITE, I guess it= doesn't > >> matter. > > > > "dialog-creating" INVITE is MUCH preferred over "out-of-dialog" INVITE,= as > > some will not easily understand the latter - and be easily confused when > > this appears. It's just not that intuitive (at least to me as well). > > > > Someone reading "dialog-creating" INVITE could say to themselves "duh,= it's > > an INVITE always creating a dialog?" > > > > redundancy is better than something less clear > > > > James > > > > > >> John > >> > >> > -----Original Message----- > >> > From: dispatch-bounces@ietf.org > >> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > >> > Sent: 21 April 2010 05:45 > >> > To: Peter Musgrave; Laura Liess > >> > Cc: dispatch@ietf.org; Martin H=FClsemann; Roland Jesske > >> > Subject: Re: [dispatch] New version: > >> > draft-kaplan-dispatch-session-id-01 > >> > > >> > > >> > Hi Peter, > >> > Yeah I should probably change that term to dialog-creating, > >> > and will do so for the next rev. (I see and use the term > >> > "out-of-dialog request" all the time to refer to any request > >> > that's not in a dialog, including dialog-creating INVITE and > >> > SUBSCRIBE, but if it confuses people it's easy to change :) > >> > > >> > -hadriel > >> > > >> > > >> > > -----Original Message----- > >> > > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > >> > > Sent: Tuesday, April 20, 2010 9:09 AM > >> > > To: Laura Liess > >> > > > >> > > Hi Hadriel, > >> > > > >> > > I am interested in the draft. > >> > > > >> > > One thing that confused me (and maybe I'm just easily confused) was > >> > > the term 'out-of-dialog INVITE' in the Example (Section 7). I'm > >> > > inferring this is an INVITE which starts a dialog (i.e. has no To: > >> > > tag). I would have referred to this as a dialog-creating INVITE. Is > >> > > 'out-of-dialog INVITE' a standard term? (I tend to to thing > >> > of methods > >> > > like MESSAGE when I read "out-of-dialog") > >> > > > >> > > Peter Musgrave > >> > > > >> > > On Tue, Apr 20, 2010 at 8:27 AM, Laura Liess > >> > > wrote: > >> > > > Hadriel, > >> > > > > >> > > > I don't think that there is no interest for the draft to be > >> > > > DISPATCHed. We had a lot of discussion on it in the past. > >> > It's just > >> > > > that people are busy and the current DISPATCH process > >> > requires a lot > >> > > > of overhead (charter, chairs...). In principle, I am OK > >> > with any way > >> > > > to get the Session-ID to RFC. Proposed Standard or > >> > Informational. As > >> > > > far as I know , other SDOs and also other carriers, not only DT, > >> > > > already use/refer the Session-ID. > >> > > > > >> > > > Comment to the draft: > >> > > > - I am OK with allowing other algorithms than Call-ID > >> > hash. However, > >> > > > the description of the hash algorithm in the 00 version was very > >> > > > usefull and avoided problems with different algorithms > >> > being used by > >> > > > the B2BUA and monitoring systems. I don't see any reason for not > >> > > > including it as an implementation example. > >> > > > > >> > > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new > >> > header field > >> > > > provides an identifier for troubleshooting uses only." > >> > > > Implementations and other SDOs (I know of 3GPP) already use > >> > > > Session-ID for SIP-services as Conferencing, to correlate > >> > both legs of > >> > > > a dialog across a B2BUA. There is no other SIP-identifier > >> > they can use > >> > > > for this. So my proposal is to allow this in the Session-ID= draft. > >> > > > Otherwise we either have inconcistency between IETF and > >> > IMS documents. > >> > > > > >> > > > Kind regards > >> > > > Laura > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > 2010/4/17 Hadriel Kaplan : > >> > > >> Howdy, > >> > > >> Based on discussions at IETF-76, I have submitted an > >> > updated draft- > >> > > kaplan-dispatch-session-id-01. > >> > > >> > >> > > >> Pursuant to the changed rules for SIP header field > >> > registration in RFC > >> > > 5727, I have changed the draft to be Informational and I'm > >> > fine with going > >> > > the Individual submission path instead of a WG, if there is > >> > no interest > >> > > for this to be DISPATCHed elsewhere. I believe this > >> > document complies > >> > > with the intent of RFC 5727. > >> > > >> > >> > > >> Comments/concerns/flames are appreciated. > >> > > >> > >> > > >> The main changes since last version: > >> > > >> - changed it to be Informational, and put in text for rfc5727. > >> > > >> - removed the specific hash algorithm for the generated > >> > value, to make > >> > > it easier for folks to just use a random number/algorithm > >> > > >> - changed it to be 16-chars of hex ascii (0-9a-f), so a > >> > 64-bit binary > >> > > number can be generated/recorded/used > >> > > >> - relaxed the requirements on B2BUA's so that the > >> > generation of it is > >> > > optional, but pass-through/copy is still mandatory > >> > > >> > >> > > >>> -----Original Message----- > >> > > >> A New Internet-Draft is available from the on-line > >> > Internet-Drafts > >> > > directories. > >> > > >> > >> > > >> Title : A Session Identifier for the Session > >> > > Initiation Protocol (SIP) > >> > > >> Author(s) : H. Kaplan > >> > > >> Filename : draft-kaplan-dispatch-session-id-01.txt > >> > > >> Pages : 11 > >> > > >> Date : 2010-04-17 > >> > > >> > >> > > >> There is a need for having a globally unique session > >> > identifier for the > >> > > same SIP session, which can be consistently maintained > >> > across Proxies, > >> > > B2BUAs and other SIP middle-boxes, for the purpose of > >> > > Troubleshooting. This draft proposes a new SIP header to > >> > carry such a > >> > > value: Session-ID. > >> > > >> > >> > > >> A URL for this Internet-Draft is: > >> > > >> > >> > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- > >> > > 01.txt > >> > > >> > >> > > >> Internet-Drafts are also available by anonymous FTP at: > >> > > >> ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > >> > > >> > >> > > >> _______________________________________________ > >> > > >> dispatch mailing list > >> > > >> dispatch@ietf.org > >> > > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > >> > >> > > > _______________________________________________ > >> > > > dispatch mailing list > >> > > > dispatch@ietf.org > >> > > > https://www.ietf.org/mailman/listinfo/dispatch > >> > > > > >> > _______________________________________________ > >> > dispatch mailing list > >> > dispatch@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dispatch > >> > > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From bruno.chatras@orange-ftgroup.com Fri Apr 23 01:53:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F5B3A69C1; Fri, 23 Apr 2010 01:53:55 -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=0.000, BAYES_00=-2.599, HELO_EQ_FR=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 c+IfmrPpJ2zk; Fri, 23 Apr 2010 01:53:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 7B8953A693D; Fri, 23 Apr 2010 01:53:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 35CEE6FCC09; Fri, 23 Apr 2010 10:54:13 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 2BD0A6FCC07; Fri, 23 Apr 2010 10:54:13 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Apr 2010 10:53: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, 23 Apr 2010 10:53:42 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141015EFC76@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] Proposed SIP Overload Control Charter Thread-Index: AcrhaivcAWXJruR7Rqq508h/XZIohQBWCz5Q References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com><4BB5409E.5080108@alcatel-lucent.com><0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com> <6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> From: To: X-OriginalArrivalTime: 23 Apr 2010 08:53:43.0723 (UTC) FILETIME=[7A5257B0:01CAE2C2] X-Mailman-Approved-At: Fri, 23 Apr 2010 06:58:12 -0700 Cc: volker.hilt@alcatel-lucent.com, dispatch@ietf.org, sip-overload@ietf.org, lars.eggert@nokia.com Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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, 23 Apr 2010 08:53:55 -0000 I would prefer to see the SIP load filtering specification released by = the end of 2010.=20 BC > -----Message d'origine----- > De : sip-overload-bounces@ietf.org=20 > [mailto:sip-overload-bounces@ietf.org] De la part de Robert Sparks > Envoy=E9 : mercredi 21 avril 2010 17:29 > =C0 : Robert Sparks > Cc : Volker Hilt; DISPATCH; sip-overload@ietf.org; Gonzalo=20 > Camarillo; Lars Eggert > Objet : Re: [sip-overload] Proposed SIP Overload Control Charter >=20 > Please comment on what these dates should actually be=20 >=20 > RjS >=20 > > Milestones: > >=20 > > Sep 2010 Design Considerations to IESG for publication as=20 > > Informational Dec 2010 Specification for a SIP overload control=20 > > mechanism based on implicit/explicit feedback to IESG for=20 > publication=20 > > as Proposed Standard May 2011 Specification for a SIP load=20 > filtering=20 > > mechaism to IESG for publication as Proposed Standard >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >=20 From HKaplan@acmepacket.com Fri Apr 23 08:55:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D757B3A6A6F for ; Fri, 23 Apr 2010 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKOvorA4PhwM for ; Fri, 23 Apr 2010 08:55:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CFE403A6A3F for ; Fri, 23 Apr 2010 08:55:07 -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, 23 Apr 2010 11:54:56 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Apr 2010 11:54:56 -0400 From: Hadriel Kaplan To: Laura Liess Date: Fri, 23 Apr 2010 11:54:55 -0400 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: AcrghNSIVIQt/+GhTb+leWQ15T6rEACdyIyA Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , =?iso-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:55:08 -0000 Hi Laura, Comments inline... > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Tuesday, April 20, 2010 8:27 AM > To: Hadriel Kaplan >=20 > I don't think that there is no interest for the draft to be > DISPATCHed. We had a lot of discussion on it in the past. It's just > that people are busy and the current DISPATCH process requires a lot > of overhead (charter, chairs...).=20 Sorry I should have been clearer - I didn't mean no interest in it, I meant= no interest in DISPATCHing it to an existing WG. (and I definitely do NOT = think it warrants a new WG :) > Comment to the draft: > - I am OK with allowing other algorithms than Call-ID hash. However, > the description of the hash algorithm in the 00 version was very > usefull and avoided problems with different algorithms being used by > the B2BUA and monitoring systems. I don't see any reason for not > including it as an implementation example. The concept of specifying the algorithm was only to guarantee the value wou= ldn't reveal which vendor had created it. But it wouldn't have made it pos= sible for a monitoring system to determine the session-id value for message= s which don't already have a session-id, because the hash used a private ke= y unique to every system. In other words, two different systems would gene= rate two different Session-IDs for the same Call-ID. That was by design. So since it was only to avoid revealing the vendor, I got comments back tha= t a random number would be good enough for that, and reduce the work/perfor= mance-hit of doing a strong hash. =20 > - Chapter 3. Overview, 3-rd paragraph: "Instead this new header field > provides an identifier for troubleshooting uses only." > Implementations and other SDOs (I know of 3GPP) already use > Session-ID for SIP-services as Conferencing, to correlate both legs of > a dialog across a B2BUA. There is no other SIP-identifier they can use > for this. So my proposal is to allow this in the Session-ID draft. > Otherwise we either have inconcistency between IETF and IMS documents. Is there a doc I can go look at which describes how they're going to use it= ? -hadriel From andrew.hutton@siemens-enterprise.com Mon Apr 26 02:50:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3103A6ADB for ; Mon, 26 Apr 2010 02:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_50=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 xsVCVmxZ+-nT for ; Mon, 26 Apr 2010 02:50:21 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 111E53A6AFF for ; Mon, 26 Apr 2010 02:50:18 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1669860; Mon, 26 Apr 2010 11:50:06 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id AC57A23F028E; Mon, 26 Apr 2010 11:50:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 26 Apr 2010 11:50:06 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan , Laura Liess Date: Mon, 26 Apr 2010 11:50:05 +0200 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: AcrghNSIVIQt/+GhTb+leWQ15T6rEACdyIyAAIodCgA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3070B172455@MCHP058A.global-ad.net> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> 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" , =?iso-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:50:22 -0000 Hi, I also think this draft has many more uses than just troubleshooting I know= for example it has been discussed as being potentially useful to the SIPRE= C work. For this reason I would like to see the draft published as Standards Track. Regards Andy =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 23 April 2010 16:55 > To: Laura Liess > Cc: dispatch@ietf.org; Martin H=FClsemann; Roland Jesske > Subject: Re: [dispatch] New version:=20 > draft-kaplan-dispatch-session-id-01 >=20 > Hi Laura, > Comments inline... >=20 > > -----Original Message----- > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > Sent: Tuesday, April 20, 2010 8:27 AM > > To: Hadriel Kaplan > >=20 > > I don't think that there is no interest for the draft to be > > DISPATCHed. We had a lot of discussion on it in the past. It's just > > that people are busy and the current DISPATCH process requires a lot > > of overhead (charter, chairs...).=20 >=20 > Sorry I should have been clearer - I didn't mean no interest=20 > in it, I meant no interest in DISPATCHing it to an existing=20 > WG. (and I definitely do NOT think it warrants a new WG :) >=20 >=20 > > Comment to the draft: > > - I am OK with allowing other algorithms than Call-ID hash. However, > > the description of the hash algorithm in the 00 version was very > > usefull and avoided problems with different algorithms being used by > > the B2BUA and monitoring systems. I don't see any reason for not > > including it as an implementation example. >=20 > The concept of specifying the algorithm was only to guarantee=20 > the value wouldn't reveal which vendor had created it. But=20 > it wouldn't have made it possible for a monitoring system to=20 > determine the session-id value for messages which don't=20 > already have a session-id, because the hash used a private=20 > key unique to every system. In other words, two different=20 > systems would generate two different Session-IDs for the same=20 > Call-ID. That was by design. >=20 > So since it was only to avoid revealing the vendor, I got=20 > comments back that a random number would be good enough for=20 > that, and reduce the work/performance-hit of doing a strong hash. > =20 >=20 > > - Chapter 3. Overview, 3-rd paragraph: "Instead this new=20 > header field > > provides an identifier for troubleshooting uses only." > > Implementations and other SDOs (I know of 3GPP) already use > > Session-ID for SIP-services as Conferencing, to correlate=20 > both legs of > > a dialog across a B2BUA. There is no other SIP-identifier=20 > they can use > > for this. So my proposal is to allow this in the Session-ID draft. > > Otherwise we either have inconcistency between IETF and IMS=20 > documents. >=20 > Is there a doc I can go look at which describes how they're=20 > going to use it? >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From peter.musgrave@magorcorp.com Mon Apr 26 03:20:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3713A6B78 for ; Mon, 26 Apr 2010 03:20:45 -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 5PYLFjWRMLCQ for ; Mon, 26 Apr 2010 03:20:44 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4586B3A693C for ; Mon, 26 Apr 2010 03:19:46 -0700 (PDT) Received: by gwaa12 with SMTP id a12so2847172gwa.31 for ; Mon, 26 Apr 2010 03:19:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.248.3 with SMTP id v3mr4033000ybh.82.1272277170828; Mon, 26 Apr 2010 03:19:30 -0700 (PDT) Received: by 10.150.92.9 with HTTP; Mon, 26 Apr 2010 03:19:30 -0700 (PDT) In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3070B172455@MCHP058A.global-ad.net> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> <101C6067BEC68246B0C3F6843BCCC1E3070B172455@MCHP058A.global-ad.net> Date: Mon, 26 Apr 2010 06:19:30 -0400 Message-ID: From: Peter Musgrave To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Roland Jesske , "dispatch@ietf.org" , Laura Liess , Hadriel Kaplan , =?ISO-8859-1?Q?Martin_H=FClsemann?= Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:20:46 -0000 Hi, I too would like to see this standards track. I already have plans to use it for some internal call logging (and I can see it's value to siprec also). Regards, Peter On Mon, Apr 26, 2010 at 5:50 AM, Hutton, Andrew wrote: > Hi, > > I also think this draft has many more uses than just troubleshooting I kn= ow for example it has been discussed as being potentially useful to the SIP= REC work. > > For this reason I would like to see the draft published as Standards Trac= k. > > Regards > Andy > > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan >> Sent: 23 April 2010 16:55 >> To: Laura Liess >> Cc: dispatch@ietf.org; Martin H=FClsemann; Roland Jesske >> Subject: Re: [dispatch] New version: >> draft-kaplan-dispatch-session-id-01 >> >> Hi Laura, >> Comments inline... >> >> > -----Original Message----- >> > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> > Sent: Tuesday, April 20, 2010 8:27 AM >> > To: Hadriel Kaplan >> > >> > I don't think that there is no interest for the draft to be >> > DISPATCHed. We had a lot of discussion on it in the past. It's just >> > that people are busy and the current DISPATCH process requires a lot >> > of overhead (charter, chairs...). >> >> Sorry I should have been clearer - I didn't mean no interest >> in it, I meant no interest in DISPATCHing it to an existing >> WG. (and I definitely do NOT think it warrants a new WG :) >> >> >> > Comment to the draft: >> > - I am OK with allowing other algorithms than Call-ID hash. However, >> > the description of the hash algorithm in the 00 version was very >> > usefull and avoided problems with different algorithms being used by >> > the B2BUA and monitoring systems. I don't see any reason for not >> > including it as an implementation example. >> >> The concept of specifying the algorithm was only to guarantee >> the value wouldn't reveal which vendor had created it. =A0But >> it wouldn't have made it possible for a monitoring system to >> determine the session-id value for messages which don't >> already have a session-id, because the hash used a private >> key unique to every system. =A0In other words, two different >> systems would generate two different Session-IDs for the same >> Call-ID. =A0That was by design. >> >> So since it was only to avoid revealing the vendor, I got >> comments back that a random number would be good enough for >> that, and reduce the work/performance-hit of doing a strong hash. >> >> >> > - Chapter 3. Overview, 3-rd paragraph: "Instead this new >> header field >> > provides an identifier for troubleshooting uses only." >> > =A0Implementations and other SDOs (I know of 3GPP) already use >> > Session-ID for SIP-services as Conferencing, to correlate >> both legs of >> > a dialog across a B2BUA. There is no other SIP-identifier >> they can use >> > for this. So my proposal is to allow this in the Session-ID draft. >> > Otherwise we either have inconcistency between IETF and IMS >> documents. >> >> Is there a doc I can go look at which describes how they're >> going to use it? >> >> -hadriel >> _______________________________________________ >> 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 Markus.Isomaki@nokia.com Mon Apr 26 03:25:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128C33A6B88 for ; Mon, 26 Apr 2010 03:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.136 X-Spam-Level: X-Spam-Status: No, score=-5.136 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_40=-0.185, 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 vxxmPjQN5IF8 for ; Mon, 26 Apr 2010 03:25:19 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 53B753A694C for ; Mon, 26 Apr 2010 03:22:39 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3QAMKBi028724 for ; Mon, 26 Apr 2010 13:22:24 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 13:22:22 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 13:22:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 13:22:13 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 26 Apr 2010 12:22:12 +0200 From: To: Date: Mon, 26 Apr 2010 12:22:11 +0200 Thread-Topic: Updated SIP and XMPP combined use charter proposal Thread-Index: AcrlKQPtOt/rA4cnTKmO7otAcL/pfQAASLrg 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 X-OriginalArrivalTime: 26 Apr 2010 10:22:13.0708 (UTC) FILETIME=[568F00C0:01CAE52A] X-Nokia-AV: Clean Subject: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:25:21 -0000 Hi, This got stuck in DISPATCH moderator queue due to too many recipients, so I= 'm forwarding it separately. Markus >-----Original Message----- >From: Isomaki Markus (Nokia-CIC/Espoo)=20 >Sent: 26 April, 2010 13:13 >To: Robert Sparks; 'ext Peter Saint-Andre'; 'ext Gonzalo=20 >Camarillo'; emcho@sip-communicator.org; 'ext Elwell, John';=20 >'rifatyu@avaya.com'; 'ben@nostrum.com';=20 >'joe.hildebrandt@webex.com'; 'adam@nostrum.com';=20 >'spencer@wonderhamster.com'; 'mbarnes@nortelnetworks.com';=20 >Veikkolainen Simo (Nokia-D/Helsinki); 'enrico.marocco@telecomitalia.it' >Cc: dispatch@ietf.org >Subject: Updated SIP and XMPP combined use charter proposal > >Hi all, > >We held a DISPATCH mini-BoF on SIP and XMPP combined use back=20 >at the November IETF with a fair amount of interest. A charter=20 >proposal was discussed around December/January, and most=20 >people on DISPATCH were happy with the outcome. After that the=20 >activity has been limited but there have been discussions with=20 >the ADs and some interested folks how the charter proposal=20 >should be updated to make it more clear what the mini-WG would=20 >be about, and especially what is out of scope. Several people=20 >were asking me about the topic before or during Anaheim IETF=20 >so I expect the interest for this is still relatively high and=20 >we should go forward. > >Based on the feedback Simo and myself have drafted an updated=20 >charter proposal, see below.=20 > >The use cases and requirements draft has also been updated: >http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/ > >Also, Emil and Enrico submitted a draft on provisioning BCP: >http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/ > >Please comment especially on the charter if it looks clear and=20 >concise enough. > >Regards, > Markus=20 > > >Combining SIP Voice and Video with XMPP IM and Presence=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >Session Initiation Protocol (SIP) and Extensible Messaging and=20 >Presence Protocol (XMPP) are both enjoying a widespread=20 >deployment over the Internet. SIP was originally intended for=20 >setting up real-time media sessions, while XMPP's roots are=20 >with instant messaging (IM) and presence. While both protocols=20 >have mushroomed in functionality, the real deployments still=20 >correlate highly with their original scope; SIP is mostly used=20 >for voice and video and for interconnect with circuit switched=20 >telephony systems, while most of XMPP deployments offer IM and=20 >presence services. So far the success with fully integrated=20 >voice, video, IM and presence services with either SIP or XMPP=20 >has been limited.=20 > >One approach to make the best out of this situation is to=20 >integrate a SIP User Agent and an XMPP client into a single=20 >application. The application would use SIP for voice and video=20 >and XMPP for IM and presence. The best part of this approach=20 >would be that no changes to existing SIP or XMPP server=20 >infrastructures would be required, and there would be no=20 >issues with interoperability between the integrated endpoints=20 >and ordinary SIP- or XMPP-only endpoints. This would enable=20 >incremental deployment, which is an important success factor.=20 >In this "fully independent" form no new SIP or XMPP standards=20 >extensions would be either needed. > >When two integrated SIP and XMPP endpoints communicate with=20 >each other, it would be possible to make the user experience=20 >even more seamless by making the two protocols more "aware" of=20 >each other through minor protocol extensions. For instance an=20 >incoming SIP voice call could be explicitly correlated with an=20 >ongoing IM exchange, or XMPP presence could include explicit=20 >SIP voice availability status. For the sake of deployment=20 >feasibility, it would be mandatory for such protocol=20 >extensions not to require any changes to SIP or XMPP server=20 >implementations, and to remain backwards compatible with=20 >non-updated SIP and XMPP endpoints.=20 > >The objective of this Working Group is to document best=20 >practices and develop protocol extensions for combining SIP=20 >based voice and video with XMPP based IM and presence such=20 >that a unified user experience can be offered to end user.=20 > >Specifically, the WG will address the following use cases:=20 >- User identifier discovery; it should be possible for a=20 >user to learn other user's SIP identifier based on her XMPP=20 >identifier and vice versa for future use without needing to=20 >engage in an active communication session with the other user.=20 >Mapping of address schemes (sip:, xmpp:, im:, pres: etc.) is=20 >out of scope of this Working Group.=20 >- Presence integration; it should be possible for user's=20 >XMPP presence status to explicitly include her capability and=20 >willingness for SIP based voice and video communication. It is=20 >desired that only XMPP presence extension mechanisms described=20 >in RFC3921 or its successor are used; presence format=20 >translation and mapping are out of scope of this Working Group. >- Session or conversation capability discovery and=20 >correlation; it should be possible to combine XMPP IM with SIP=20 >voice and video communication between two endpoints so that=20 >the endpoints can discover each others' capabilities and=20 >explicitly relate the communication across the two protocols. =20 >- Provisioning; it should be possible to configure=20 >integrated SIP and XMPP endpoints with as small extra burden=20 >as possible compared to SIP- or XMPP-only endpoints,=20 >especially if both SIP and XMPP are offered by the same=20 >service provider. However, it is desired that no protocol=20 >changes are needed for this. Also, cross-domain authentication=20 >is out of scope of this Working Group. > >The protocol extensions developed in the WG must meet the=20 >following criteria: >- The extensions must work without changes to SIP or XMPP=20 >server infrastructures (including typical SIP B2BUAs), and=20 >across SIP and XMPP deployments that are independent from each=20 >other (such as that they are offered by two different=20 >non-coordinated domains).=20 >- The extensions must not break backwards compatibility=20 >with non-updated SIP and XMPP endpoints. > >The following is out of scope of the initial charter of the WG:=20 >- Multiparty communication, for instance the combined use=20 >of SIP voice conferencing and XMPP IM chatrooms.=20 >- Advanced services such as SIP session transfer combined=20 >with XMPP IM.=20 >- Protocol interworking, that is, translation gateways from=20 >SIP to XMPP or vice versa.=20 >- New routing logic; the WG should rely on existing routing=20 >mechanisms defined for SIP and XMPP, and not define=20 >cross-domain routing for example in case when a user's SIP AOR=20 >is known but that user is not registered for SIP service. > >Milestones > >Dec 2010 Use cases and protocol requirements document=20 >submitted to IESG (Informational). > >Aug 2011 Document defining mechanisms for discovering user's=20 >SIP identifier based on her XMPP identifier submitted to IESG=20 >(Standards Track). > >Aug 2011 Document defining XMPP presence extensions for SIP=20 >voice and video communication capability and willingness=20 >submitted to IESG (Standards Track). > >Aug 2011 Document defining protocol extensions that allow=20 >combined SIP voice and video and XMPP IM capable endpoints to=20 >discover each others' capabilities and correlate their=20 >communication across the two protocols submitted to IESG=20 >(Standards Track). > >Aug 2011 Document defining best practises document for=20 >configuration and provisioning of combined SIP and XMPP=20 >endpoints submitted to IESG (BCP).= From Markus.Isomaki@nokia.com Mon Apr 26 03:14:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526273A6B74 for ; Mon, 26 Apr 2010 03:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.192 X-Spam-Level: X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_50=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 Sb2BeJCbV+AD for ; Mon, 26 Apr 2010 03:14:37 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AC73C3A6B64 for ; Mon, 26 Apr 2010 03:13:29 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3QACrnW022553; Mon, 26 Apr 2010 05:13:12 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 13:13:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 13:12:55 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 26 Apr 2010 12:12:55 +0200 From: To: , , , , , , , , , , , , Date: Mon, 26 Apr 2010 12:12:45 +0200 Thread-Topic: Updated SIP and XMPP combined use charter proposal Thread-Index: AcrlKQPtOt/rA4cnTKmO7otAcL/pfQ== 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 X-OriginalArrivalTime: 26 Apr 2010 10:12:55.0589 (UTC) FILETIME=[09E4CD50:01CAE529] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 26 Apr 2010 05:34:37 -0700 Cc: dispatch@ietf.org Subject: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:14:40 -0000 Hi all, We held a DISPATCH mini-BoF on SIP and XMPP combined use back at the Novemb= er IETF with a fair amount of interest. A charter proposal was discussed ar= ound December/January, and most people on DISPATCH were happy with the outc= ome. After that the activity has been limited but there have been discussio= ns with the ADs and some interested folks how the charter proposal should b= e updated to make it more clear what the mini-WG would be about, and especi= ally what is out of scope. Several people were asking me about the topic be= fore or during Anaheim IETF so I expect the interest for this is still rela= tively high and we should go forward. Based on the feedback Simo and myself have drafted an updated charter propo= sal, see below.=20 The use cases and requirements draft has also been updated: http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/ Also, Emil and Enrico submitted a draft on provisioning BCP: http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/ Please comment especially on the charter if it looks clear and concise enou= gh. Regards, Markus=20 Combining SIP Voice and Video with XMPP IM and Presence =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Session Initiation Protocol (SIP) and Extensible Messaging and Presence Pro= tocol (XMPP) are both enjoying a widespread deployment over the Internet. S= IP was originally intended for setting up real-time media sessions, while X= MPP's roots are with instant messaging (IM) and presence. While both protoc= ols have mushroomed in functionality, the real deployments still correlate = highly with their original scope; SIP is mostly used for voice and video an= d for interconnect with circuit switched telephony systems, while most of X= MPP deployments offer IM and presence services. So far the success with ful= ly integrated voice, video, IM and presence services with either SIP or XMP= P has been limited.=20 One approach to make the best out of this situation is to integrate a SIP U= ser Agent and an XMPP client into a single application. The application wou= ld use SIP for voice and video and XMPP for IM and presence. The best part = of this approach would be that no changes to existing SIP or XMPP server in= frastructures would be required, and there would be no issues with interope= rability between the integrated endpoints and ordinary SIP- or XMPP-only en= dpoints. This would enable incremental deployment, which is an important su= ccess factor. In this "fully independent" form no new SIP or XMPP standards= extensions would be either needed. When two integrated SIP and XMPP endpoints communicate with each other, it = would be possible to make the user experience even more seamless by making = the two protocols more "aware" of each other through minor protocol extensi= ons. For instance an incoming SIP voice call could be explicitly correlated= with an ongoing IM exchange, or XMPP presence could include explicit SIP v= oice availability status. For the sake of deployment feasibility, it would = be mandatory for such protocol extensions not to require any changes to SIP= or XMPP server implementations, and to remain backwards compatible with no= n-updated SIP and XMPP endpoints.=20 The objective of this Working Group is to document best practices and devel= op protocol extensions for combining SIP based voice and video with XMPP ba= sed IM and presence such that a unified user experience can be offered to e= nd user.=20 Specifically, the WG will address the following use cases:=20 - User identifier discovery; it should be possible for a user to learn o= ther user's SIP identifier based on her XMPP identifier and vice versa for = future use without needing to engage in an active communication session wit= h the other user. Mapping of address schemes (sip:, xmpp:, im:, pres: etc.)= is out of scope of this Working Group.=20 - Presence integration; it should be possible for user's XMPP presence s= tatus to explicitly include her capability and willingness for SIP based vo= ice and video communication. It is desired that only XMPP presence extensio= n mechanisms described in RFC3921 or its successor are used; presence forma= t translation and mapping are out of scope of this Working Group. - Session or conversation capability discovery and correlation; it shoul= d be possible to combine XMPP IM with SIP voice and video communication bet= ween two endpoints so that the endpoints can discover each others' capabili= ties and explicitly relate the communication across the two protocols. =20 - Provisioning; it should be possible to configure integrated SIP and XM= PP endpoints with as small extra burden as possible compared to SIP- or XMP= P-only endpoints, especially if both SIP and XMPP are offered by the same s= ervice provider. However, it is desired that no protocol changes are needed= for this. Also, cross-domain authentication is out of scope of this Workin= g Group. The protocol extensions developed in the WG must meet the following criteri= a: - The extensions must work without changes to SIP or XMPP server infrast= ructures (including typical SIP B2BUAs), and across SIP and XMPP deployment= s that are independent from each other (such as that they are offered by tw= o different non-coordinated domains).=20 - The extensions must not break backwards compatibility with non-updated= SIP and XMPP endpoints. The following is out of scope of the initial charter of the WG:=20 - Multiparty communication, for instance the combined use of SIP voice c= onferencing and XMPP IM chatrooms.=20 - Advanced services such as SIP session transfer combined with XMPP IM.= =20 - Protocol interworking, that is, translation gateways from SIP to XMPP = or vice versa.=20 - New routing logic; the WG should rely on existing routing mechanisms d= efined for SIP and XMPP, and not define cross-domain routing for example in= case when a user's SIP AOR is known but that user is not registered for SI= P service. Milestones Dec 2010 Use cases and protocol requirements document submitted to IESG (In= formational). Aug 2011 Document defining mechanisms for discovering user's SIP identifie= r based on her XMPP identifier submitted to IESG (Standards Track). Aug 2011 Document defining XMPP presence extensions for SIP voice and video= communication capability and willingness submitted to IESG (Standards Trac= k). Aug 2011 Document defining protocol extensions that allow combined SIP voic= e and video and XMPP IM capable endpoints to discover each others' capabili= ties and correlate their communication across the two protocols submitted t= o IESG (Standards Track). Aug 2011 Document defining best practises document for configuration and pr= ovisioning of combined SIP and XMPP endpoints submitted to IESG (BCP).= From john.elwell@siemens-enterprise.com Mon Apr 26 03:39:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5964A3A68BF for ; Mon, 26 Apr 2010 03:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 rPCTTzWqBmsa for ; Mon, 26 Apr 2010 03:39:52 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 909423A6808 for ; Mon, 26 Apr 2010 03:39:51 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1669474; Mon, 26 Apr 2010 12:39:36 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2C90823F0278; Mon, 26 Apr 2010 12:39:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 26 Apr 2010 12:39:36 +0200 From: "Elwell, John" To: "Markus.Isomaki@nokia.com" , "rjsparks@nostrum.com" , "stpeter@stpeter.im" , "Gonzalo.Camarillo@ericsson.com" , "emcho@sip-communicator.org" , "rifatyu@avaya.com" , "ben@nostrum.com" , "joe.hildebrandt@webex.com" , "adam@nostrum.com" , "spencer@wonderhamster.com" , "mbarnes@nortelnetworks.com" , "Simo.Veikkolainen@nokia.com" , "enrico.marocco@telecomitalia.it" Date: Mon, 26 Apr 2010 12:39:34 +0200 Thread-Topic: Updated SIP and XMPP combined use charter proposal Thread-Index: AcrlKQPtOt/rA4cnTKmO7otAcL/pfQAA2Gkg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 26 Apr 2010 05:34:37 -0700 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:39:53 -0000 Markus, Looks good in general. "Mapping of address schemes (sip:, xmpp:, im:, pres: etc.) is out of scope = of this Working Group." That's fine, but shouldn't this also be mentioned later in the list of out = of scope topics? John=20 > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > Sent: 26 April 2010 11:13 > To: rjsparks@nostrum.com; stpeter@stpeter.im;=20 > Gonzalo.Camarillo@ericsson.com; emcho@sip-communicator.org;=20 > Elwell, John; rifatyu@avaya.com; ben@nostrum.com;=20 > joe.hildebrandt@webex.com; adam@nostrum.com;=20 > spencer@wonderhamster.com; mbarnes@nortelnetworks.com;=20 > Simo.Veikkolainen@nokia.com; enrico.marocco@telecomitalia.it > Cc: dispatch@ietf.org > Subject: Updated SIP and XMPP combined use charter proposal >=20 > Hi all, >=20 > We held a DISPATCH mini-BoF on SIP and XMPP combined use back=20 > at the November IETF with a fair amount of interest. A=20 > charter proposal was discussed around December/January, and=20 > most people on DISPATCH were happy with the outcome. After=20 > that the activity has been limited but there have been=20 > discussions with the ADs and some interested folks how the=20 > charter proposal should be updated to make it more clear what=20 > the mini-WG would be about, and especially what is out of=20 > scope. Several people were asking me about the topic before=20 > or during Anaheim IETF so I expect the interest for this is=20 > still relatively high and we should go forward. >=20 > Based on the feedback Simo and myself have drafted an updated=20 > charter proposal, see below.=20 >=20 > The use cases and requirements draft has also been updated: > http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/ >=20 > Also, Emil and Enrico submitted a draft on provisioning BCP: > http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/ >=20 > Please comment especially on the charter if it looks clear=20 > and concise enough. >=20 > Regards, > Markus=20 >=20 >=20 > Combining SIP Voice and Video with XMPP IM and Presence=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > Session Initiation Protocol (SIP) and Extensible Messaging=20 > and Presence Protocol (XMPP) are both enjoying a widespread=20 > deployment over the Internet. SIP was originally intended for=20 > setting up real-time media sessions, while XMPP's roots are=20 > with instant messaging (IM) and presence. While both=20 > protocols have mushroomed in functionality, the real=20 > deployments still correlate highly with their original scope;=20 > SIP is mostly used for voice and video and for interconnect=20 > with circuit switched telephony systems, while most of XMPP=20 > deployments offer IM and presence services. So far the=20 > success with fully integrated voice, video, IM and presence=20 > services with either SIP or XMPP has been limited.=20 >=20 > One approach to make the best out of this situation is to=20 > integrate a SIP User Agent and an XMPP client into a single=20 > application. The application would use SIP for voice and=20 > video and XMPP for IM and presence. The best part of this=20 > approach would be that no changes to existing SIP or XMPP=20 > server infrastructures would be required, and there would be=20 > no issues with interoperability between the integrated=20 > endpoints and ordinary SIP- or XMPP-only endpoints. This=20 > would enable incremental deployment, which is an important=20 > success factor. In this "fully independent" form no new SIP=20 > or XMPP standards extensions would be either needed. >=20 > When two integrated SIP and XMPP endpoints communicate with=20 > each other, it would be possible to make the user experience=20 > even more seamless by making the two protocols more "aware"=20 > of each other through minor protocol extensions. For instance=20 > an incoming SIP voice call could be explicitly correlated=20 > with an ongoing IM exchange, or XMPP presence could include=20 > explicit SIP voice availability status. For the sake of=20 > deployment feasibility, it would be mandatory for such=20 > protocol extensions not to require any changes to SIP or XMPP=20 > server implementations, and to remain backwards compatible=20 > with non-updated SIP and XMPP endpoints.=20 >=20 > The objective of this Working Group is to document best=20 > practices and develop protocol extensions for combining SIP=20 > based voice and video with XMPP based IM and presence such=20 > that a unified user experience can be offered to end user.=20 >=20 > Specifically, the WG will address the following use cases:=20 > - User identifier discovery; it should be possible for a=20 > user to learn other user's SIP identifier based on her XMPP=20 > identifier and vice versa for future use without needing to=20 > engage in an active communication session with the other=20 > user. Mapping of address schemes (sip:, xmpp:, im:, pres:=20 > etc.) is out of scope of this Working Group.=20 > - Presence integration; it should be possible for user's=20 > XMPP presence status to explicitly include her capability and=20 > willingness for SIP based voice and video communication. It=20 > is desired that only XMPP presence extension mechanisms=20 > described in RFC3921 or its successor are used; presence=20 > format translation and mapping are out of scope of this Working Group. > - Session or conversation capability discovery and=20 > correlation; it should be possible to combine XMPP IM with=20 > SIP voice and video communication between two endpoints so=20 > that the endpoints can discover each others' capabilities and=20 > explicitly relate the communication across the two protocols. =20 > - Provisioning; it should be possible to configure=20 > integrated SIP and XMPP endpoints with as small extra burden=20 > as possible compared to SIP- or XMPP-only endpoints,=20 > especially if both SIP and XMPP are offered by the same=20 > service provider. However, it is desired that no protocol=20 > changes are needed for this. Also, cross-domain=20 > authentication is out of scope of this Working Group. >=20 > The protocol extensions developed in the WG must meet the=20 > following criteria: > - The extensions must work without changes to SIP or XMPP=20 > server infrastructures (including typical SIP B2BUAs), and=20 > across SIP and XMPP deployments that are independent from=20 > each other (such as that they are offered by two different=20 > non-coordinated domains).=20 > - The extensions must not break backwards compatibility=20 > with non-updated SIP and XMPP endpoints. >=20 > The following is out of scope of the initial charter of the WG:=20 > - Multiparty communication, for instance the combined use=20 > of SIP voice conferencing and XMPP IM chatrooms.=20 > - Advanced services such as SIP session transfer combined=20 > with XMPP IM.=20 > - Protocol interworking, that is, translation gateways=20 > from SIP to XMPP or vice versa.=20 > - New routing logic; the WG should rely on existing=20 > routing mechanisms defined for SIP and XMPP, and not define=20 > cross-domain routing for example in case when a user's SIP=20 > AOR is known but that user is not registered for SIP service. >=20 > Milestones >=20 > Dec 2010 Use cases and protocol requirements document=20 > submitted to IESG (Informational). >=20 > Aug 2011 Document defining mechanisms for discovering user's=20 > SIP identifier based on her XMPP identifier submitted to IESG=20 > (Standards Track). >=20 > Aug 2011 Document defining XMPP presence extensions for SIP=20 > voice and video communication capability and willingness=20 > submitted to IESG (Standards Track). >=20 > Aug 2011 Document defining protocol extensions that allow=20 > combined SIP voice and video and XMPP IM capable endpoints to=20 > discover each others' capabilities and correlate their=20 > communication across the two protocols submitted to IESG=20 > (Standards Track). >=20 > Aug 2011 Document defining best practises document for=20 > configuration and provisioning of combined SIP and XMPP=20 > endpoints submitted to IESG (BCP).= From en5192@att.com Mon Apr 26 06:55:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AE13A6BAB; Mon, 26 Apr 2010 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 N5EbOmsIdgfu; Mon, 26 Apr 2010 06:55:27 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id E11833A6A67; Mon, 26 Apr 2010 06:55:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: en5192@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1272290113!41237223!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 16081 invoked from network); 26 Apr 2010 13:55:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Apr 2010 13:55:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3QDsvGF003341; Mon, 26 Apr 2010 09:54:57 -0400 Received: from misout7msgusr7b.ugd.att.com (misout7msgusr7b.ugd.att.com [144.155.43.104]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3QDspcn003217; Mon, 26 Apr 2010 09:54: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2010 09:53:40 -0400 Message-ID: <5DA01D2CA74FAF40ADF71DB4177D345A055BB760@misout7msgusr7b.ugd.att.com> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141015EFC76@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] Proposed SIP Overload Control Charter Thread-Index: AcrhaivcAWXJruR7Rqq508h/XZIohQBWCz5QAJ+6sSA= References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com><4BB5409E.5080108@alcatel-lucent.com><0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com><6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141015EFC76@ftrdmel0.rd.francetelecom.fr> From: "NOEL, ERIC C (ATTLABS)" To: , Cc: volker.hilt@alcatel-lucent.com, dispatch@ietf.org, sip-overload@ietf.org, lars.eggert@nokia.com Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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: Mon, 26 Apr 2010 13:55:27 -0000 Folks, Wrt milestones deadlines: 1. A document describing key design considerations for a SIP overload control mechanism =3D=3D> Sep 2010 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback =3D=3D> Dec 2010 3. A specification for a SIP load filtering mechanism =3D=3D> May = 2011 I have a few comments: - Is item 1 a cleaned up version of = draft-ietf-sipping-overload-design-02.pdf? =3D=3D> if so I am OK with Sep 2010 date. - Could item 2 consist of the documentation of one of the SIP overload = control mechanism studied by the SIP overload design team coordinated by = Volker?=20 =3D=3D> Provided work consists of documenting one of the control = mechanism studied by the SIP overload design team, then I am ok with Dec = 2010. - With respect to item 3, are there any other related IETF activity = besides draft-shen-sipping-load-control-event-package that need = consideration? Is the expectation to validate the proposed load = filtering mechanism through simulation? =3D=3D> Would like feedback on questions prior agreeing on May 2011 = deadline. Lastly, what will be the mode of operation to actually work on these = items? Continue sending comments on the sip-overload distribution list? = Have regular sub-teams meeting (via conference calls)?=20 Thanks, Eric -----Original Message----- From: sip-overload-bounces@ietf.org = [mailto:sip-overload-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com Sent: Friday, April 23, 2010 4:54 AM To: rjsparks@nostrum.com Cc: volker.hilt@alcatel-lucent.com; dispatch@ietf.org; = sip-overload@ietf.org; Gonzalo.Camarillo@ericsson.com; = lars.eggert@nokia.com Subject: Re: [sip-overload] Proposed SIP Overload Control Charter I would prefer to see the SIP load filtering specification released by = the end of 2010.=20 BC > -----Message d'origine----- > De : sip-overload-bounces@ietf.org=20 > [mailto:sip-overload-bounces@ietf.org] De la part de Robert Sparks > Envoy=E9 : mercredi 21 avril 2010 17:29 > =C0 : Robert Sparks > Cc : Volker Hilt; DISPATCH; sip-overload@ietf.org; Gonzalo=20 > Camarillo; Lars Eggert > Objet : Re: [sip-overload] Proposed SIP Overload Control Charter >=20 > Please comment on what these dates should actually be=20 >=20 > RjS >=20 > > Milestones: > >=20 > > Sep 2010 Design Considerations to IESG for publication as=20 > > Informational Dec 2010 Specification for a SIP overload control=20 > > mechanism based on implicit/explicit feedback to IESG for=20 > publication=20 > > as Proposed Standard May 2011 Specification for a SIP load=20 > filtering=20 > > mechaism to IESG for publication as Proposed Standard >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >=20 _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From laura.liess.dt@googlemail.com Mon Apr 26 06:57:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFB43A6A67 for ; Mon, 26 Apr 2010 06:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_40=-0.185, 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 t3G7fTAyTaqP for ; Mon, 26 Apr 2010 06:57:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 305C628C0E0 for ; Mon, 26 Apr 2010 06:57:19 -0700 (PDT) Received: by wyb35 with SMTP id 35so2812792wyb.31 for ; Mon, 26 Apr 2010 06:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DU9Awqn2ap2YiU4efuY+P7VUMsT/roZdfIln9efUVIo=; b=SqHX/JV/OC4oNCa/jNq7lhytZxAAEw/6tW4rK3F0IPsS0idugXTWeeBm0yloDENsyp mm0tkWZuXyDFd6ln1rdUR3xFN61eq9WYtjInSFaEIjMfiWKOOak0jk9k4o4lYYpAyYDr DE/tWfksVbImSOXz/vVEwVcDNyUHx8cjf3ezk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RJeyEzklKCob0jRSGfYcFORzll4wRpJbrcjME0kIZWDKlsdyh8ZNjei6FITwnh1AuQ XyzwIxL0meDrsqbwP1ztcZqflGvLXeE2n6EL2Xi9jnKOglu8Bg/OjhhOlI6QG0E+4G+b FMZuqEEc/cAFlKaD6TFkywaBBSc9WaKgP0WW4= MIME-Version: 1.0 Received: by 10.216.90.130 with SMTP id e2mr5375089wef.210.1272290224092; Mon, 26 Apr 2010 06:57:04 -0700 (PDT) Received: by 10.216.171.135 with HTTP; Mon, 26 Apr 2010 06:57:04 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> Date: Mon, 26 Apr 2010 15:57:04 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , =?ISO-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 13:57:23 -0000 Hi Hadriel, Comments inline... > > The concept of specifying the algorithm was only to guarantee the value w= ouldn't reveal which vendor had created it. =A0But it wouldn't have made it= possible for a monitoring system to determine the session-id value for mes= sages which don't already have a session-id, because the hash used a privat= e key unique to every system. =A0In other words, two different systems woul= d generate two different Session-IDs for the same Call-ID. =A0That was by d= esign. > > So since it was only to avoid revealing the vendor, I got comments back t= hat a random number would be good enough for that, > and reduce the work/performance-hit of doing a strong hash. > For us it is important only not to reveal the IP-address in the original Call-ID. We also intend the messsage correlation software to know the key. The external monitoring system stores all the in- and outgoing SIP-messages for a B2BUA. For every incomming, out-of-dialog message, the message correlation software looks for the Session-ID. If it finds one, it identifies all other messages, in and out, and the correlation is done. If there is no Session-ID in the message, it takes the Call-ID, hashes it with the key of the B2BUA and searches for an outgoing message with this Session-ID. > >> - Chapter 3. Overview, 3-rd paragraph: "Instead this new header field >> provides an identifier for troubleshooting uses only." >> =A0Implementations and other SDOs (I know of 3GPP) already use >> Session-ID for SIP-services as Conferencing, to correlate both legs of >> a dialog across a B2BUA. There is no other SIP-identifier they can use >> for this. So my proposal is to allow this in the Session-ID draft. >> Otherwise we either have inconcistency between IETF and IMS documents. > > Is there a doc I can go look at which describes how they're going to use = it? 3GPP TS 24.605 shows how it is used for Conferencing. See http://www.3gpp.org/ftp/Specs/html-info/24605.htm Here is the message flow. In TS 24.229 the Session-ID usage was extended to dialog correlation in general. http://www.3gpp.org/ftp/Specs/html-info/24229.htm Please make sure you download the last versions, at the bottom of the tables, for both specifications. They decided to use Session-ID because there is no other mechanism for dialog correlation. Such mechanism is needed both for troubleshooting and dialog correlation. My opinion is that we should try to get a WG to solve both problems. Laura > > -hadriel > From volker.hilt@alcatel-lucent.com Mon Apr 26 13:19:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3403A6980; Mon, 26 Apr 2010 13:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.567, 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 xh4xuuygANRB; Mon, 26 Apr 2010 13:19:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id ACA713A689D; Mon, 26 Apr 2010 13:19:37 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o3QKJMYX018113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 15:19:23 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o3QKJLnC030201; Mon, 26 Apr 2010 15:19:21 -0500 Received: from [135.112.131.79] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.2.213.0; Mon, 26 Apr 2010 15:19:21 -0500 Message-ID: <4BD5F5C5.1000705@alcatel-lucent.com> Date: Mon, 26 Apr 2010 16:21:25 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "NOEL, ERIC C (ATTLABS)" References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com><4BB5409E.5080108@alcatel-lucent.com><0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com><6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141015EFC76@ftrdmel0.rd.francetelecom.fr> <5DA01D2CA74FAF40ADF71DB4177D345A055BB760@misout7msgusr7b.ugd.att.com> In-Reply-To: <5DA01D2CA74FAF40ADF71DB4177D345A055BB760@misout7msgusr7b.ugd.att.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "bruno.chatras@orange-ftgroup.com" , "dispatch@ietf.org" , "sip-overload@ietf.org" , "lars.eggert@nokia.com" Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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: Mon, 26 Apr 2010 20:19:42 -0000 Eric, > > Wrt milestones deadlines: > > 1. A document describing key design considerations for a SIP overload > control mechanism ==> Sep 2010 > 2. A specification for an SIP overload control mechanism based on > implicit/explicit feedback ==> Dec 2010 > 3. A specification for a SIP load filtering mechanism ==> May 2011 > > I have a few comments: > > - Is item 1 a cleaned up version of draft-ietf-sipping-overload-design-02.pdf? > ==> if so I am OK with Sep 2010 date. > - Could item 2 consist of the documentation of one of the SIP overload control mechanism studied by the SIP overload design team coordinated by Volker? > ==> Provided work consists of documenting one of the control mechanism studied by the SIP overload design team, then I am ok with Dec 2010. > - With respect to item 3, are there any other related IETF activity besides draft-shen-sipping-load-control-event-package that need consideration? Is the expectation to validate the proposed load filtering mechanism through simulation? > ==> Would like feedback on questions prior agreeing on May 2011 deadline. > The charter lays out milestones for items the proposed working group should produce. It is up to the WG to evaluate the drafts that have been proposed and adopt drafts that meet these milestones. The drafts you mention are candidates. They may or may not be adopted by the WG. > Lastly, what will be the mode of operation to actually work on these > items? Continue sending comments on the sip-overload distribution > list? Have regular sub-teams meeting (via conference calls)? > All discussions will happen on the sip-overload mailing list and all comments need to go to this list. We may use conference calls for specific topics if needed. If there is a need, calls will be announced on the mailing list. Thanks, Volker > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of bruno.chatras@orange-ftgroup.com > Sent: Friday, April 23, 2010 4:54 AM > To: rjsparks@nostrum.com > Cc: volker.hilt@alcatel-lucent.com; dispatch@ietf.org; sip-overload@ietf.org; Gonzalo.Camarillo@ericsson.com; lars.eggert@nokia.com > Subject: Re: [sip-overload] Proposed SIP Overload Control Charter > > I would prefer to see the SIP load filtering specification released by the end of 2010. > BC > >> -----Message d'origine----- >> De : sip-overload-bounces@ietf.org >> [mailto:sip-overload-bounces@ietf.org] De la part de Robert Sparks >> Envoyé : mercredi 21 avril 2010 17:29 >> À : Robert Sparks >> Cc : Volker Hilt; DISPATCH; sip-overload@ietf.org; Gonzalo >> Camarillo; Lars Eggert >> Objet : Re: [sip-overload] Proposed SIP Overload Control Charter >> >> Please comment on what these dates should actually be >> >> RjS >> >>> Milestones: >>> >>> Sep 2010 Design Considerations to IESG for publication as >>> Informational Dec 2010 Specification for a SIP overload control >>> mechanism based on implicit/explicit feedback to IESG for >> publication >>> as Proposed Standard May 2011 Specification for a SIP load >> filtering >>> mechaism to IESG for publication as Proposed Standard >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >> > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From enrico.marocco@telecomitalia.it Tue Apr 27 02:55:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C053A69FF for ; Tue, 27 Apr 2010 02:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.819 X-Spam-Level: * X-Spam-Status: No, score=1.819 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_50=0.001, 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 22jb142t3mQA for ; Tue, 27 Apr 2010 02:55:51 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 9DEF63A692B for ; Tue, 27 Apr 2010 02:55:43 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Apr 2010 11:55:28 +0200 Received: from [163.162.173.11] (163.162.173.11) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Apr 2010 11:55:28 +0200 Message-ID: <4BD6B499.2060908@telecomitalia.it> Date: Tue, 27 Apr 2010 11:55:37 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "Markus.Isomaki@nokia.com" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040208030904090907060908" Cc: "mbarnes@nortelnetworks.com" , "dispatch@ietf.org" Subject: Re: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 09:55:52 -0000 --------------ms040208030904090907060908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Markus, this version addresses my previous concerns. I'm fine with it. Enrico Markus.Isomaki@nokia.com wrote: > Hi all, > > We held a DISPATCH mini-BoF on SIP and XMPP combined use back at the November IETF with a fair amount of interest. A charter proposal was discussed around December/January, and most people on DISPATCH were happy with the outcome. After that the activity has been limited but there have been discussions with the ADs and some interested folks how the charter proposal should be updated to make it more clear what the mini-WG would be about, and especially what is out of scope. Several people were asking me about the topic before or during Anaheim IETF so I expect the interest for this is still relatively high and we should go forward. > > Based on the feedback Simo and myself have drafted an updated charter proposal, see below. > > The use cases and requirements draft has also been updated: > http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/ > > Also, Emil and Enrico submitted a draft on provisioning BCP: > http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/ > > Please comment especially on the charter if it looks clear and concise enough. > > Regards, > Markus > > > Combining SIP Voice and Video with XMPP IM and Presence ======================================================= > > Session Initiation Protocol (SIP) and Extensible Messaging and Presence Protocol (XMPP) are both enjoying a widespread deployment over the Internet. SIP was originally intended for setting up real-time media sessions, while XMPP's roots are with instant messaging (IM) and presence. While both protocols have mushroomed in functionality, the real deployments still correlate highly with their original scope; SIP is mostly used for voice and video and for interconnect with circuit switched telephony systems, while most of XMPP deployments offer IM and presence services. So far the success with fully integrated voice, video, IM and presence services with either SIP or XMPP has been limited. > > One approach to make the best out of this situation is to integrate a SIP User Agent and an XMPP client into a single application. The application would use SIP for voice and video and XMPP for IM and presence. The best part of this approach would be that no changes to existing SIP or XMPP server infrastructures would be required, and there would be no issues with interoperability between the integrated endpoints and ordinary SIP- or XMPP-only endpoints. This would enable incremental deployment, which is an important success factor. In this "fully independent" form no new SIP or XMPP standards extensions would be either needed. > > When two integrated SIP and XMPP endpoints communicate with each other, it would be possible to make the user experience even more seamless by making the two protocols more "aware" of each other through minor protocol extensions. For instance an incoming SIP voice call could be explicitly correlated with an ongoing IM exchange, or XMPP presence could include explicit SIP voice availability status. For the sake of deployment feasibility, it would be mandatory for such protocol extensions not to require any changes to SIP or XMPP server implementations, and to remain backwards compatible with non-updated SIP and XMPP endpoints. > > The objective of this Working Group is to document best practices and develop protocol extensions for combining SIP based voice and video with XMPP based IM and presence such that a unified user experience can be offered to end user. > > Specifically, the WG will address the following use cases: > - User identifier discovery; it should be possible for a user to learn other user's SIP identifier based on her XMPP identifier and vice versa for future use without needing to engage in an active communication session with the other user. Mapping of address schemes (sip:, xmpp:, im:, pres: etc.) is out of scope of this Working Group. > - Presence integration; it should be possible for user's XMPP presence status to explicitly include her capability and willingness for SIP based voice and video communication. It is desired that only XMPP presence extension mechanisms described in RFC3921 or its successor are used; presence format translation and mapping are out of scope of this Working Group. > - Session or conversation capability discovery and correlation; it should be possible to combine XMPP IM with SIP voice and video communication between two endpoints so that the endpoints can discover each others' capabilities and explicitly relate the communication across the two protocols. > - Provisioning; it should be possible to configure integrated SIP and XMPP endpoints with as small extra burden as possible compared to SIP- or XMPP-only endpoints, especially if both SIP and XMPP are offered by the same service provider. However, it is desired that no protocol changes are needed for this. Also, cross-domain authentication is out of scope of this Working Group. > > The protocol extensions developed in the WG must meet the following criteria: > - The extensions must work without changes to SIP or XMPP server infrastructures (including typical SIP B2BUAs), and across SIP and XMPP deployments that are independent from each other (such as that they are offered by two different non-coordinated domains). > - The extensions must not break backwards compatibility with non-updated SIP and XMPP endpoints. > > The following is out of scope of the initial charter of the WG: > - Multiparty communication, for instance the combined use of SIP voice conferencing and XMPP IM chatrooms. > - Advanced services such as SIP session transfer combined with XMPP IM. > - Protocol interworking, that is, translation gateways from SIP to XMPP or vice versa. > - New routing logic; the WG should rely on existing routing mechanisms defined for SIP and XMPP, and not define cross-domain routing for example in case when a user's SIP AOR is known but that user is not registered for SIP service. > > Milestones > > Dec 2010 Use cases and protocol requirements document submitted to IESG (Informational). > > Aug 2011 Document defining mechanisms for discovering user's SIP identifier based on her XMPP identifier submitted to IESG (Standards Track). > > Aug 2011 Document defining XMPP presence extensions for SIP voice and video communication capability and willingness submitted to IESG (Standards Track). > > Aug 2011 Document defining protocol extensions that allow combined SIP voice and video and XMPP IM capable endpoints to discover each others' capabilities and correlate their communication across the two protocols submitted to IESG (Standards Track). > > Aug 2011 Document defining best practises document for configuration and provisioning of combined SIP and XMPP endpoints submitted to IESG (BCP). --------------ms040208030904090907060908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNDI3 MDk1NTM3WjAjBgkqhkiG9w0BCQQxFgQU+rP4OXrTA3gwjKWOx+P/qxZssGEwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBACwZATR1IIYmAdWejoKb gCLuHSw5eVTQpFGibQU51Ywy7sg9MnfRb4f9ggDhAypY9Wy3DdCRivojiu3N97V0vHP1MpIc 5maBXfmxE9u4HxPGjUaBLimDv9NkpUT1I4/MHjVDRMEWTCSx8GCLimZMCgcv8Ryr5zJpUfv9 uZvqj7uzB8Pc7uDUUWVR++2Kh4vAKDwbT5GXu6uq3SKdGg0GJpLyxRA7YLwgERaFdWcPykrd tjQPm1sm82b5s0Z2yfT9GWZejKxwNMbC1NkfKjt76QJl0yVhBuYDd9kYglgDWmEVwOVWSIuo xtJ4J/3VshHLOvNQXIfFnFm5MbAb/1te5d8AAAAAAAA= --------------ms040208030904090907060908-- From peter.musgrave@magorcorp.com Tue Apr 27 04:17:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419503A6877 for ; Tue, 27 Apr 2010 04:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, 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 kqnDP9896AuJ for ; Tue, 27 Apr 2010 04:17:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B66C63A6895 for ; Tue, 27 Apr 2010 04:17:25 -0700 (PDT) Received: by gwaa12 with SMTP id a12so3339928gwa.31 for ; Tue, 27 Apr 2010 04:17:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.254.7 with SMTP id b7mr5190499ybi.293.1272367021596; Tue, 27 Apr 2010 04:17:01 -0700 (PDT) Received: by 10.150.92.9 with HTTP; Tue, 27 Apr 2010 04:17:01 -0700 (PDT) In-Reply-To: <4BD6B499.2060908@telecomitalia.it> References: <4BD6B499.2060908@telecomitalia.it> Date: Tue, 27 Apr 2010 07:17:01 -0400 Message-ID: From: Peter Musgrave To: Enrico Marocco Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mbarnes@nortelnetworks.com" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 11:17:34 -0000 Hi, Overall I think the text is good. One clarification. The charter says "one approach" is to combine the XMPP and SIP into a single application. Do you regard cases where they are in different applications and perhaps on different devices as "in scope"? If not, perhaps "The objective..." should be amended to make it clear that only issues associated with combining them into a single application are in scope? If yes, then are mechanism for the applications to exchange info out of sco= pe? Thanks, Peter Musgrave On Tue, Apr 27, 2010 at 5:55 AM, Enrico Marocco wrote: > Thanks Markus, this version addresses my previous concerns. I'm fine > with it. > > Enrico > > Markus.Isomaki@nokia.com wrote: >> Hi all, >> >> We held a DISPATCH mini-BoF on SIP and XMPP combined use back at the Nov= ember IETF with a fair amount of interest. A charter proposal was discussed= around December/January, and most people on DISPATCH were happy with the o= utcome. After that the activity has been limited but there have been discus= sions with the ADs and some interested folks how the charter proposal shoul= d be updated to make it more clear what the mini-WG would be about, and esp= ecially what is out of scope. Several people were asking me about the topic= before or during Anaheim IETF so I expect the interest for this is still r= elatively high and we should go forward. >> >> Based on the feedback Simo and myself have drafted an updated charter pr= oposal, see below. >> >> The use cases and requirements draft has also been updated: >> http://datatracker.ietf.org/doc/draft-veikkolainen-sip-xmpp-coex-reqs/ >> >> Also, Emil and Enrico submitted a draft on provisioning BCP: >> http://datatracker.ietf.org/doc/draft-ivov-sipxmpp-auth/ >> >> Please comment especially on the charter if it looks clear and concise e= nough. >> >> Regards, >> =A0 =A0 =A0 Markus >> >> >> Combining SIP Voice and Video with XMPP IM and Presence =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Session Initiation Protocol (SIP) and Extensible Messaging and Presence = Protocol (XMPP) are both enjoying a widespread deployment over the Internet= . SIP was originally intended for setting up real-time media sessions, whil= e XMPP's roots are with instant messaging (IM) and presence. While both pro= tocols have mushroomed in functionality, the real deployments still correla= te highly with their original scope; SIP is mostly used for voice and video= and for interconnect with circuit switched telephony systems, while most o= f XMPP deployments offer IM and presence services. So far the success with = fully integrated voice, video, IM and presence services with either SIP or = XMPP has been limited. >> >> One approach to make the best out of this situation is to integrate a SI= P User Agent and an XMPP client into a single application. The application = would use SIP for voice and video and XMPP for IM and presence. The best pa= rt of this approach would be that no changes to existing SIP or XMPP server= infrastructures would be required, and there would be no issues with inter= operability between the integrated endpoints and ordinary SIP- or XMPP-only= endpoints. This would enable incremental deployment, which is an important= success factor. In this "fully independent" form no new SIP or XMPP standa= rds extensions would be either needed. >> >> When two integrated SIP and XMPP endpoints communicate with each other, = it would be possible to make the user experience even more seamless by maki= ng the two protocols more "aware" of each other through minor protocol exte= nsions. For instance an incoming SIP voice call could be explicitly correla= ted with an ongoing IM exchange, or XMPP presence could include explicit SI= P voice availability status. For the sake of deployment feasibility, it wou= ld be mandatory for such protocol extensions not to require any changes to = SIP or XMPP server implementations, and to remain backwards compatible with= non-updated SIP and XMPP endpoints. >> >> The objective of this Working Group is to document best practices and de= velop protocol extensions for combining SIP based voice and video with XMPP= based IM and presence such that a unified user experience can be offered t= o end user. >> >> Specifically, the WG will address the following use cases: >> - =A0 =A0User identifier discovery; it should be possible for a user to = learn other user's SIP identifier based on her XMPP identifier and vice ver= sa for future use without needing to engage in an active communication sess= ion with the other user. Mapping of address schemes (sip:, xmpp:, im:, pres= : etc.) is out of scope of this Working Group. >> - =A0 =A0Presence integration; it should be possible for user's XMPP pre= sence status to explicitly include her capability and willingness for SIP b= ased voice and video communication. It is desired that only XMPP presence e= xtension mechanisms described in RFC3921 or its successor are used; presenc= e format translation and mapping are out of scope of this Working Group. >> - =A0 =A0Session or conversation capability discovery and correlation; i= t should be possible to combine XMPP IM with SIP voice and video communicat= ion between two endpoints so that the endpoints can discover each others' c= apabilities and explicitly relate the communication across the two protocol= s. >> - =A0 =A0Provisioning; it should be possible to configure integrated SIP= and XMPP endpoints with as small extra burden as possible compared to SIP-= or XMPP-only endpoints, especially if both SIP and XMPP are offered by the= same service provider. However, it is desired that no protocol changes are= needed for this. Also, cross-domain authentication is out of scope of this= Working Group. >> >> The protocol extensions developed in the WG must meet the following crit= eria: >> - =A0 =A0The extensions must work without changes to SIP or XMPP server = infrastructures (including typical SIP B2BUAs), and across SIP and XMPP dep= loyments that are independent from each other (such as that they are offere= d by two different non-coordinated domains). >> - =A0 =A0The extensions must not break backwards compatibility with non-= updated SIP and XMPP endpoints. >> >> The following is out of scope of the initial charter of the WG: >> - =A0 =A0Multiparty communication, for instance the combined use of SIP = voice conferencing and XMPP IM chatrooms. >> - =A0 =A0Advanced services such as SIP session transfer combined with XM= PP IM. >> - =A0 =A0Protocol interworking, that is, translation gateways from SIP t= o XMPP or vice versa. >> - =A0 =A0New routing logic; the WG should rely on existing routing mecha= nisms defined for SIP and XMPP, and not define cross-domain routing for exa= mple in case when a user's SIP AOR is known but that user is not registered= for SIP service. >> >> Milestones >> >> Dec 2010 Use cases and protocol requirements document submitted to IESG = (Informational). >> >> Aug 2011 Document =A0defining mechanisms for discovering user's SIP iden= tifier based on her XMPP identifier submitted to IESG (Standards Track). >> >> Aug 2011 Document defining XMPP presence extensions for SIP voice and vi= deo communication capability and willingness submitted to IESG (Standards T= rack). >> >> Aug 2011 Document defining protocol extensions that allow combined SIP v= oice and video and XMPP IM capable endpoints to discover each others' capab= ilities and correlate their communication across the two protocols submitte= d to IESG (Standards Track). >> >> Aug 2011 Document defining best practises document for configuration and= provisioning of combined SIP and XMPP endpoints submitted to IESG (BCP). > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From Peter.Dawes@vodafone.com Tue Apr 27 04:29:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFDC3A6908 for ; Tue, 27 Apr 2010 04:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_17=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 s6mMcuU4X6HU for ; Tue, 27 Apr 2010 04:29:15 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by core3.amsl.com (Postfix) with ESMTP id A1CCD3A6968 for ; Tue, 27 Apr 2010 04:28:38 -0700 (PDT) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id D74BE214902 for ; Tue, 27 Apr 2010 13:28:23 +0200 (CEST) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint02 (Postfix) with ESMTPS id B98E62148F9; Tue, 27 Apr 2010 13:28:23 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 13:28:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 13:26:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: New version: draft-kaplan-dispatch-session-id-01 Thread-Index: Acrl/IcfIS3QJPs9TyamBNIgy9Tj8A== From: "Dawes, Peter, VF-Group" To: "Hutton, Andrew" , "Cc: Roland Jesske" , , , "Hadriel Kaplan" , , X-OriginalArrivalTime: 27 Apr 2010 11:28:11.0063 (UTC) FILETIME=[B7BD3470:01CAE5FC] Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 11:29:17 -0000 Hello Hadriel, All, Thanks for the draft. Similar to the other comments, I think that draft-kaplan-dispatch-session-id-01 should not be restricted to troubleshooting. At least one other active draft discusses correlating SIP dialogs (draft-loreto-dispatch-disaggregated-media-01.txt), and the Session-ID header field could be thought of as correlating a series of dialogs linked in series by B2BUAs. It might be that this header field can be used for both purposes. Could you please clarify the importance of making the draft "standards track"? I had a look at what standards track means in RFC 4677 "The Tao of the IETF" and I found that it means the author gives up control of the draft, the draft needs IETF (not just working group) consensus and that the standards track should distinguish specifications that have been demonstrated to interoperate. Are these the reasons for suggesting standards track? I think the draft needs to be clear on the meaning of "pass the identifier through" in section 1.1 Requirements: REQ2: It must be possible to pass the identifier through SIP B2BUAs,=20 with as high a probability as possible. This requirement drives the=20 following requirements: and also the meaning of "related requests" in section 4.5 4.5. B2BUA Behavior=20 =20 A B2BUA compliant with this document MUST copy the Session-ID header=20 field it receives in requests as a UAS into the related requests it=20 generates as a UAC; and any Session-ID field it receives in=20 responses as a UAC into the correlated responses it generates as a=20 UAS. As the draft says (section 8.2) "In general, B2BUA behavior cannot be dictated by standards. They do whatever their owners/operators wish them to do, or whatever is necessary to make their applications work." So to help B2BUAs behave predictably, I think the draft needs a more detailed description and examples of when requests are related and when they are not.=20 I also have a few editorial comments: Change: "Abstract =20 There is a need for having a globally unique session identifier for=20 the same SIP session, which can be consistently maintained across=20 Proxies, B2BUAs and other SIP middle-boxes, for the purpose of=20 Troubleshooting. This draft proposes a new SIP header to carry such=20 a value: Session-ID." To: "Abstract =20 There is a need for having a globally unique session identifier for=20 the same SIP session, which can be consistently maintained across=20 Proxies, B2BUAs and other SIP middle-boxes, for the purpose of=20 Troubleshooting. This draft proposes a new SIP header field to carry such=20 a value: Session-ID." Change: "1. Introduction =20 The SIP [RFC3261] Call-ID header value is a globally unique=20 identifier, mandatory in all requests/responses, which identifies=20 SIP messages belonging to the same dialog or registration." "1. Introduction =20 The SIP [RFC3261] Call-ID header value is a globally unique=20 identifier, mandatory in all requests/responses, which is the same for=20 SIP messages belonging to the same dialog or registration." Change: "4.5. B2BUA Behavior=20 =20 A B2BUA compliant with this document MUST copy the Session-ID header=20 field it receives in requests as a UAS into the related requests it=20 generates as a UAC; and any Session-ID field it receives in=20 responses as a UAC into the correlated responses it generates as a=20 UAS. " To: "4.5. B2BUA Behavior=20 =20 A B2BUA compliant with this document MUST copy the Session-ID header=20 field it receives in requests as a UAS into the related requests it=20 generates as a UAC; and any Session-ID header field it receives in=20 responses as a UAC into the correlated responses it generates as a=20 UAS. " Best regards, Peter =20 Message: 2 Date: Mon, 26 Apr 2010 06:19:30 -0400 From: Peter Musgrave Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 To: "Hutton, Andrew" Cc: Roland Jesske , "dispatch@ietf.org" , Laura Liess , Hadriel Kaplan , Martin H?lsemann Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Hi, I too would like to see this standards track. I already have plans to use it for some internal call logging (and I can see it's value to siprec also). Regards, Peter On Mon, Apr 26, 2010 at 5:50 AM, Hutton, Andrew wrote: > Hi, > > I also think this draft has many more uses than just troubleshooting I know for example it has been discussed as being potentially useful to the SIPREC work. > > For this reason I would like to see the draft published as Standards Track. > > Regards > Andy > > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org ] On Behalf Of Hadriel Kaplan >> Sent: 23 April 2010 16:55 >> To: Laura Liess >> Cc: dispatch@ietf.org; Martin H?lsemann; Roland Jesske >> Subject: Re: [dispatch] New version: >> draft-kaplan-dispatch-session-id-01 >> >> Hi Laura, >> Comments inline... >> >> > -----Original Message----- >> > From: Laura Liess [mailto:laura.liess.dt@googlemail.com ] >> > Sent: Tuesday, April 20, 2010 8:27 AM >> > To: Hadriel Kaplan >> > >> > I don't think that there is no interest for the draft to be=20 >> > DISPATCHed. We had a lot of discussion on it in the past. It's just >> > that people are busy and the current DISPATCH process requires a=20 >> > lot of overhead (charter, chairs...). >> >> Sorry I should have been clearer - I didn't mean no interest in it, I >> meant no interest in DISPATCHing it to an existing WG. (and I=20 >> definitely do NOT think it warrants a new WG :) >> >> >> > Comment to the draft: >> > - I am OK with allowing other algorithms than Call-ID hash.=20 >> > However, the description of the hash algorithm in the 00 version=20 >> > was very usefull and avoided problems with different algorithms=20 >> > being used by the B2BUA and monitoring systems. I don't see any=20 >> > reason for not including it as an implementation example. >> >> The concept of specifying the algorithm was only to guarantee the=20 >> value wouldn't reveal which vendor had created it. ?But it wouldn't=20 >> have made it possible for a monitoring system to determine the=20 >> session-id value for messages which don't already have a session-id,=20 >> because the hash used a private key unique to every system. ?In other >> words, two different systems would generate two different Session-IDs >> for the same Call-ID. ?That was by design. >> >> So since it was only to avoid revealing the vendor, I got comments=20 >> back that a random number would be good enough for that, and reduce=20 >> the work/performance-hit of doing a strong hash. >> >> >> > - Chapter 3. Overview, 3-rd paragraph: "Instead this new >> header field >> > provides an identifier for troubleshooting uses only." >> > ?Implementations and other SDOs (I know of 3GPP) already use=20 >> > Session-ID for SIP-services as Conferencing, to correlate >> both legs of >> > a dialog across a B2BUA. There is no other SIP-identifier >> they can use >> > for this. So my proposal is to allow this in the Session-ID draft. >> > Otherwise we either have inconcistency between IETF and IMS >> documents. >> >> Is there a doc I can go look at which describes how they're going to=20 >> use it? >> >> -hadriel >> _______________________________________________ >> 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 > =20 From peter.musgrave@magorcorp.com Tue Apr 27 04:36:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B303E3A6902 for ; Tue, 27 Apr 2010 04:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.212 X-Spam-Level: X-Spam-Status: No, score=-0.212 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_20=-0.74, 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 J96bUrbn98S8 for ; Tue, 27 Apr 2010 04:36:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3D7993A67AD for ; Tue, 27 Apr 2010 04:36:01 -0700 (PDT) Received: by gyh4 with SMTP id 4so6811424gyh.31 for ; Tue, 27 Apr 2010 04:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.208.5 with SMTP id f5mr5185603ybg.271.1272368145647; Tue, 27 Apr 2010 04:35:45 -0700 (PDT) Received: by 10.150.92.9 with HTTP; Tue, 27 Apr 2010 04:35:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Apr 2010 07:35:45 -0400 Message-ID: From: Peter Musgrave To: "Dawes, Peter, VF-Group" Content-Type: text/plain; charset=ISO-8859-1 Cc: dispatch@ietf.org, "Cc: Roland Jesske" , laura.liess.dt@googlemail.com, Hadriel Kaplan , Martin.Huelsemann@telekom.de Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 11:36:05 -0000 Re: standards track Ah...thanks for the clarification. I misinterpreted this to mean "get adopted by a working group" and that was the idea I wanted to express support for. Peter Musgrave On Tue, Apr 27, 2010 at 7:26 AM, Dawes, Peter, VF-Group wrote: > Hello Hadriel, All, > Thanks for the draft. Similar to the other comments, I think that > draft-kaplan-dispatch-session-id-01 should not be restricted to > troubleshooting. At least one other active draft discusses correlating > SIP dialogs (draft-loreto-dispatch-disaggregated-media-01.txt), and the > Session-ID header field could be thought of as correlating a series of > dialogs linked in series by B2BUAs. It might be that this header field > can be used for both purposes. > > Could you please clarify the importance of making the draft "standards > track"? I had a look at what standards track means in RFC 4677 "The Tao > of the IETF" and I found that it means the author gives up control of > the draft, the draft needs IETF (not just working group) consensus and > that the standards track should distinguish specifications that have > been demonstrated to interoperate. Are these the reasons for suggesting > standards track? From andrew.hutton@siemens-enterprise.com Tue Apr 27 06:03:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4023A69B9 for ; Tue, 27 Apr 2010 06:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 hn2nuexBOrD9 for ; Tue, 27 Apr 2010 06:03:04 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3AB563A6994 for ; Tue, 27 Apr 2010 06:03:03 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1687954; Tue, 27 Apr 2010 15:02:51 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 0AB8D23F028E; Tue, 27 Apr 2010 15:02:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 27 Apr 2010 15:02:51 +0200 From: "Hutton, Andrew" To: Peter Musgrave , "Dawes, Peter, VF-Group" Date: Tue, 27 Apr 2010 15:02:49 +0200 Thread-Topic: New version: draft-kaplan-dispatch-session-id-01 Thread-Index: Acrl/coTxwQP6CBJRI28iwV/B87p+gAC1qwQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3070B172CC6@MCHP058A.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "Martin.Huelsemann@telekom.de" , "laura.liess.dt@googlemail.com" , "Cc: Roland Jesske" , Hadriel Kaplan Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 13:03:05 -0000 Hi, Have a look at http://www.ietf.org/iesg/informational-vs-experimental.html = and read section 2. This states: An "Informational" specification is published for the general information o= f the Internet community, and does not represent an Internet community cons= ensus or recommendation. For me this suggests that this specification which seems to be important an= d probably will be widely implemented should be a standards track specifica= tion. Regards Andy > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 > Sent: 27 April 2010 12:36 > To: Dawes, Peter, VF-Group > Cc: Hutton, Andrew; Cc: Roland Jesske; dispatch@ietf.org;=20 > laura.liess.dt@googlemail.com; Hadriel Kaplan;=20 > Martin.Huelsemann@telekom.de > Subject: Re: New version: draft-kaplan-dispatch-session-id-01 >=20 > Re: standards track >=20 > Ah...thanks for the clarification. >=20 > I misinterpreted this to mean "get adopted by a working group" and > that was the idea I wanted to express support for. >=20 > Peter Musgrave >=20 > On Tue, Apr 27, 2010 at 7:26 AM, Dawes, Peter, VF-Group > wrote: > > Hello Hadriel, All, > > Thanks for the draft. Similar to the other comments, I think that > > draft-kaplan-dispatch-session-id-01 should not be restricted to > > troubleshooting. At least one other active draft discusses=20 > correlating > > SIP dialogs=20 > (draft-loreto-dispatch-disaggregated-media-01.txt), and the > > Session-ID header field could be thought of as correlating=20 > a series of > > dialogs linked in series by B2BUAs. It might be that this=20 > header field > > can be used for both purposes. > > > > Could you please clarify the importance of making the draft=20 > "standards > > track"? I had a look at what standards track means in RFC=20 > 4677 "The Tao > > of the IETF" and I found that it means the author gives up=20 > control of > > the draft, the draft needs IETF (not just working group)=20 > consensus and > > that the standards track should distinguish specifications that have > > been demonstrated to interoperate. Are these the reasons=20 > for suggesting > > standards track? > > = From partr@cisco.com Tue Apr 27 07:58:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B2D28C235; Tue, 27 Apr 2010 07:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wdqe0MJGJx3; Tue, 27 Apr 2010 07:58:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AF9C13A6BBE; Tue, 27 Apr 2010 07:53:43 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwEAPmW1ktAaHtegWdsb2JhbACcThUBAQsLIiKmY5ofgkyCQgSDOB8 X-IronPort-AV: E=Sophos;i="4.52,280,1270425600"; d="scan'208";a="60173366" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2010 14:53:28 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RErRjc003699; Tue, 27 Apr 2010 14:53:27 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 20:23:27 +0530 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, 27 Apr 2010 20:23:26 +0530 Message-ID: In-Reply-To: <4BD5F5C5.1000705@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [sip-overload] Proposed SIP Overload Control Charter Thread-Index: AcrlfdskN/qI7PFISx20X/Vf7uzcOwAmyKfw References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com><4BB5409E.5080108@alcatel-lucent.com><0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com><6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141015EFC76@ftrdmel0.rd.francetelecom.fr><5DA01D2CA74FAF40ADF71DB4177D345A055BB760@misout7msgusr7b.ugd.att.com> <4BD5F5C5.1000705@alcatel-lucent.com> From: "Parthasarathi R (partr)" To: "Volker Hilt" , "NOEL, ERIC C (ATTLABS)" X-OriginalArrivalTime: 27 Apr 2010 14:53:27.0190 (UTC) FILETIME=[64B90B60:01CAE619] Cc: bruno.chatras@orange-ftgroup.com, dispatch@ietf.org, sip-overload@ietf.org, lars.eggert@nokia.com, "Paul Jones \(paulej\)" Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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: Tue, 27 Apr 2010 14:58:51 -0000 Hi all, > 2. A specification for an SIP overload control mechanism based on > implicit/explicit feedback =3D=3D> Dec 2010 draft-partha-sip-overload-resource-availability is a draft based on = explicit feedback mechanism (SUBSCRIBE/NOTIFY). This draft is an = enhancement of H.323 Resource Availability Indication mechanism (RAI) = which is widely deployed in H.323 network for handling overload = situation. The draft mechanism is tested in our Lab and it is working = fine for overloading of different resources like CPU, Memory, DSP, DS0. = The proposed mechanism works well in case server has capability to = handle audio & video and audio only call simultaneously. Could you = please consider this draft for the above requirement.=20 Thanks Partha -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Volker Hilt Sent: Tuesday, April 27, 2010 1:51 AM To: NOEL, ERIC C (ATTLABS) Cc: bruno.chatras@orange-ftgroup.com; dispatch@ietf.org; = sip-overload@ietf.org; lars.eggert@nokia.com Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control = Charter Eric, > > Wrt milestones deadlines: > > 1. A document describing key design considerations for a SIP = overload > control mechanism =3D=3D> Sep 2010 > 2. A specification for an SIP overload control mechanism based on > implicit/explicit feedback =3D=3D> Dec 2010 > 3. A specification for a SIP load filtering mechanism =3D=3D> May = > 2011 > > I have a few comments: > > - Is item 1 a cleaned up version of = draft-ietf-sipping-overload-design-02.pdf? > =3D=3D> if so I am OK with Sep 2010 date. > - Could item 2 consist of the documentation of one of the SIP overload = control mechanism studied by the SIP overload design team coordinated by = Volker? > =3D=3D> Provided work consists of documenting one of the control = mechanism studied by the SIP overload design team, then I am ok with Dec = 2010. > - With respect to item 3, are there any other related IETF activity = besides draft-shen-sipping-load-control-event-package that need = consideration? Is the expectation to validate the proposed load = filtering mechanism through simulation? > =3D=3D> Would like feedback on questions prior agreeing on May = 2011 deadline. > The charter lays out milestones for items the proposed working group = should produce. It is up to the WG to evaluate the drafts that have been = proposed and adopt drafts that meet these milestones. The drafts you = mention are candidates. They may or may not be adopted by the WG. > Lastly, what will be the mode of operation to actually work on these=20 > items? Continue sending comments on the sip-overload distribution=20 > list? Have regular sub-teams meeting (via conference calls)? > All discussions will happen on the sip-overload mailing list and all = comments need to go to this list. We may use conference calls for = specific topics if needed. If there is a need, calls will be announced = on the mailing list. Thanks, Volker > -----Original Message----- > From: sip-overload-bounces@ietf.org=20 > [mailto:sip-overload-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Friday, April 23, 2010 4:54 AM > To: rjsparks@nostrum.com > Cc: volker.hilt@alcatel-lucent.com; dispatch@ietf.org;=20 > sip-overload@ietf.org; Gonzalo.Camarillo@ericsson.com;=20 > lars.eggert@nokia.com > Subject: Re: [sip-overload] Proposed SIP Overload Control Charter > > I would prefer to see the SIP load filtering specification released by = the end of 2010. > BC > >> -----Message d'origine----- >> De : sip-overload-bounces@ietf.org >> [mailto:sip-overload-bounces@ietf.org] De la part de Robert Sparks=20 >> Envoy=E9 : mercredi 21 avril 2010 17:29 =C0 : Robert Sparks Cc : = Volker=20 >> Hilt; DISPATCH; sip-overload@ietf.org; Gonzalo Camarillo; Lars Eggert = >> Objet : Re: [sip-overload] Proposed SIP Overload Control Charter >> >> Please comment on what these dates should actually be >> >> RjS >> >>> Milestones: >>> >>> Sep 2010 Design Considerations to IESG for publication as=20 >>> Informational Dec 2010 Specification for a SIP overload control=20 >>> mechanism based on implicit/explicit feedback to IESG for >> publication >>> as Proposed Standard May 2011 Specification for a SIP load >> filtering >>> mechaism to IESG for publication as Proposed Standard >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >> > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > 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 HKaplan@acmepacket.com Tue Apr 27 08:58:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6F73A6BF3 for ; Tue, 27 Apr 2010 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 sbwIY2Nmp-NB for ; Tue, 27 Apr 2010 08:58:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4F9273A6868 for ; Tue, 27 Apr 2010 08:55:21 -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, 27 Apr 2010 11:55:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 11:55:07 -0400 From: Hadriel Kaplan To: Laura Liess Date: Tue, 27 Apr 2010 11:55:08 -0400 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: AcrlSGvq5RlQbGFhTrSW4o3cdEuKswA2Ovlg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F121F@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , =?iso-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 15:58:34 -0000 > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Monday, April 26, 2010 9:57 AM >=20 > For us it is important only not to reveal the IP-address in the > original Call-ID. We also intend the messsage correlation software to > know the key. The external monitoring system stores all the in- and > outgoing SIP-messages for a B2BUA. For every incomming, out-of-dialog > message, the message correlation software looks for the Session-ID. If > it finds one, it identifies all other messages, in and out, and the > correlation is done. If there is no Session-ID in the message, it > takes the Call-ID, hashes it with the key of the B2BUA and searches > for an outgoing message with this Session-ID. As currently defined the B2BUA would insert the same Session-ID in the resp= onses it generates back upstream to the UAC - is that not enough for a moni= toring system to correlate both sides? I don't know the answer; hopefully= some monitoring vendors will chime in. I told several of them about this = draft but I don't know if they had anyone join dispatch. -hadriel From adam@nostrum.com Tue Apr 27 10:46:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0549C28C15D for ; Tue, 27 Apr 2010 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_50=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 jOGtZ0dVTLya for ; Tue, 27 Apr 2010 10:46:22 -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 84ACE3A6A99 for ; Tue, 27 Apr 2010 10:46:16 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3RHjpkP064439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 12:45:54 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BD722CD.8020203@nostrum.com> Date: Tue, 27 Apr 2010 12:45:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:46:24 -0000 On 4/17/10 13:42, Apr 17, Hadriel Kaplan wrote: > - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary number can be generated/recorded/used > If this is only for troubleshooting, that's probably Good Enough [tm]. But I've seen a few messages clamoring for this to be useful for non-debugging purposes. If these identifiers are used for correlation after the fact -- especially for something with real-world ramifications like billing, legal intercept, criminal forensics or the like -- I think 64 bits is a bit paltry. Keep in mind that SIP is being deployed in carrier grade systems, with high rates of throughput. For estimation purposes, let's consider AT&T's voice network. As of 1999, it carried about 300 millon calls per day [1]. Let's imagine some day in the future in which these are all traveling over SIP, but the traffic load has mysteriously not increased. So we're being somewhat optimistic about SIP's adoption, but very pessimistic about calling patterns. This is a classic example of the Birthday Paradox [2]. Using a 64-bit integer as the number of bins: - If you were to analyze one day's traffic, you'd have about a 0.2% chance of a collision. - Analyzing one week of traffic (seven days), that chance goes up to 11.2%. - And, over the course of a month (30 days) -- where there might be billing implications -- it skyrockets to 88.9%. Now, if you doubled length of the identifier -- to 128 bits -- you'd have to process 26 quadrillion (26 * 10^15) calls before your chance of collision rose as high as .0001%. That's about 238,000 years worth of calls. And *that* should be good enough for non-debugging purposes. So I'd propose we use 32 hex chars instead of 16. /a [1] http://www2.research.att.com/areas/visualization/papers_videos/abstract.php?id=CG-AbelloGKN99 [2] http://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem From pkyzivat@cisco.com Tue Apr 27 11:16:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B942328C1A6 for ; Tue, 27 Apr 2010 11:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.353 X-Spam-Level: X-Spam-Status: No, score=-10.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M8e1zxyWwgL for ; Tue, 27 Apr 2010 11:16:56 -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 EBBB63A6B74 for ; Tue, 27 Apr 2010 11:16:45 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL7G1ktAZnwN/2dsb2JhbACcTnGnaZochQ4E X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105748644" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 18:16:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3RIGR2T007353; Tue, 27 Apr 2010 18:16:27 GMT Message-ID: <4BD729F6.4030802@cisco.com> Date: Tue, 27 Apr 2010 14:16:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <4BD722CD.8020203@nostrum.com> In-Reply-To: <4BD722CD.8020203@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:16:56 -0000 Adam Roach wrote: > And *that* should be good enough for non-debugging purposes. So I'd > propose we use 32 hex chars instead of 16. If we care about message size, maybe radix64 (22 chars instead of 32)? Thanks, Paul From HKaplan@acmepacket.com Tue Apr 27 11:26:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D6628C238 for ; Tue, 27 Apr 2010 11:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_50=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 HvpiklA1CnDf for ; Tue, 27 Apr 2010 11:26:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 964F13A6918 for ; Tue, 27 Apr 2010 11:25:03 -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, 27 Apr 2010 14:24:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 14:24:50 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Tue, 27 Apr 2010 14:24:49 -0400 Thread-Topic: Using session-id for dialog correlation Thread-Index: AcrmNuwi6qvbpieVQEqOL1XxIRQ97Q== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> 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] Using session-id for dialog correlation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 27 Apr 2010 18:26:31 -0000 [sorry for the long email, but it's a complicated topic] A few people have mentioned that the session-id draft should not only be fo= r troubleshooting, but for dialog correlation as well. =20 Specifically to handle this type of scenario, based on 3GPP 24.605 annex A.= 2.2 +----+ +-----+ +----+ +-----+ +----+ |UA-A| |B2BUA| | AS | |B2BUA| |UA-B| +----+ +-----+ +----+ +-----+ +----+ | | | | | |INVITE | | | | |callid:1a |callid:1b |callid:1c |callid:1d | |----------->|----------->|---------->|----------->| |sessid:1 |sessid:1 |sessid:1 |sessid:1 | | | | | | |INVITE | | | | |callid:2a |callid:2b | | | |----------->|----------->| | | |sessid:2 |sessid:2 |re-INVITE | | |RL|RL|callid:1c |callid:1d | | | |---------->|----------->| | | |sessid:1 |sessid:1 | | | | | | [note: this is a simplified drawing from 3gpp's - in 3gpp it has two called= parties: UA-B and UA-C, but it doesn't really matter with regards to the p= roblem] Explanation of drawing: UA-A has a call with UA-B through multiple B2BUA's and an Application Serve= r. The dialogs of that call all have the same session-id, but unique call-= id/tags. UA-A wants to invoke a 3rd party conference facility in the AS, and referen= ce the call with UA-B for that. In this particular 3gpp scenario, to do th= at UA-A sends a new INVITE to the AS with a resource-list body (a la RFC 53= 66) containing the call information for the original call. This is the "RL= " piece in the diagram. It has the calli-d/tags as well, but the= y'll be wrong when received at the AS. The AS processes that list, can't match the callid/tags in the resource-lit= but does match the session-id, and sends a re-INVITE to party B within the= original call's dialog. Do I have that right? I think there are problems doing that. :( 1) The Session-ID only provides a single value which is the same on both "s= ides" of a B2BUA. The AS *is* a B2BUA, so when it gets the resource-list w= ith a Session-ID, how does it know which side of session-id 1 to re-INVITE?= I.e., how does it know to send a re-INVITE to call-id 1c vs. 1b? The tag= s were there to do that, but they no longer match. We could define a flag/= param for Session-ID to indicate uac vs. uas, if you think that would help = (I was prepared to do that in the draft at one point, to avoid this problem= ). 2) What if the AS has multiple dialogs for that same Session-ID? It could = have - for example in a "normal" ad-hoc rfc5366 conference scenario the AS = could have invited multiple participants to the same initial conference cal= l, and could arguably use the same session-id for all legs. So if another = invite referred to that conference call, it would be ambiguous which leg it= meant. 3) Let's say this call-flow actually worked, and the AS sent the re-INVITE = to UA-B. At that point, the B2BUA(s) on the left-hand side of the AS are n= o longer in synch with regards to the call or media state. For example, so= me B2BUA's will tear-down the call if media stops flowing through them for = too long. In this specific 3gpp spec it says the call was put on hold befo= re-hand, so that won't happen, but you get the idea: "bypassing" b2bua's is= brittle. 4) In this *particular* scenario the solution is easier: make the B2BUA's u= nderstand resource-lists, and make them change the callid/tags in them corr= ectly. After all, that's what's causing the mismatch at the AS. But isn't= this a rather unlikely/rare scenario? I mean do you really intend every c= all to go through an AS, just in case it ends up becoming a 3pcc conf call? But I also don't understand why 3gpp has this call flow this way. I'm not = an expert on conference call models by any stretch, and I'm not trying to s= econd-guess 3gpp, but it seems to me that this isn't what should happen in = this call case. From a logical perspective, the AS getting the resource-li= st should try to match the URI's in it. When it doesn't find them, it shou= ld act *exactly* as it would if it were not by coincidence the same AS whic= h was in the original call flows - in other words, it should generate new I= NVITEs with a Replaces header for the callid/tags in the resource-list. Th= ose would go to the URI's in the resource-list, which would be the B2BUA th= at UA-A made the original call to. The AS will eventually get that INVITE = with Replaces back again, through that b2bua, things match up, and all is g= ood. =20 It's more signaling, but really this call scenario is rare to begin with an= d you need the call signaling to avoid the issues raised earlier. And it w= ill actually replace the original call dialogs, which is a good thing. And= it will work the same way as cases where the conference AS is not by coinc= idence the same as the original calls. (I think) -hadriel From HKaplan@acmepacket.com Tue Apr 27 11:46:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AE028C189 for ; Tue, 27 Apr 2010 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 NfwDHaCT+0rP for ; Tue, 27 Apr 2010 11:46:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5EA1B28C191 for ; Tue, 27 Apr 2010 11:44: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, 27 Apr 2010 14:44:36 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 14:44:36 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 27 Apr 2010 14:44:36 -0400 Thread-Topic: [dispatch] New version: draft-kaplan-dispatch-session-id-01 Thread-Index: AcrmMYeRh4icbzPySYS4AXt9+8/2SwAB+Twg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1293@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <4BD722CD.8020203@nostrum.com> In-Reply-To: <4BD722CD.8020203@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:46:02 -0000 Good point. I'll change it back to 128 bits. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 27, 2010 1:46 PM > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 >=20 > On 4/17/10 13:42, Apr 17, Hadriel Kaplan wrote: > > - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary > number can be generated/recorded/used > > >=20 > If this is only for troubleshooting, that's probably Good Enough [tm]. > But I've seen a few messages clamoring for this to be useful for > non-debugging purposes. If these identifiers are used for correlation > after the fact -- especially for something with real-world ramifications > like billing, legal intercept, criminal forensics or the like -- I think > 64 bits is a bit paltry. >=20 > Keep in mind that SIP is being deployed in carrier grade systems, with > high rates of throughput. >=20 > For estimation purposes, let's consider AT&T's voice network. As of > 1999, it carried about 300 millon calls per day [1]. Let's imagine some > day in the future in which these are all traveling over SIP, but the > traffic load has mysteriously not increased. So we're being somewhat > optimistic about SIP's adoption, but very pessimistic about calling > patterns. >=20 > This is a classic example of the Birthday Paradox [2]. Using a 64-bit > integer as the number of bins: >=20 > - If you were to analyze one day's traffic, you'd have about a 0.2% > chance of a collision. >=20 > - Analyzing one week of traffic (seven days), that chance goes up to 11.2= %. >=20 > - And, over the course of a month (30 days) -- where there might be > billing implications -- it skyrockets to 88.9%. >=20 > Now, if you doubled length of the identifier -- to 128 bits -- you'd > have to process 26 quadrillion (26 * 10^15) calls before your chance of > collision rose as high as .0001%. That's about 238,000 years worth of > calls. >=20 > And *that* should be good enough for non-debugging purposes. So I'd > propose we use 32 hex chars instead of 16. >=20 > /a >=20 >=20 > [1] > http://www2.research.att.com/areas/visualization/papers_videos/abstract.p= h > p?id=3DCG-AbelloGKN99 > [2] > http://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem From HKaplan@acmepacket.com Tue Apr 27 11:49:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95553A6A2D for ; Tue, 27 Apr 2010 11:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 hW6LCdYuLuO0 for ; Tue, 27 Apr 2010 11:49:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 744ED3A6781 for ; Tue, 27 Apr 2010 11:49:02 -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, 27 Apr 2010 14:48:49 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 14:48:49 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Tue, 27 Apr 2010 14:48:49 -0400 Thread-Topic: Using session-id for dialog correlation Thread-Index: AcrmNuwi6qvbpieVQEqOL1XxIRQ97QAAsfwg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1296@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1281@mail> 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] Using session-id for dialog correlation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 27 Apr 2010 18:49:24 -0000 Just to be clear, I use the term "B2BUA" in the sense of not being a generi= c 3261 proxy. I am not referring to SBC's. In the 3gpp diagram these were= labeled as "Intermediate IM CN subsystem entities", which could be 3261 pr= oxies; but the diagram shows them changing the call-id and thus I just labe= led them as "B2BUA" to be simpler. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Tuesday, April 27, 2010 2:25 PM > To: dispatch@ietf.org > Subject: [dispatch] Using session-id for dialog correlation >=20 > [sorry for the long email, but it's a complicated topic] >=20 > A few people have mentioned that the session-id draft should not only be > for troubleshooting, but for dialog correlation as well. >=20 > Specifically to handle this type of scenario, based on 3GPP 24.605 annex > A.2.2 >=20 > +----+ +-----+ +----+ +-----+ +----+ > |UA-A| |B2BUA| | AS | |B2BUA| |UA-B| > +----+ +-----+ +----+ +-----+ +----+ > | | | | | > |INVITE | | | | > |callid:1a |callid:1b |callid:1c |callid:1d | > |----------->|----------->|---------->|----------->| > |sessid:1 |sessid:1 |sessid:1 |sessid:1 | > | | | | | > |INVITE | | | | > |callid:2a |callid:2b | | | > |----------->|----------->| | | > |sessid:2 |sessid:2 |re-INVITE | | > |RL|RL|callid:1c |callid:1d | > | | |---------->|----------->| > | | |sessid:1 |sessid:1 | > | | | | | >=20 > [note: this is a simplified drawing from 3gpp's - in 3gpp it has two > called parties: UA-B and UA-C, but it doesn't really matter with regards > to the problem] >=20 > Explanation of drawing: > UA-A has a call with UA-B through multiple B2BUA's and an Application > Server. The dialogs of that call all have the same session-id, but uniqu= e > call-id/tags. >=20 > UA-A wants to invoke a 3rd party conference facility in the AS, and > reference the call with UA-B for that. In this particular 3gpp scenario, > to do that UA-A sends a new INVITE to the AS with a resource-list body (a > la RFC 5366) containing the call information for the original call. This > is the "RL" piece in the diagram. It has the calli-d/tags as > well, but they'll be wrong when received at the AS. >=20 > The AS processes that list, can't match the callid/tags in the resource- > lit but does match the session-id, and sends a re-INVITE to party B withi= n > the original call's dialog. >=20 > Do I have that right? >=20 > I think there are problems doing that. :( >=20 > 1) The Session-ID only provides a single value which is the same on both > "sides" of a B2BUA. The AS *is* a B2BUA, so when it gets the resource- > list with a Session-ID, how does it know which side of session-id 1 to re= - > INVITE? I.e., how does it know to send a re-INVITE to call-id 1c vs. 1b? > The tags were there to do that, but they no longer match. We could defin= e > a flag/param for Session-ID to indicate uac vs. uas, if you think that > would help (I was prepared to do that in the draft at one point, to avoid > this problem). >=20 > 2) What if the AS has multiple dialogs for that same Session-ID? It coul= d > have - for example in a "normal" ad-hoc rfc5366 conference scenario the A= S > could have invited multiple participants to the same initial conference > call, and could arguably use the same session-id for all legs. So if > another invite referred to that conference call, it would be ambiguous > which leg it meant. >=20 > 3) Let's say this call-flow actually worked, and the AS sent the re-INVIT= E > to UA-B. At that point, the B2BUA(s) on the left-hand side of the AS are > no longer in synch with regards to the call or media state. For example, > some B2BUA's will tear-down the call if media stops flowing through them > for too long. In this specific 3gpp spec it says the call was put on hol= d > before-hand, so that won't happen, but you get the idea: "bypassing" > b2bua's is brittle. >=20 > 4) In this *particular* scenario the solution is easier: make the B2BUA's > understand resource-lists, and make them change the callid/tags in them > correctly. After all, that's what's causing the mismatch at the AS. But > isn't this a rather unlikely/rare scenario? I mean do you really intend > every call to go through an AS, just in case it ends up becoming a 3pcc > conf call? >=20 > But I also don't understand why 3gpp has this call flow this way. I'm no= t > an expert on conference call models by any stretch, and I'm not trying to > second-guess 3gpp, but it seems to me that this isn't what should happen > in this call case. From a logical perspective, the AS getting the > resource-list should try to match the URI's in it. When it doesn't find > them, it should act *exactly* as it would if it were not by coincidence > the same AS which was in the original call flows - in other words, it > should generate new INVITEs with a Replaces header for the callid/tags in > the resource-list. Those would go to the URI's in the resource-list, > which would be the B2BUA that UA-A made the original call to. The AS wil= l > eventually get that INVITE with Replaces back again, through that b2bua, > things match up, and all is good. >=20 > It's more signaling, but really this call scenario is rare to begin with > and you need the call signaling to avoid the issues raised earlier. And > it will actually replace the original call dialogs, which is a good thing= . > And it will work the same way as cases where the conference AS is not by > coincidence the same as the original calls. (I think) >=20 > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From volker.hilt@alcatel-lucent.com Tue Apr 27 12:07:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51AF63A6A4A; Tue, 27 Apr 2010 12:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 dXOQu-JNtSee; Tue, 27 Apr 2010 12:07:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 3BB1C3A699F; Tue, 27 Apr 2010 12:07:24 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o3RJ79ow023981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 14:07:09 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o3RJ6rbe002557; Tue, 27 Apr 2010 14:07:09 -0500 Received: from [135.222.104.95] (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.2.213.0; Tue, 27 Apr 2010 14:07:00 -0500 Message-ID: <4BD73716.1050903@alcatel-lucent.com> Date: Tue, 27 Apr 2010 15:12:22 -0400 From: Volker Hilt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <429D5EE4-8790-4D0D-A7A7-CB2DE9E2D70A@nostrum.com><4BB5409E.5080108@alcatel-lucent.com><0F93BDF3-0A60-4E81-B427-3778613EAE45@nostrum.com><6FEFDA2E-C51F-451A-B0A4-3973580468D1@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141015EFC76@ftrdmel0.rd.francetelecom.fr><5DA01D2CA74FAF40ADF71DB4177D345A055BB760@misout7msgusr7b.ugd.att.com> <4BD5F5C5.1000705@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "bruno.chatras@orange-ftgroup.com" , "dispatch@ietf.org" , "NOEL, ERIC C \(ATTLABS\)" , "lars.eggert@nokia.com" , "Paul Jones \(paulej\)" , "sip-overload@ietf.org" Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control 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: Tue, 27 Apr 2010 19:07:31 -0000 Partha, please feel encouraged to submit your draft for consideration to the wg once it is chartered! Thanks, Volker Parthasarathi R (partr) wrote: > Hi all, > >> 2. A specification for an SIP overload control mechanism based on >> implicit/explicit feedback ==> Dec 2010 > > draft-partha-sip-overload-resource-availability is a draft based on explicit feedback mechanism (SUBSCRIBE/NOTIFY). This draft is an enhancement of H.323 Resource Availability Indication mechanism (RAI) which is widely deployed in H.323 network for handling overload situation. The draft mechanism is tested in our Lab and it is working fine for overloading of different resources like CPU, Memory, DSP, DS0. The proposed mechanism works well in case server has capability to handle audio & video and audio only call simultaneously. Could you please consider this draft for the above requirement. > > Thanks > Partha > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Volker Hilt > Sent: Tuesday, April 27, 2010 1:51 AM > To: NOEL, ERIC C (ATTLABS) > Cc: bruno.chatras@orange-ftgroup.com; dispatch@ietf.org; sip-overload@ietf.org; lars.eggert@nokia.com > Subject: Re: [dispatch] [sip-overload] Proposed SIP Overload Control Charter > > Eric, >> Wrt milestones deadlines: >> >> 1. A document describing key design considerations for a SIP overload >> control mechanism ==> Sep 2010 >> 2. A specification for an SIP overload control mechanism based on >> implicit/explicit feedback ==> Dec 2010 >> 3. A specification for a SIP load filtering mechanism ==> May >> 2011 >> >> I have a few comments: >> >> - Is item 1 a cleaned up version of draft-ietf-sipping-overload-design-02.pdf? >> ==> if so I am OK with Sep 2010 date. >> - Could item 2 consist of the documentation of one of the SIP overload control mechanism studied by the SIP overload design team coordinated by Volker? >> ==> Provided work consists of documenting one of the control mechanism studied by the SIP overload design team, then I am ok with Dec 2010. >> - With respect to item 3, are there any other related IETF activity besides draft-shen-sipping-load-control-event-package that need consideration? Is the expectation to validate the proposed load filtering mechanism through simulation? >> ==> Would like feedback on questions prior agreeing on May 2011 deadline. >> > The charter lays out milestones for items the proposed working group should produce. It is up to the WG to evaluate the drafts that have been proposed and adopt drafts that meet these milestones. The drafts you mention are candidates. They may or may not be adopted by the WG. > >> Lastly, what will be the mode of operation to actually work on these >> items? Continue sending comments on the sip-overload distribution >> list? Have regular sub-teams meeting (via conference calls)? >> > All discussions will happen on the sip-overload mailing list and all comments need to go to this list. We may use conference calls for specific topics if needed. If there is a need, calls will be announced on the mailing list. > > Thanks, > > Volker > > > > >> -----Original Message----- >> From: sip-overload-bounces@ietf.org >> [mailto:sip-overload-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Friday, April 23, 2010 4:54 AM >> To: rjsparks@nostrum.com >> Cc: volker.hilt@alcatel-lucent.com; dispatch@ietf.org; >> sip-overload@ietf.org; Gonzalo.Camarillo@ericsson.com; >> lars.eggert@nokia.com >> Subject: Re: [sip-overload] Proposed SIP Overload Control Charter >> >> I would prefer to see the SIP load filtering specification released by the end of 2010. >> BC >> >>> -----Message d'origine----- >>> De : sip-overload-bounces@ietf.org >>> [mailto:sip-overload-bounces@ietf.org] De la part de Robert Sparks >>> Envoyé : mercredi 21 avril 2010 17:29 À : Robert Sparks Cc : Volker >>> Hilt; DISPATCH; sip-overload@ietf.org; Gonzalo Camarillo; Lars Eggert >>> Objet : Re: [sip-overload] Proposed SIP Overload Control Charter >>> >>> Please comment on what these dates should actually be >>> >>> RjS >>> >>>> Milestones: >>>> >>>> Sep 2010 Design Considerations to IESG for publication as >>>> Informational Dec 2010 Specification for a SIP overload control >>>> mechanism based on implicit/explicit feedback to IESG for >>> publication >>>> as Proposed Standard May 2011 Specification for a SIP load >>> filtering >>>> mechaism to IESG for publication as Proposed Standard >>> _______________________________________________ >>> sip-overload mailing list >>> sip-overload@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-overload >>> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >> _______________________________________________ >> 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 stpeter@stpeter.im Tue Apr 27 13:13:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3D33A6A9D for ; Tue, 27 Apr 2010 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 7la0zJT2WQmd for ; Tue, 27 Apr 2010 13:13:52 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 62D933A6A3E for ; Tue, 27 Apr 2010 13:13:21 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4403240E39; Tue, 27 Apr 2010 14:13:08 -0600 (MDT) Message-ID: <4BD74552.309@stpeter.im> Date: Tue, 27 Apr 2010 14:13:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Musgrave References: <4BD6B499.2060908@telecomitalia.it> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050506000106070405000500" Cc: "mbarnes@nortelnetworks.com" , "dispatch@ietf.org" , "Markus.Isomaki@nokia.com" Subject: Re: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:13:53 -0000 This is a cryptographically signed message in MIME format. --------------ms050506000106070405000500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/27/10 5:17 AM, Peter Musgrave wrote: > Hi, >=20 > Overall I think the text is good. >=20 > One clarification. The charter says "one approach" is to combine the > XMPP and SIP into a single application. Do you regard cases where they > are in different applications and perhaps on different devices as "in > scope"? My understanding has always been that those problems are interesting but out of scope for now -- the group wants to make progress on a well-defined problem (dual-stack user agents) before trying to solve other problems. > If not, perhaps "The objective..." should be amended to make it clear > that only issues associated with combining them into a single > application are in scope? That seems appropriate. > If yes, then are mechanism for the applications to exchange info out of= scope? I think that it is out of scope for this group to work on coordination between single-stack (SIP only or XMPP only) user agents on the same device (or multiple devices controlled by the same user). But those who have proposed this work can correct me if I'm wrong. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050506000106070405000500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQyNzIwMTMwNlowIwYJKoZIhvcNAQkEMRYEFKLylIcgdGr6qLBJzTDN G7SoO8MdMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAAHmciAOBbGHdOG365HSoBk6nqzjedCs+m0oGqoNY 2tIh8BEmR2IXzF8SBaxGlXp5k8T4IBGDV1IiQf5Km89pSME0RirpRq8yQ43mndk1agP3OV8A kpEYoO2jhBIB1q5xbC7tJ5/uzXFIZI+6CdVanv1PsewYcNnQgVIxfCliupykegcQ++35v1Lh ARsKRj0RuwJeUULoUxm3vlXg65GsNZS5qEg2eYXeIHkRxA+XzwvqYSiO8TFsJotW7WbuoxEA MYEwSLynJ7IJA+UhSBjGbeKqVPYUgJaARw+yUG7q6qunin07OR+rFo5q/o0KIzy09S+vgydI NmLqBDW2JMTVwwAAAAAAAA== --------------ms050506000106070405000500-- From Simo.Veikkolainen@nokia.com Tue Apr 27 23:14:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903023A6AD6 for ; Tue, 27 Apr 2010 23:14:30 -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 bo6e2KsQ5wxw for ; Tue, 27 Apr 2010 23:14:29 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 649243A6AB4 for ; Tue, 27 Apr 2010 23:14:28 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3S6Dfn8003834; Wed, 28 Apr 2010 09:14:10 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Apr 2010 09:13:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Apr 2010 09:13:51 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 28 Apr 2010 08:13:50 +0200 From: To: , Date: Wed, 28 Apr 2010 08:13:46 +0200 Thread-Topic: [dispatch] Updated SIP and XMPP combined use charter proposal Thread-Index: AcrmRieF9mut3Ft2TJarvJZRiHbumwAU30qQ Message-ID: References: <4BD6B499.2060908@telecomitalia.it> <4BD74552.309@stpeter.im> In-Reply-To: <4BD74552.309@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2010 06:13:51.0421 (UTC) FILETIME=[F8EDF6D0:01CAE699] X-Nokia-AV: Clean Cc: mbarnes@nortelnetworks.com, dispatch@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [dispatch] Updated SIP and XMPP combined use charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 06:14:30 -0000 DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPkJlaGFsZiBP ZiBleHQgUGV0ZXIgU2FpbnQtQW5kcmUNCj5TZW50OiAyNyBBcHJpbCwgMjAxMCAyMzoxMw0KPlRv OiBQZXRlciBNdXNncmF2ZQ0KPkNjOiBtYmFybmVzQG5vcnRlbG5ldHdvcmtzLmNvbTsgZGlzcGF0 Y2hAaWV0Zi5vcmc7IElzb21ha2kgTWFya3VzDQo+KE5va2lhLUNJQy9Fc3BvbykNCj5TdWJqZWN0 OiBSZTogW2Rpc3BhdGNoXSBVcGRhdGVkIFNJUCBhbmQgWE1QUCBjb21iaW5lZCB1c2UgY2hhcnRl cg0KPnByb3Bvc2FsDQo+DQo+T24gNC8yNy8xMCA1OjE3IEFNLCBQZXRlciBNdXNncmF2ZSB3cm90 ZToNCj4+IEhpLA0KPj4NCj4+IE92ZXJhbGwgSSB0aGluayB0aGUgdGV4dCBpcyBnb29kLg0KPj4N Cj4+IE9uZSBjbGFyaWZpY2F0aW9uLiBUaGUgY2hhcnRlciBzYXlzICJvbmUgYXBwcm9hY2giIGlz IHRvIGNvbWJpbmUgdGhlDQo+PiBYTVBQIGFuZCBTSVAgaW50byBhIHNpbmdsZSBhcHBsaWNhdGlv bi4gRG8geW91IHJlZ2FyZCBjYXNlcyB3aGVyZSB0aGV5DQo+PiBhcmUgaW4gZGlmZmVyZW50IGFw cGxpY2F0aW9ucyBhbmQgcGVyaGFwcyBvbiBkaWZmZXJlbnQgZGV2aWNlcyBhcyAiaW4NCj4+IHNj b3BlIj8NCj4NCj5NeSB1bmRlcnN0YW5kaW5nIGhhcyBhbHdheXMgYmVlbiB0aGF0IHRob3NlIHBy b2JsZW1zIGFyZSBpbnRlcmVzdGluZyBidXQNCj5vdXQgb2Ygc2NvcGUgZm9yIG5vdyAtLSB0aGUg Z3JvdXAgd2FudHMgdG8gbWFrZSBwcm9ncmVzcyBvbiBhIHdlbGwtDQo+ZGVmaW5lZCBwcm9ibGVt IChkdWFsLXN0YWNrIHVzZXIgYWdlbnRzKSBiZWZvcmUgdHJ5aW5nIHRvIHNvbHZlIG90aGVyDQo+ cHJvYmxlbXMuDQoNClRoYXQgaGFzIGluZGVlZCBiZWVuIG91ciBpbnRlbnRpb24uDQoNCj4+IElm IG5vdCwgcGVyaGFwcyAiVGhlIG9iamVjdGl2ZS4uLiIgc2hvdWxkIGJlIGFtZW5kZWQgdG8gbWFr ZSBpdCBjbGVhcg0KPj4gdGhhdCBvbmx5IGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggY29tYmluaW5n IHRoZW0gaW50byBhIHNpbmdsZQ0KPj4gYXBwbGljYXRpb24gYXJlIGluIHNjb3BlPw0KPg0KPlRo YXQgc2VlbXMgYXBwcm9wcmlhdGUuDQo+DQo+PiBJZiB5ZXMsIHRoZW4gYXJlIG1lY2hhbmlzbSBm b3IgdGhlIGFwcGxpY2F0aW9ucyB0byBleGNoYW5nZSBpbmZvIG91dA0KPm9mIHNjb3BlPw0KDQpI b3cgYWJvdXQgIlRoZSBvYmplY3RpdmUgb2YgdGhpcyBXb3JraW5nIEdyb3VwIGlzIHRvIGRvY3Vt ZW50IGJlc3QgcHJhY3RpY2VzIGFuZCBkZXZlbG9wIHByb3RvY29sIGV4dGVuc2lvbnMgZm9yIGNv bWJpbmluZyBTSVAgYmFzZWQgdm9pY2UgYW5kIHZpZGVvIHdpdGggWE1QUCBiYXNlZCBJTSBhbmQg cHJlc2VuY2UgaW50byBhIHNpbmdsZSBhcHBsaWNhdGlvbiBzbyB0aGF0IGEgdW5pZmllZCB1c2Vy IGV4cGVyaWVuY2UgY2FuIGJlIG9mZmVyZWQgdG8gZW5kIHVzZXIuIj8NCg0KU2ltbw0KDQo+SSB0 aGluayB0aGF0IGl0IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBncm91cCB0byB3b3JrIG9uIGNv b3JkaW5hdGlvbg0KPmJldHdlZW4gc2luZ2xlLXN0YWNrIChTSVAgb25seSBvciBYTVBQIG9ubHkp IHVzZXIgYWdlbnRzIG9uIHRoZSBzYW1lDQo+ZGV2aWNlIChvciBtdWx0aXBsZSBkZXZpY2VzIGNv bnRyb2xsZWQgYnkgdGhlIHNhbWUgdXNlcikuDQo+DQo+QnV0IHRob3NlIHdobyBoYXZlIHByb3Bv c2VkIHRoaXMgd29yayBjYW4gY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcuIDopDQo+DQo+UGV0ZXIN Cj4NCj4tLQ0KPlBldGVyIFNhaW50LUFuZHJlDQo+aHR0cHM6Ly9zdHBldGVyLmltLw0KPg0KPg0K DQo= From Peter.Dawes@vodafone.com Wed Apr 28 01:12:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C53B3A6856 for ; Wed, 28 Apr 2010 01:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=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 KL6ZgvciL6oP for ; Wed, 28 Apr 2010 01:12:28 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by core3.amsl.com (Postfix) with ESMTP id D42463A6835 for ; Wed, 28 Apr 2010 01:12:27 -0700 (PDT) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id E28A845C4 for ; Wed, 28 Apr 2010 10:12:12 +0200 (CEST) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id D43A2438A; Wed, 28 Apr 2010 10:12:12 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Apr 2010 10:12:13 +0200 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, 28 Apr 2010 10:12:57 +0200 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3070B172CC6@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version: draft-kaplan-dispatch-session-id-01 Thread-Index: Acrl/coTxwQP6CBJRI28iwV/B87p+gAC1qwQAAFThvA= References: <101C6067BEC68246B0C3F6843BCCC1E3070B172CC6@MCHP058A.global-ad.net> From: "Dawes, Peter, VF-Group" To: "Hutton, Andrew" , "Peter Musgrave" X-OriginalArrivalTime: 28 Apr 2010 08:12:13.0998 (UTC) FILETIME=[826534E0:01CAE6AA] Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, laura.liess.dt@googlemail.com, "Cc: Roland Jesske" , Hadriel Kaplan Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:12:29 -0000 Hi Andy, Peter, Thanks for the explaining the implications of standards track. After checking http://www.ietf.org/iesg/informational-vs-experimental.html and RFC 2026, I think that this draft should be standards track. When the updated draft-kaplan-dispatch-session-id was announced, it was pointed out that RFC 5727 allows new header fields to be introduced by Informational RFCs but RFC 5727 says "The proposed header field MUST be of a purely informational nature and MUST NOT significantly change the behavior of SIP entities that support it." which does not seem to apply, particularly if Session-ID is not for troubleshooting only. =20 Regards, Peter =20 -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: 27 April 2010 14:03 To: Peter Musgrave; Dawes, Peter, VF-Group Cc: Cc: Roland Jesske; dispatch@ietf.org; laura.liess.dt@googlemail.com; Hadriel Kaplan; Martin.Huelsemann@telekom.de Subject: RE: New version: draft-kaplan-dispatch-session-id-01 Hi, Have a look at http://www.ietf.org/iesg/informational-vs-experimental.html and read section 2. This states: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. For me this suggests that this specification which seems to be important and probably will be widely implemented should be a standards track specification. Regards Andy > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: 27 April 2010 12:36 > To: Dawes, Peter, VF-Group > Cc: Hutton, Andrew; Cc: Roland Jesske; dispatch@ietf.org;=20 > laura.liess.dt@googlemail.com; Hadriel Kaplan;=20 > Martin.Huelsemann@telekom.de > Subject: Re: New version: draft-kaplan-dispatch-session-id-01 >=20 > Re: standards track >=20 > Ah...thanks for the clarification. >=20 > I misinterpreted this to mean "get adopted by a working group" and=20 > that was the idea I wanted to express support for. >=20 > Peter Musgrave >=20 > On Tue, Apr 27, 2010 at 7:26 AM, Dawes, Peter, VF-Group=20 > wrote: > > Hello Hadriel, All, > > Thanks for the draft. Similar to the other comments, I think that > > draft-kaplan-dispatch-session-id-01 should not be restricted to=20 > > troubleshooting. At least one other active draft discusses > correlating > > SIP dialogs > (draft-loreto-dispatch-disaggregated-media-01.txt), and the > > Session-ID header field could be thought of as correlating > a series of > > dialogs linked in series by B2BUAs. It might be that this > header field > > can be used for both purposes. > > > > Could you please clarify the importance of making the draft > "standards > > track"? I had a look at what standards track means in RFC > 4677 "The Tao > > of the IETF" and I found that it means the author gives up > control of > > the draft, the draft needs IETF (not just working group) > consensus and > > that the standards track should distinguish specifications that have > > been demonstrated to interoperate. Are these the reasons > for suggesting > > standards track? > >=20 From Peter.Dawes@vodafone.com Wed Apr 28 01:14:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89143A686C for ; Wed, 28 Apr 2010 01:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=1.450, 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 84yBL+yAfzhG for ; Wed, 28 Apr 2010 01:14:56 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by core3.amsl.com (Postfix) with ESMTP id DCA513A684B for ; Wed, 28 Apr 2010 01:14:54 -0700 (PDT) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id 7080E21483F for ; Wed, 28 Apr 2010 10:14:40 +0200 (CEST) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint02 (Postfix) with ESMTPS id 654AE214836 for ; Wed, 28 Apr 2010 10:14:40 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Apr 2010 10:14:41 +0200 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, 28 Apr 2010 10:15:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5A== From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 28 Apr 2010 08:14:41.0592 (UTC) FILETIME=[DA5E4380:01CAE6AA] Subject: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:14:58 -0000 Hello All, An updated draft is available on the topic of providing security for the media plane between a SIP client and its first-hop proxy (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-01.txt). This draft defines a "mediasec" header field parameter and a "mediasec" option tag to extend RFC 3329 "Security Mechanism Agreement for the Session Initiation Protocol (SIP)" to apply to the media plane.=20 =20 This draft results from 3GPP requirements to secure the media plane controlled by SIP. The DTLS-SRTP work being done in IETF could not be used because security setup is done within the media plane, and the media plane might not be available at session setup. Also, DTLS-SRTP does not meet the requirement for lawful interception to be undetectable. 3GPP media plane security is described in http://ftp.3gpp.org/ftp/Specs/2010-03/Rel-9/33_series/33328-910.zip. A new version of I-D, draft-dawes-dispatch-mediasec-parameter-01.txt has been successfully submitted by Peter Dawes and posted to the IETF repository. Filename: draft-dawes-dispatch-mediasec-parameter Revision: 01 Title: Capability Exchange for Media Plane Security Creation_date: 2010-04-19 WG ID: Independent Submission Number_of_pages: 21 Abstract: Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is already described in an RFC. This document extends negotiation of a security mechanism to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label security mechanisms that apply to the media plane.=20 =20 Best regards, Peter =20 =20 From adam@nostrum.com Wed Apr 28 06:26:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFC128C117 for ; Wed, 28 Apr 2010 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.180, 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 BVLGy-rXdqoq for ; Wed, 28 Apr 2010 06:26:51 -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 18E0B28C153 for ; Wed, 28 Apr 2010 06:20:56 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3SDKg3O098304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 08:20:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BD83629.1040705@nostrum.com> Date: Wed, 28 Apr 2010 08:20:41 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:26:51 -0000 On 4/28/10 03:15, Apr 28, Dawes, Peter, VF-Group wrote: > Also, DTLS-SRTP does not meet the requirement for lawful interception to be undetectable. > I'm afraid that requirement is out of scope for work undertaken in the IETF. The official, published, IETF-wide policy on lawful intercept is summarized as: "The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards." Please see RFC 2804 for further details. /a From pkyzivat@cisco.com Wed Apr 28 06:33:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0BF28C123 for ; Wed, 28 Apr 2010 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnY5bUFrv8DT for ; Wed, 28 Apr 2010 06:33:40 -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 9FD1D3A6C58 for ; Wed, 28 Apr 2010 06:30:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK/V10tAZnwM/2dsb2JhbACccHGjBJo5hQ4E X-IronPort-AV: E=Sophos;i="4.52,288,1270425600"; d="scan'208";a="105901119" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Apr 2010 13:30:20 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SDUK10024454; Wed, 28 Apr 2010 13:30:20 GMT Message-ID: <4BD8386B.7090707@cisco.com> Date: Wed, 28 Apr 2010 09:30:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:33:41 -0000 Peter - a question: Dawes, Peter, VF-Group wrote: > Hello All, > An updated draft is available on the topic of providing security for the > media plane between a SIP client and its first-hop proxy > (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-01.txt). > This draft defines a "mediasec" header field parameter and a "mediasec" > option tag to extend RFC 3329 "Security Mechanism Agreement for the > Session Initiation Protocol (SIP)" to apply to the media plane. I am confused about the concept of "security for the media plane between a SIP client and its first-hop proxy". A proxy has no involvement with media. I read through the draft to understand better, but didn't gain enlightenment there. In fact I found no mention of proxies at all. However I did find that the mechanism only applies in cases where there is a single Via header, which means the server must be one hop removed from the client. So I haven't been able to discern if this is just a matter of the first hop from the client enforcing a requirement that media security be used between the UAC and UAS, or if there is some expectation that the proxy will in fact control the receipt and encryption/decryption of the media. That might have been clearer if the examples showed the SDP. Thanks, Paul From laura.liess.dt@googlemail.com Wed Apr 28 07:42:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260DE3A68FA for ; Wed, 28 Apr 2010 07:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=0.936, 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 fdbI6cpduhQ4 for ; Wed, 28 Apr 2010 07:42:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C49AC3A6B53 for ; Wed, 28 Apr 2010 07:40:42 -0700 (PDT) Received: by wwi17 with SMTP id 17so1080870wwi.31 for ; Wed, 28 Apr 2010 07:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9lwEULo0ARqZwnnr7VXoOOKvzE8JwUvdWnIKUoRN60c=; b=kTu1nBFrQdMXjSBTKwoMli1fbRDLt9vDZ2dwbyxUsefknQ05YMfs1hUOB4yDU4SB4L naJF77EBcM0aTb5pVhhJfKck0myqpGB5NqklnAoxJEweBgX88lVE4wTAzRbAItdlrHHJ jWF72NZ8COq+ozzsTd0+gVnnthXBmeVHMSgwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eP8/J7wA5lEteHOy5TTx7quTUIBTvN1DEo+WeskyZ0aBfPqKIJ3LhsvfbaN9fVRXDO 1w0VYrt2qnMfEPydZCsagyipct4DRPJDLi+/4/Ka9AW8aimPo/pCRSJq+72YAH7fFghR NivJVnQNzqh+z2SIThZTaVUAJxgTwQOAkfLAU= MIME-Version: 1.0 Received: by 10.216.160.213 with SMTP id u63mr3753407wek.128.1272465626170; Wed, 28 Apr 2010 07:40:26 -0700 (PDT) Received: by 10.216.171.135 with HTTP; Wed, 28 Apr 2010 07:40:25 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F121F@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCF10E@mail> <430FC6BDED356B4C8498F634416644A91A7A06BE40@mail> <430FC6BDED356B4C8498F634416644A91A8A5F121F@mail> Date: Wed, 28 Apr 2010 16:40:25 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , =?ISO-8859-1?Q?Martin_H=FClsemann?= , Roland Jesske Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:42:31 -0000 2010/4/27 Hadriel Kaplan : > > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Monday, April 26, 2010 9:57 AM >> >> For us it is important only not to reveal the IP-address in the >> original Call-ID. We also intend the messsage correlation software to >> know the key. The external =A0monitoring system stores all the in- and >> outgoing SIP-messages for a B2BUA. For every incomming, out-of-dialog >> message, the message correlation software looks for the Session-ID. If >> it finds one, it identifies all other messages, in and out, and the >> correlation is done. =A0 If there is no Session-ID in the message, it >> takes the Call-ID, hashes it with the key of the B2BUA and searches >> for an outgoing message with this Session-ID. > > As currently defined the B2BUA would insert the same Session-ID in the re= sponses it generates back upstream to the UAC - is that not enough for a mo= nitoring system to correlate both sides? =A0 I don't know the answer; hopef= ully some monitoring vendors will chime in. =A0I told several of them about= this draft but I don't know if they had anyone join dispatch. > What if the answer is missing? How can you tell then if the B2BUA did not sent the INVITE or if the UAS did not answer or if the B2BUA discarded the response instead of sending it to the UAC? Or did I miss something? Laura From keith.drage@alcatel-lucent.com Wed Apr 28 10:12:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003C13A69A9 for ; Wed, 28 Apr 2010 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=-2.093, BAYES_20=-0.74, 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 oAKnXMGHcLAL for ; Wed, 28 Apr 2010 10:12:33 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id F29C33A6950 for ; Wed, 28 Apr 2010 10:12:29 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3SHC3ZU007705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Apr 2010 19:12:11 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 28 Apr 2010 19:12:04 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Dawes, Peter, VF-Group" Date: Wed, 28 Apr 2010 19:12:03 +0200 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: Acrm13rPQePGIEYCROKXQDqmVC8/AQAHcRRA Message-ID: References: <4BD8386B.7090707@cisco.com> In-Reply-To: <4BD8386B.7090707@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.64 on 155.132.188.80 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 17:12:34 -0000 The underlying way this works is described in: http://www.3gpp.org/ftp/Specs/html-info/33328.htm Search for "a2ae" for the relevant bits of text. The first hop device is in fact a B2BUA with media, where it needs to imple= ment these procedures.=20 The general use case for these procedures would seem to be where you have a= n access technology that is not secure in itself, but needs some level of s= ecurity therefore provided. So WLAN uses accessing 3G would use it, but 3G = users would not, because the underlying bearers are already security protec= ted to an extent. I'll leave Peter to discuss how much more introductory material should be i= n the document, but this at least will hopefully help you understand what i= s happening. regards Keith=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, April 28, 2010 2:30 PM > To: Dawes, Peter, VF-Group > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 > Peter - a question: >=20 > Dawes, Peter, VF-Group wrote: > > Hello All, > > An updated draft is available on the topic of providing=20 > security for=20 > > the media plane between a SIP client and its first-hop proxy=20 > >=20 > (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete > r-01.txt). > > This draft defines a "mediasec" header field parameter and=20 > a "mediasec" > > option tag to extend RFC 3329 "Security Mechanism Agreement for the=20 > > Session Initiation Protocol (SIP)" to apply to the media plane. >=20 > I am confused about the concept of "security for the media=20 > plane between a SIP client and its first-hop proxy". >=20 > A proxy has no involvement with media. I read through the=20 > draft to understand better, but didn't gain enlightenment=20 > there. In fact I found no mention of proxies at all. However=20 > I did find that the mechanism only applies in cases where=20 > there is a single Via header, which means the server must be=20 > one hop removed from the client. >=20 > So I haven't been able to discern if this is just a matter of=20 > the first hop from the client enforcing a requirement that=20 > media security be used between the UAC and UAS, or if there=20 > is some expectation that the proxy will in fact control the=20 > receipt and encryption/decryption of the media. >=20 > That might have been clearer if the examples showed the SDP. >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@cisco.com Wed Apr 28 10:26:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9C23A6A0C for ; Wed, 28 Apr 2010 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMgSGTjXep4t for ; Wed, 28 Apr 2010 10:26:32 -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 3D4473A69E5 for ; Wed, 28 Apr 2010 10:26:32 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMMM2EtAZnwM/2dsb2JhbACcdHGkK5ophQ4E X-IronPort-AV: E=Sophos;i="4.52,289,1270425600"; d="scan'208";a="105988437" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Apr 2010 17:26:19 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SHQIA6004052; Wed, 28 Apr 2010 17:26:18 GMT Message-ID: <4BD86FBB.4080406@cisco.com> Date: Wed, 28 Apr 2010 13:26:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BD8386B.7090707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , "Dawes, Peter, VF-Group" Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 17:26:34 -0000 DRAGE, Keith (Keith) wrote: > The underlying way this works is described in: > > http://www.3gpp.org/ftp/Specs/html-info/33328.htm > > Search for "a2ae" for the relevant bits of text. > > The first hop device is in fact a B2BUA with media, where it needs to implement these procedures. This is the key thing I was suspecting. If it needs to be a B2BUA for this to work, then talking about it as a proxy is inappropriate. Thanks, Paul > The general use case for these procedures would seem to be where you have an access technology that is not secure in itself, but needs some level of security therefore provided. So WLAN uses accessing 3G would use it, but 3G users would not, because the underlying bearers are already security protected to an extent. > > I'll leave Peter to discuss how much more introductory material should be in the document, but this at least will hopefully help you understand what is happening. > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Wednesday, April 28, 2010 2:30 PM >> To: Dawes, Peter, VF-Group >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] New I-D: >> draft-dawes-dispatch-mediasec-parameter-01 >> >> Peter - a question: >> >> Dawes, Peter, VF-Group wrote: >>> Hello All, >>> An updated draft is available on the topic of providing >> security for >>> the media plane between a SIP client and its first-hop proxy >>> >> (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete >> r-01.txt). >>> This draft defines a "mediasec" header field parameter and >> a "mediasec" >>> option tag to extend RFC 3329 "Security Mechanism Agreement for the >>> Session Initiation Protocol (SIP)" to apply to the media plane. >> I am confused about the concept of "security for the media >> plane between a SIP client and its first-hop proxy". >> >> A proxy has no involvement with media. I read through the >> draft to understand better, but didn't gain enlightenment >> there. In fact I found no mention of proxies at all. However >> I did find that the mechanism only applies in cases where >> there is a single Via header, which means the server must be >> one hop removed from the client. >> >> So I haven't been able to discern if this is just a matter of >> the first hop from the client enforcing a requirement that >> media security be used between the UAC and UAS, or if there >> is some expectation that the proxy will in fact control the >> receipt and encryption/decryption of the media. >> >> That might have been clearer if the examples showed the SDP. >> >> Thanks, >> Paul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From jmpolk@cisco.com Wed Apr 28 14:25:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EC63A6899 for ; Wed, 28 Apr 2010 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuQVnULFmShH for ; Wed, 28 Apr 2010 14:25:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A4ACC3A6860 for ; Wed, 28 Apr 2010 14:25:10 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,290,1270425600"; d="scan'208";a="522127463" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2010 21:24:58 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3SLOu2M023994; Wed, 28 Apr 2010 21:24:57 GMT Message-Id: <201004282124.o3SLOu2M023994@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Apr 2010 16:24:55 -0500 To: Paul Kyzivat , "DRAGE, Keith (Keith)" From: "James M. Polk" In-Reply-To: <4BD86FBB.4080406@cisco.com> References: <4BD8386B.7090707@cisco.com> <4BD86FBB.4080406@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 21:25:12 -0000 At 12:26 PM 4/28/2010, Paul Kyzivat wrote: >DRAGE, Keith (Keith) wrote: >>The underlying way this works is described in: >>http://www.3gpp.org/ftp/Specs/html-info/33328.htm >>Search for "a2ae" for the relevant bits of text. >>The first hop device is in fact a B2BUA with media, where it needs >>to implement these procedures. > >This is the key thing I was suspecting. >If it needs to be a B2BUA for this to work, then talking about it as >a proxy is inappropriate. > > Thanks, > Paul > >>The general use case for these procedures would seem to be where >>you have an access technology that is not secure in itself, but >>needs some level of security therefore provided. So WLAN uses >>accessing 3G would use it, but 3G users would not, this makes it appear in an SBC role (which does always receive the media) more than a B2BUA role (which doesn't always (i.e., perhaps rarely) receive the media). If this is agreed to, then this can be more of an e2e scenario in which DTLS-SRTP can be used, in which the P-CSCF has the decryption keys for the media - thus able to meet the requirements for LI that the IETF cannot address, per RFC 2804, as Adam stated already. I'm also not completely clear now SRTP can be used at all in this scenario, given the scenario assumes that SRTP breaks the requirements for LI capture. Thus, isn't this doc advocating a mandate that (effectively) "there shall be no SRTP between the UE and the first hop proxy (that really isn't a proxy) because it breaks the LI requirements that 3GPP wants to address (that the IETF can't)".... this appears curious at best James >>because the underlying bearers are already security protected to an extent. >>I'll leave Peter to discuss how much more introductory material >>should be in the document, but this at least will hopefully help >>you understand what is happening. >>regards >>Keith >>>-----Original Message----- >>>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>>On Behalf Of Paul Kyzivat >>>Sent: Wednesday, April 28, 2010 2:30 PM >>>To: Dawes, Peter, VF-Group >>>Cc: dispatch@ietf.org >>>Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 >>> >>>Peter - a question: >>> >>>Dawes, Peter, VF-Group wrote: >>>>Hello All, >>>>An updated draft is available on the topic of providing >>>security for >>>>the media plane between a SIP client and its first-hop proxy >>>(http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete >>> >> r-01.txt). >>>>This draft defines a "mediasec" header field parameter and >>>a "mediasec" >>>>option tag to extend RFC 3329 "Security Mechanism Agreement for >>>>the Session Initiation Protocol (SIP)" to apply to the media plane. >>>I am confused about the concept of "security for the media plane >>>between a SIP client and its first-hop proxy". >>> >>>A proxy has no involvement with media. I read through the draft to >>>understand better, but didn't gain enlightenment there. In fact I >>>found no mention of proxies at all. However I did find that the >>>mechanism only applies in cases where there is a single Via >>>header, which means the server must be one hop removed from the client. >>> >>>So I haven't been able to discern if this is just a matter of the >>>first hop from the client enforcing a requirement that media >>>security be used between the UAC and UAS, or if there is some >>>expectation that the proxy will in fact control the receipt and >>>encryption/decryption of the media. >>> >>>That might have been clearer if the examples showed the SDP. >>> >>> 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 HKaplan@acmepacket.com Wed Apr 28 21:46:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E725928C194 for ; Wed, 28 Apr 2010 21:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 WzjaipYJ8QPh for ; Wed, 28 Apr 2010 21:46:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CCB0C28C0DC for ; Wed, 28 Apr 2010 21:46:09 -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, 29 Apr 2010 00:45:55 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Apr 2010 00:45:54 -0400 From: Hadriel Kaplan To: "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Thu, 29 Apr 2010 00:45:54 -0400 Thread-Topic: New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 04:46:11 -0000 Hey Peter, Have you looked at RFC 3840? Wouldn't just registering a new feature tag for sdes-srtp in IANA be what y= ou need? =20 Why do you need an option-tag, and why does this need to be in sec-agree? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dawes, Peter, VF-Group > Sent: Wednesday, April 28, 2010 4:15 AM > To: dispatch@ietf.org > Subject: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 >=20 > Hello All, > An updated draft is available on the topic of providing security for the > media plane between a SIP client and its first-hop proxy > (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-01.txt). > This draft defines a "mediasec" header field parameter and a "mediasec" > option tag to extend RFC 3329 "Security Mechanism Agreement for the > Session Initiation Protocol (SIP)" to apply to the media plane. >=20 > This draft results from 3GPP requirements to secure the media plane > controlled by SIP. The DTLS-SRTP work being done in IETF could not be > used because security setup is done within the media plane, and the > media plane might not be available at session setup. Also, DTLS-SRTP > does not meet the requirement for lawful interception to be > undetectable. 3GPP media plane security is described in > http://ftp.3gpp.org/ftp/Specs/2010-03/Rel-9/33_series/33328-910.zip. >=20 > A new version of I-D, draft-dawes-dispatch-mediasec-parameter-01.txt has > been successfully submitted by Peter Dawes and posted to the IETF > repository. >=20 > Filename: draft-dawes-dispatch-mediasec-parameter > Revision: 01 > Title: Capability Exchange for Media Plane Security > Creation_date: 2010-04-19 > WG ID: Independent Submission > Number_of_pages: 21 >=20 > Abstract: > Negotiating the security mechanisms used between a Session Initiation > Protocol (SIP) user agent and its next-hop SIP entity is already > described in an RFC. This document extends negotiation of a security > mechanism to the media plane by defining a new Session Initiation > Protocol (SIP) header field parameter to label security mechanisms that > apply to the media plane. >=20 > Best regards, > Peter >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From peter.leis@nsn.com Thu Apr 29 02:08:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922333A6862 for ; Thu, 29 Apr 2010 02:08:46 -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 MwuBnYbfhFcS for ; Thu, 29 Apr 2010 02:08:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5FD7328C201 for ; Thu, 29 Apr 2010 02:08:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3T984In006728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Apr 2010 11:08:04 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3T983cK026612; Thu, 29 Apr 2010 11:08:04 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 11:08:03 +0200 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, 29 Apr 2010 11:08:02 +0200 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIA= References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 29 Apr 2010 09:08:03.0729 (UTC) FILETIME=[79675810:01CAE77B] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 09:08:46 -0000 hello, RFC 3840 does not help here. We need a solution where the UA can indicate its support for sdes-srtp, but also where the SBC (P-CSCF) can indicate its support for sdes-srtp. Both needs to happen at registration time. =20 RFC 3840 does only cover UA indicating support, but not SBC indicating support. regards Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan Sent: Thursday, April 29, 2010 6:46 AM To: Dawes, Peter, VF-Group; dispatch@ietf.org Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Hey Peter, Have you looked at RFC 3840? Wouldn't just registering a new feature tag for sdes-srtp in IANA be what you need? =20 Why do you need an option-tag, and why does this need to be in sec-agree? -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dawes, Peter, VF-Group > Sent: Wednesday, April 28, 2010 4:15 AM > To: dispatch@ietf.org > Subject: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 >=20 > Hello All, > An updated draft is available on the topic of providing security for the > media plane between a SIP client and its first-hop proxy > (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-01.txt). > This draft defines a "mediasec" header field parameter and a "mediasec" > option tag to extend RFC 3329 "Security Mechanism Agreement for the > Session Initiation Protocol (SIP)" to apply to the media plane. >=20 > This draft results from 3GPP requirements to secure the media plane > controlled by SIP. The DTLS-SRTP work being done in IETF could not be > used because security setup is done within the media plane, and the > media plane might not be available at session setup. Also, DTLS-SRTP > does not meet the requirement for lawful interception to be > undetectable. 3GPP media plane security is described in > http://ftp.3gpp.org/ftp/Specs/2010-03/Rel-9/33_series/33328-910.zip. >=20 > A new version of I-D, draft-dawes-dispatch-mediasec-parameter-01.txt has > been successfully submitted by Peter Dawes and posted to the IETF > repository. >=20 > Filename: draft-dawes-dispatch-mediasec-parameter > Revision: 01 > Title: Capability Exchange for Media Plane Security > Creation_date: 2010-04-19 > WG ID: Independent Submission > Number_of_pages: 21 >=20 > Abstract: > Negotiating the security mechanisms used between a Session Initiation > Protocol (SIP) user agent and its next-hop SIP entity is already > described in an RFC. This document extends negotiation of a security > mechanism to the media plane by defining a new Session Initiation > Protocol (SIP) header field parameter to label security mechanisms that > apply to the media plane. >=20 > Best regards, > Peter >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Peter.Dawes@vodafone.com Thu Apr 29 08:21:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF1528C137 for ; Thu, 29 Apr 2010 08:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.967, 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 QIe-h4HVMcJQ for ; Thu, 29 Apr 2010 08:21:03 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by core3.amsl.com (Postfix) with ESMTP id 1C27D28C138 for ; Thu, 29 Apr 2010 08:20:49 -0700 (PDT) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id 3137721481F for ; Thu, 29 Apr 2010 17:20:33 +0200 (CEST) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint02 (Postfix) with ESMTPS id 2401C2147DF; Thu, 29 Apr 2010 17:20:33 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 17:20:32 +0200 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, 29 Apr 2010 17:21:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: Acrnr50EGRZU1fx1StufV2NzSR6GhQ== From: "Dawes, Peter, VF-Group" To: "Paul Kyzivat" , "DRAGE, Keith (Keith" X-OriginalArrivalTime: 29 Apr 2010 15:20:32.0355 (UTC) FILETIME=[82390B30:01CAE7AF] Cc: dispatch@ietf.org Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:21:17 -0000 Hi Paul, Keith, Thanks for checking the draft. The encryption/decryption of the media happens at a security gateway controlled by the first-hop proxy, so the first-hop proxy passes the cryptographic key to this gateway. The first-hop proxy does not terminate a SIP dialog and initiate a new one, and I took the term "first-hop proxy" from RFC 3329 which negotiates security for SIP signalling, so I'm not sure that B2BUA is the correct term. I agree that this draft differs from RFC 3329 as it involves a security gateway for the media, and I agree that the gateway needs to be described in the draft. I also agree that SDP is relevant, so I will add examples.=20 Regards, Peter >> So I haven't been able to discern if this is just a matter of the=20 >> first hop from the client enforcing a requirement that media security >> be used between the UAC and UAS, or if there is some expectation that >> the proxy will in fact control the receipt and encryption/decryption=20 >> of the media. >> >> That might have been clearer if the examples showed the SDP. Message: 6 Date: Wed, 28 Apr 2010 13:26:19 -0400 From: Paul Kyzivat Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 To: "DRAGE, Keith (Keith)" Cc: "dispatch@ietf.org" , "Dawes, Peter, VF-Group" Message-ID: <4BD86FBB.4080406@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed =20 =20 DRAGE, Keith (Keith) wrote: > The underlying way this works is described in: >=20 > http://www.3gpp.org/ftp/Specs/html-info/33328.htm =20 >=20 > Search for "a2ae" for the relevant bits of text. >=20 > The first hop device is in fact a B2BUA with media, where it needs to implement these procedures.=20 This is the key thing I was suspecting. If it needs to be a B2BUA for this to work, then talking about it as a proxy is inappropriate. Thanks, Paul > The general use case for these procedures would seem to be where you have an access technology that is not secure in itself, but needs some level of security therefore provided. So WLAN uses accessing 3G would use it, but 3G users would not, because the underlying bearers are already security protected to an extent. >=20 > I'll leave Peter to discuss how much more introductory material should be in the document, but this at least will hopefully help you understand what is happening. >=20 > regards >=20 > Keith >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org ] On Behalf Of Paul Kyzivat >> Sent: Wednesday, April 28, 2010 2:30 PM >> To: Dawes, Peter, VF-Group >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] New I-D:=20 >> draft-dawes-dispatch-mediasec-parameter-01 >> >> Peter - a question: >> >> Dawes, Peter, VF-Group wrote: >>> Hello All, >>> An updated draft is available on the topic of providing >> security for >>> the media plane between a SIP client and its first-hop proxy >>> >> (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete =20 >> r-01.txt). >>> This draft defines a "mediasec" header field parameter and >> a "mediasec" >>> option tag to extend RFC 3329 "Security Mechanism Agreement for the=20 >>> Session Initiation Protocol (SIP)" to apply to the media plane. >> I am confused about the concept of "security for the media plane=20 >> between a SIP client and its first-hop proxy". >> >> A proxy has no involvement with media. I read through the draft to=20 >> understand better, but didn't gain enlightenment there. In fact I=20 >> found no mention of proxies at all. However I did find that the=20 >> mechanism only applies in cases where there is a single Via header,=20 >> which means the server must be one hop removed from the client. >> >> So I haven't been able to discern if this is just a matter of the=20 >> first hop from the client enforcing a requirement that media security >> be used between the UAC and UAS, or if there is some expectation that >> the proxy will in fact control the receipt and encryption/decryption=20 >> of the media. >> >> That might have been clearer if the examples showed the SDP. >> >> Thanks, >> Paul >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch =20 >> =20 ------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 =20 End of dispatch Digest, Vol 13, Issue 23 **************************************** =20 =20 From pkyzivat@cisco.com Thu Apr 29 08:37:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAA23A6A93 for ; Thu, 29 Apr 2010 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBJxKW0eL93b for ; Thu, 29 Apr 2010 08:37:36 -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 7AB3C3A6A40 for ; Thu, 29 Apr 2010 08:37:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC5F2UtAZnwN/2dsb2JhbACdD3GlBJl7hRAE X-IronPort-AV: E=Sophos;i="4.52,296,1270425600"; d="scan'208";a="106480803" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2010 15:37:16 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3TFbGBZ022603; Thu, 29 Apr 2010 15:37:16 GMT Message-ID: <4BD9A7AC.4050504@cisco.com> Date: Thu, 29 Apr 2010 11:37:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, "DRAGE, Keith \(Keith" Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:37:38 -0000 Peter, Dawes, Peter, VF-Group wrote: > Hi Paul, Keith, > Thanks for checking the draft. The encryption/decryption of the media > happens at a security gateway controlled by the first-hop proxy, so the > first-hop proxy passes the cryptographic key to this gateway. The > first-hop proxy does not terminate a SIP dialog and initiate a new one, Does this "first-hop proxy" change the SDP? That is the key. If it does, then it is not properly a proxy. If it does not, then no issue. Thanks, Paul > and I took the term "first-hop proxy" from RFC 3329 which negotiates > security for SIP signalling, so I'm not sure that B2BUA is the correct > term. I agree that this draft differs from RFC 3329 as it involves a > security gateway for the media, and I agree that the gateway needs to be > described in the draft. I also agree that SDP is relevant, so I will add > examples. > > Regards, > Peter > >>> So I haven't been able to discern if this is just a matter of the > >>> first hop from the client enforcing a requirement that media security > > >>> be used between the UAC and UAS, or if there is some expectation that > > >>> the proxy will in fact control the receipt and encryption/decryption > >>> of the media. > > >>> That might have been clearer if the examples showed the SDP. > > > > > > > Message: 6 > > Date: Wed, 28 Apr 2010 13:26:19 -0400 > > From: Paul Kyzivat > > Subject: Re: [dispatch] New I-D: > > draft-dawes-dispatch-mediasec-parameter-01 > > To: "DRAGE, Keith (Keith)" > > Cc: "dispatch@ietf.org" , "Dawes, Peter, VF-Group" > > > > Message-ID: <4BD86FBB.4080406@cisco.com> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > > DRAGE, Keith (Keith) wrote: > >> The underlying way this works is described in: > > >> http://www.3gpp.org/ftp/Specs/html-info/33328.htm > > > >> Search for "a2ae" for the relevant bits of text. > > >> The first hop device is in fact a B2BUA with media, where it needs to > implement these procedures. > > This is the key thing I was suspecting. > > If it needs to be a B2BUA for this to work, then talking about it as a > proxy is inappropriate. > > Thanks, > > Paul > >> The general use case for these procedures would seem to be where you > have an access technology that is not secure in itself, but needs some > level of security therefore provided. So WLAN uses accessing 3G would > use it, but 3G users would not, because the underlying bearers are > already security protected to an extent. > > >> I'll leave Peter to discuss how much more introductory material should > be in the document, but this at least will hopefully help you understand > what is happening. > > >> regards > > >> Keith > > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org > ] On Behalf Of Paul Kyzivat > >>> Sent: Wednesday, April 28, 2010 2:30 PM > >>> To: Dawes, Peter, VF-Group > >>> Cc: dispatch@ietf.org > >>> Subject: Re: [dispatch] New I-D: > >>> draft-dawes-dispatch-mediasec-parameter-01 > > >>> Peter - a question: > > >>> Dawes, Peter, VF-Group wrote: > >>>> Hello All, > >>>> An updated draft is available on the topic of providing > >>> security for > >>>> the media plane between a SIP client and its first-hop proxy > > >>> (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete > > >>> r-01.txt). > >>>> This draft defines a "mediasec" header field parameter and > >>> a "mediasec" > >>>> option tag to extend RFC 3329 "Security Mechanism Agreement for the > >>>> Session Initiation Protocol (SIP)" to apply to the media plane. > >>> I am confused about the concept of "security for the media plane > >>> between a SIP client and its first-hop proxy". > > >>> A proxy has no involvement with media. I read through the draft to > >>> understand better, but didn't gain enlightenment there. In fact I > >>> found no mention of proxies at all. However I did find that the > >>> mechanism only applies in cases where there is a single Via header, > >>> which means the server must be one hop removed from the client. > > >>> So I haven't been able to discern if this is just a matter of the > >>> first hop from the client enforcing a requirement that media security > > >>> be used between the UAC and UAS, or if there is some expectation that > > >>> the proxy will in fact control the receipt and encryption/decryption > >>> of the media. > > >>> That might have been clearer if the examples showed the SDP. > > >>> 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 > > > > > End of dispatch Digest, Vol 13, Issue 23 > > **************************************** > > > > From HKaplan@acmepacket.com Thu Apr 29 09:35:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DC83A6B07 for ; Thu, 29 Apr 2010 09:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 IInBR8UQfmxi for ; Thu, 29 Apr 2010 09:35:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DDE773A6AEB for ; Thu, 29 Apr 2010 09:35:45 -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, 29 Apr 2010 12:35:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Apr 2010 12:35:28 -0400 From: Hadriel Kaplan To: "Dawes, Peter, VF-Group" , Paul Kyzivat , "DRAGE, Keith (Keith" Date: Thu, 29 Apr 2010 12:35:27 -0400 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: Acrnr50EGRZU1fx1StufV2NzSR6GhQACDhPg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F16F9@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 16:35:47 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dawes, Peter, VF-Group > Sent: Thursday, April 29, 2010 11:21 AM >=20 > Hi Paul, Keith, > Thanks for checking the draft. The encryption/decryption of the media > happens at a security gateway controlled by the first-hop proxy, so the > first-hop proxy passes the cryptographic key to this gateway. The > first-hop proxy does not terminate a SIP dialog and initiate a new one, > and I took the term "first-hop proxy" from RFC 3329 which negotiates > security for SIP signalling, so I'm not sure that B2BUA is the correct > term. I agree that this draft differs from RFC 3329 as it involves a > security gateway for the media, and I agree that the gateway needs to be > described in the draft. I also agree that SDP is relevant, so I will add > examples. Technically it *is* a B2BUA (and an SBC is a B2BUA). A "Proxy" never modif= ies SDP, by definition. Likewise if the "Proxy" does transcoding, or media= relay, or IPv6-IPv6 media interworking, etc. - it's a B2BUA, not a "Proxy"= . The sec-agree stuff could be done in a real Proxy, because it affected s= ignaling layer only (even then it's debatable, since it removes the option-= tag from the Require header). It'll confuse people to call this next-hop thing a Proxy - we just need to = call a spade a spade. So to be consistent with standard terminology the dr= aft should just call it a B2BUA. -hadriel From HKaplan@acmepacket.com Thu Apr 29 09:59:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE2728C138 for ; Thu, 29 Apr 2010 09:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 ZLTvUmKEgJ1v for ; Thu, 29 Apr 2010 09:59:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D8A9728C28F for ; Thu, 29 Apr 2010 09:58:51 -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, 29 Apr 2010 12:58:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Apr 2010 12:58:37 -0400 From: Hadriel Kaplan To: "Leis, Peter (NSN - DE/Munich)" , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Thu, 29 Apr 2010 12:58:31 -0400 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AA== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1711@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> 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] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 16:59:02 -0000 > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > Sent: Thursday, April 29, 2010 5:08 AM > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org >=20 > RFC 3840 does not help here. We need a solution where the UA can > indicate its support for sdes-srtp, but also where the SBC (P-CSCF) can > indicate its support for sdes-srtp. Both needs to happen at registration > time. Right, but I'm trying to figure out why that is. I mean what's the reason = the UA needs to know at Registration time that it's next-hop b2bua can do s= rtp, instead of letting SDP handle it? I *think* the answer is so that it can later send an INVITE with an SDP off= er without failing the request - is that the reason? > RFC 3840 does only cover UA indicating support, but not SBC indicating > support. Actually, in a way it does. An SBC is a B2BUA. As a UA, it can indicate f= eature tags. What it *can't* do is indicate it in the REGISTER response it= sends to the UA. But the UA could send an OPTIONS to the B2BUA and get it= in a feature tag of the response to the OPTIONS. I know it sucks to send = more SIP messages, but I don't see how to avoid that and be consistent with= the SIP architecture. It's really weird for a REGISTER response to indica= te media capabilities of the Registrar. -hadriel From gao.yang2@zte.com.cn Thu Apr 29 20:57:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F066B28C13F for ; Thu, 29 Apr 2010 20:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.338 X-Spam-Level: X-Spam-Status: No, score=-98.338 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 K1HHSNml1oEV for ; Thu, 29 Apr 2010 20:57:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 366C53A69FD for ; Thu, 29 Apr 2010 20:57:32 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887992332426; Fri, 30 Apr 2010 11:53:09 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.992332426; Fri, 30 Apr 2010 11:57:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3U3vEEh005752 for ; Fri, 30 Apr 2010 11:57:14 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 30 Apr 2010 11:55:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-30 11:57:08, Serialize complete at 2010-04-30 11:57:08 Content-Type: multipart/alternative; boundary="=_alternative 0015AF7348257715_=" X-MAIL: mse2.zte.com.cn o3U3vEEh005752 Subject: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 30 Apr 2010 03:57:34 -0000 This is a multipart message in MIME format. --=_alternative 0015AF7348257715_= Content-Type: text/plain; charset="US-ASCII" Hi, For people caring about SIP/IMS's network management level, I think one application independency AAA infrastructure is future direction for SIP/IMS. I'd like to know how many people have the same interest? If you have any comments/feeling/suggestion for this topic, feel free to go on. Telecom Core Network IMS(IP Multimedia Subsystem) is aimed for unified user management, unified authentication, unified policy/charging and unified service control, but it is tightly coupled with SIP. While the telecom core network operators want to deploy any non-sip application, they find that the unified platform(IMS) would not be suitable. We may conclude from the situation that, if telecom (core network) operators want to make one infrastructure(unified user management, unified authentication, unified policy/charging and unified service control) suitable for any application(sip and non-sip), they need make an sip decoupling AAA infrastructure at first. Making IMS's AAA based on HIP and IMS's multimedia level still on sip, would make IMS's infrastructure open for any other protocol and application. And if the telecom (core network) operators want to embrace more and more non-sip application, HIP may be the only way. Meanwhile, Could Computing and even M2M network also can get benefit from such application independency AAA infrastructure: Clouding Computing Some standard cloud/grid computing technology is based on Web. On the web platform, it is easy to bulid one AAA infrastructure and open for appliaction such as SOA. But if we want to build web and non-web(such as RAI) application on the same platform, there's the same problem IMS has. So, if IT industry's could computing want to embrace non-web application, HIP may be the same way again. M2M Network Machine to machine network is hot now. But it also need one application independency AAA infrastructure as platform for all the conceivable application protocols. HIP is still a good choice for it. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0015AF7348257715_= Content-Type: text/html; charset="US-ASCII"
Hi,

For people caring about SIP/IMS's network management level, I think one application independency AAA infrastructure is future direction for SIP/IMS. I'd like to know how many people have the same interest? If you have any comments/feeling/suggestion for this topic, feel free to go on.

Telecom Core Network

IMS(IP Multimedia Subsystem) is aimed for unified user management, unified authentication, unified policy/charging and unified service control, but it is tightly coupled with SIP. While the telecom core network operators want to deploy any non-sip application, they find that the unified platform(IMS) would not be suitable.  

We may conclude from the situation that, if telecom (core network) operators want to make one infrastructure(unified user management, unified authentication, unified policy/charging and unified service control) suitable for any application(sip and non-sip), they need make an sip decoupling AAA infrastructure at first.

Making IMS's AAA based on HIP and IMS's multimedia level still on sip, would make IMS's infrastructure open for any other protocol and application. And if the telecom (core network) operators want to embrace more and more non-sip application, HIP may be the only way.

Meanwhile, Could Computing and even M2M network also can get benefit from such application independency AAA infrastructure:

Clouding Computing

Some standard cloud/grid computing technology is based on Web. On the web platform, it is easy to bulid one AAA infrastructure and open for appliaction such as SOA. But if we want to build web and non-web(such as RAI) application on the same platform, there's the same problem IMS has.
So, if IT industry's could computing want to embrace non-web application, HIP may be the same way again.

M2M Network
Machine to machine network is hot now. But it also need one application independency AAA infrastructure as platform for all the conceivable application protocols. HIP is still a good choice for it.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0015AF7348257715_=-- From gao.yang2@zte.com.cn Thu Apr 29 21:20:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EAB28C159 for ; Thu, 29 Apr 2010 21:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.303 X-Spam-Level: X-Spam-Status: No, score=-99.303 tagged_above=-999 required=5 tests=[AWL=2.535, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 qJRxkXeD17aM for ; Thu, 29 Apr 2010 21:20:11 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CF77928C14C for ; Thu, 29 Apr 2010 21:19:50 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Fri, 30 Apr 2010 12:16:02 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 43572.992332426; Fri, 30 Apr 2010 12:15:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3U4JCSq035125 for ; Fri, 30 Apr 2010 12:19:14 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 30 Apr 2010 12:17:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-30 12:19:08, Serialize complete at 2010-04-30 12:19:08 Content-Type: multipart/alternative; boundary="=_alternative 0017B35348257715_=" X-MAIL: mse2.zte.com.cn o3U4JCSq035125 Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 30 Apr 2010 04:20:15 -0000 This is a multipart message in MIME format. --=_alternative 0017B35348257715_= Content-Type: text/plain; charset="US-ASCII" This figure is the concept and application stack for application independency AAA infrastructure using HIP: |--------| |--------| |---------| |---------| |SIP App1| |SIP App2| |NoSIPApp1| |NoSIPApp1| |--------| |--------| |---------| |---------| |-------------------| |------------------------| |SIP infrastructure | |NoSIP App infrastructure| |-------------------| |------------------------| |------------------------------------------------| |application independency AAA infrastructure(HIP)| |------------------------------------------------| And while we doing so, some part of SIP would be in application independency level, such as registration, user management, mobility management and so on. So, we may need a lightweight SIP. And further, SIP application level is the same as current deployment. Then, SIP AS, such as conference AS and other 3pcc controller can be still work in the application independency AAA infrastructure. |--------| |--------| |SIP App1| |SIP App2| |--------| |--------| |-------------------| |SIP infrastructure | |-------------------| =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0017B35348257715_= Content-Type: text/html; charset="US-ASCII"
This figure is the concept and application stack for application independency AAA infrastructure using HIP:

|--------| |--------|   |---------|    |---------|
|SIP App1| |SIP App2|   |NoSIPApp1|    |NoSIPApp1|
|--------| |--------|   |---------|    |---------|

|-------------------|   |------------------------|
|SIP infrastructure |   |NoSIP App infrastructure|
|-------------------|   |------------------------|

|------------------------------------------------|
|application independency AAA infrastructure(HIP)|
|------------------------------------------------|

And while we doing so, some part of SIP would be in application independency level, such as registration, user management, mobility management and so on. So, we may need a lightweight SIP.

And further, SIP application level is the same as current deployment. Then, SIP AS, such as conference AS and other 3pcc controller can be still work in the application independency AAA infrastructure.

|--------| |--------|
|SIP App1| |SIP App2|
|--------| |--------|

|-------------------|
|SIP infrastructure |
|-------------------|


===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0017B35348257715_=-- From peter.leis@nsn.com Fri Apr 30 01:18:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3903A6957 for ; Fri, 30 Apr 2010 01:18:03 -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 KF-Bq7S1sc7M for ; Fri, 30 Apr 2010 01:18:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id F2D7228C15B for ; Fri, 30 Apr 2010 01:17:36 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3U8HIw7015809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Apr 2010 10:17:18 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3U8HIew010007; Fri, 30 Apr 2010 10:17:18 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Apr 2010 10:17: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2010 10:17:17 +0200 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1711@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKaw References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1711@mail> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Hadriel Kaplan" , "Dawes, Peter, VF-Group" , X-OriginalArrivalTime: 30 Apr 2010 08:17:19.0071 (UTC) FILETIME=[8D0F26F0:01CAE83D] Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 08:18:03 -0000 =20 > -----Original Message----- > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Thursday, April 29, 2010 6:59 PM > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group;=20 > dispatch@ietf.org > Subject: RE: [dispatch] New I-D:=20 > draft-dawes-dispatch-mediasec-parameter-01 >=20 >=20 >=20 > > -----Original Message----- > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > > Sent: Thursday, April 29, 2010 5:08 AM > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org > >=20 > > RFC 3840 does not help here. We need a solution where the UA can > > indicate its support for sdes-srtp, but also where the SBC=20 > (P-CSCF) can > > indicate its support for sdes-srtp. Both needs to happen at=20 > registration > > time. >=20 > Right, but I'm trying to figure out why that is. I mean=20 > what's the reason the UA needs to know at Registration time=20 > that it's next-hop b2bua can do srtp, instead of letting SDP=20 > handle it? >=20 > I *think* the answer is so that it can later send an INVITE=20 > with an SDP offer without failing the request - is that the reason? >=20 Right >=20 > > RFC 3840 does only cover UA indicating support, but not SBC=20 > indicating > > support. >=20 > Actually, in a way it does. An SBC is a B2BUA. As a UA, it=20 > can indicate feature tags. What it *can't* do is indicate it=20 > in the REGISTER response it sends to the UA. But the UA=20 > could send an OPTIONS to the B2BUA and get it in a feature=20 > tag of the response to the OPTIONS. I know it sucks to send=20 > more SIP messages, but I don't see how to avoid that and be=20 > consistent with the SIP architecture. It's really weird for=20 > a REGISTER response to indicate media capabilities of the Registrar. >=20 use of OPTIONS was discussed, but due to the additional signalling, it was discarded. The indication of network support for SDES-SRTP in response to REGISTER is not included by the registrar, but by the network element placed at the edge (the SBC/B2BUA) > -hadriel >=20 From peter.musgrave@magorcorp.com Fri Apr 30 03:34:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35FD3A6825 for ; Fri, 30 Apr 2010 03:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_50=0.001, 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 Mq+GYaJA7yes for ; Fri, 30 Apr 2010 03:34:50 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 01BF73A659A for ; Fri, 30 Apr 2010 03:34:49 -0700 (PDT) Received: by gyh4 with SMTP id 4so21380gyh.31 for ; Fri, 30 Apr 2010 03:34:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.7.1 with SMTP id 1mr1867916ybg.191.1272623673224; Fri, 30 Apr 2010 03:34:33 -0700 (PDT) Received: by 10.150.92.9 with HTTP; Fri, 30 Apr 2010 03:34:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Apr 2010 06:34:33 -0400 Message-ID: From: Peter Musgrave To: gao.yang2@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Cc: dispatch@ietf.org Subject: Re: [dispatch] Open talk and investigation about HIP and SIP/IMS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 30 Apr 2010 10:34:50 -0000 Hi Gao, I am interested in the possibilities of HIP and SIP. (I can't speak to IMS since I don't work in that area - and frankly find it all very baffling). There is a passing reference to HIP in the p2psip work. How deeply to you see the interworking? Ideally in a "future perfect" world I would like to use HITs in URLs and SDPs and then have the socket do the NAT traversal for me as part of establishing the HIP connection. Then NAT traversal can live in the IP stack and not in my media/signalling code. Regards, Peter Musgrave From HKaplan@acmepacket.com Fri Apr 30 08:47:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576C63A6AB2 for ; Fri, 30 Apr 2010 08:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 l7WpnEd9GLy4 for ; Fri, 30 Apr 2010 08:47:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 50A143A688C for ; Fri, 30 Apr 2010 08:47:06 -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, 30 Apr 2010 11:46:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 30 Apr 2010 11:46:51 -0400 From: Hadriel Kaplan To: "Leis, Peter (NSN - DE/Munich)" , "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Fri, 30 Apr 2010 11:46:39 -0400 Thread-Topic: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcrmqvRb0oMPHsADQou35HEOHpkh5AAqrLBwAAk+WIAAD9d+AAAExKawAB23s7A= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F18BC@mail> References: <430FC6BDED356B4C8498F634416644A91A8A5F15EF@mail> <430FC6BDED356B4C8498F634416644A91A8A5F1711@mail> 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] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:47:07 -0000 > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > Sent: Friday, April 30, 2010 4:17 AM > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org >=20 > > -----Original Message----- > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Thursday, April 29, 2010 6:59 PM > > > > Right, but I'm trying to figure out why that is. I mean > > what's the reason the UA needs to know at Registration time > > that it's next-hop b2bua can do srtp, instead of letting SDP > > handle it? > > > > I *think* the answer is so that it can later send an INVITE > > with an SDP offer without failing the request - is that the reason? >=20 > Right =20 OK, and I also agree that's a real problem. That issue was raised in the I= ETF in 2006/2007. There was a very simple proposal to avoid that, in draft= -kaplan-mmusic-best-effort-srtp, but the decision of the MMUSIC WG was to i= nstead use draft-ietf-mmusic-sdp-capability-negotiation to accomplish it. = That draft is now in the RFC editor's queue. I know it's a lot of processi= ng overhead, but that was the decision. And I think 3gpp has put support f= or that into some release or other. > > > RFC 3840 does only cover UA indicating support, but not SBC > > indicating > > > support. > > > > Actually, in a way it does. An SBC is a B2BUA. As a UA, it > > can indicate feature tags. What it *can't* do is indicate it > > in the REGISTER response it sends to the UA. But the UA > > could send an OPTIONS to the B2BUA and get it in a feature > > tag of the response to the OPTIONS. I know it sucks to send > > more SIP messages, but I don't see how to avoid that and be > > consistent with the SIP architecture. It's really weird for > > a REGISTER response to indicate media capabilities of the Registrar. >=20 > use of OPTIONS was discussed, but due to the additional signalling, it > was discarded. Considering all of the other signaling already required (subscription to re= g-event, subscription to presence, xcap, possibly subscription to Config se= rver) isn't an OPTIONS just a nit at this point? And that way this could b= e a general solution, instead of a 3gpp-specific one. > The indication of network support for SDES-SRTP in response to REGISTER > is not included by the registrar, but by the network element placed at > the edge (the SBC/B2BUA) I know, but from the UA's perspective the REGISTER response is coming from = the Registrar, possibly through proxies. There's no logical/conceptual mod= el in the IETF for a REGISTER response to indicate media capabilities of so= me middle hop of the REGISTER. -hadriel From fluffy@cisco.com Fri Apr 30 08:52:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40ABF3A69F1 for ; Fri, 30 Apr 2010 08:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx+9YQFAMLMl for ; Fri, 30 Apr 2010 08:52:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6770D3A69A4 for ; Fri, 30 Apr 2010 08:52:24 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPaZ2ktAaMHG/2dsb2JhbACdIHGkdZoMhRIEgz4 X-IronPort-AV: E=Sophos;i="4.52,303,1270425600"; d="scan'208";a="190837116" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2010 15:52:10 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3UFq76o004478; Fri, 30 Apr 2010 15:52:08 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BD83629.1040705@nostrum.com> Date: Fri, 30 Apr 2010 09:52:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BD83629.1040705@nostrum.com> To: "Dawes, Peter, VF-Group" X-Mailer: Apple Mail (2.1078) Cc: DISPATCH Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:52:25 -0000 There has been more than one talks to 3GPP folks about how to do = intercept with DTLS-SRTP and the folks involved were well aware of the = undetectable requirement. Though I'm not infested in discussing wiretap = at IETF, I do believe it is possible to construct a system several = different way that meet the requirements I am aware of. (And it is = possible to do without B2BUA but it seem the system here could do in the = SBC) On Apr 28, 2010, at 7:20 AM, Adam Roach wrote: > On 4/28/10 03:15, Apr 28, Dawes, Peter, VF-Group wrote: >> Also, DTLS-SRTP does not meet the requirement for lawful interception = to be undetectable. >> =20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Fri Apr 30 12:30:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD13528C1D7 for ; Fri, 30 Apr 2010 12:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.627 X-Spam-Level: X-Spam-Status: No, score=-108.627 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 852H4h1XuGAX for ; Fri, 30 Apr 2010 12:30:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F118128C268 for ; Fri, 30 Apr 2010 12:30:36 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFvM2kurR7H+/2dsb2JhbACdJXGkU5oNhRIEgz4 X-IronPort-AV: E=Sophos;i="4.52,304,1270425600"; d="scan'208";a="190929596" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 30 Apr 2010 19:30:23 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3UJUM0t018534; Fri, 30 Apr 2010 19:30:22 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> Date: Fri, 30 Apr 2010 13:30:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1AF232C1-9025-4C5E-9F52-DC3BD9CDDE68@cisco.com> References: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1078) Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 30 Apr 2010 19:30:38 -0000 There probably any number of reasons that TRIP and others were never = deployed but I think one of the largest reasons is the questions about = authorization of identities. There are any number of protocols where = organization A can tell organization B that calls to phone number X = should be routed to server Y. Some examples are TRIP, DUNI, flavors of = ENUM, VIPR, and so on. The issue is you need a reason that B should = trust what A told them. Without a good answer that question, it's hard to see how one would use = the resulting solution.=20 Cullen =20 On Mar 5, 2010, at 1:04 PM, Dean Willis wrote: >=20 > Fundamental routing problem: >=20 > The fundamental SIP routing problem is this: I've been given a message = that is addressed either to a telephone number or to a user@domain name. = Where do I send this SIP request to next? >=20 > For "really stupid nodes", the question is easily answered: if the = destination isn't "me", I send the request to my default proxy and let = it deal with the problem. The default proxy might route the message = itself, or it might send back a 302 informing the me as to where to send = the request. It is important to note that in general, this "next hop" = decision represents a singular hop. We have no way to 302-respond with a = vector that specifies a sequence of relays to be used. >=20 > For a smarter host on "the open Internet", the answer is also easy. If = the target identifier is a "user@domain" URI, then I look up the domain = part in DNS and send the request there. If the target identifier is a = phone number, I use ENUM to look up an associated SIP URI, and I send = the request to that URI. Local routing tables that have much the same = effect may also be used, but are not specified in the governing RFCs. >=20 > But the "real world" (at least as we have allowed it to become = perverted) doesn't work that way. In this unhappy place, we don't have = direct end-to-end SIP routability. Instead, for many reasons good, bad, = and mostly practical, we must transit a set of relay nodes to get from = point A to B. Further complicating matters, we may not even know what = the whole set of nodes are, as various portions of the vector may be = "topology hidden." >=20 > So in practice, a "really stupid node" like a phone-gateway or PBX = sends its request to a routing proxy, which then uses a combination of = ENUM, DNS, and local policy to select a next-hop relay. Note that this = decision-making process tends to repeat at each relay node, since 1) we = don't have away to represent a multi-hop vector in a 302 response, and = 2) each node has limited view of the end-to-end visibility, in part due = to topology hiding. There's no good exchange mechanism for this = information, and no standard way to inform SIP nodes about how to use = it. We've seen proposals for source-context-sensitive private ENUM = solutions, mutagenic SIP proxy servers that return 302s, various = web-service approaches, and others. >=20 >=20 >=20 > TRIP: A solution? >=20 > TRIP proposes one model, wherein the "smart" nodes (called LS, or = Location Servers) exchange reachability information with each other = using a variant of BGP. This provides us a rich fabric for advertising = routes, control peering policy, deciding what parts of stuff to = "topology hide", and so on. Where BGP uses IP addresses (or the prefixes = thereof) as routing targets, TRIP uses telephone numbers (or the = prefixes thereof). Like BGP, it allows for "internal" routing using a = flood model, and "external" routing using more controlled policy. >=20 > In shortest essence, TRIP allows a first LS to say to an external LS = "For the following phone numbers and phone number ranges, I suggest you = use this other node or set of nodes (by IP or DNS name) as your next = hop(s). And I heard this from node X, who heard it from node Y, who = heard it from node Z." It allows allows a first LS to say to its = internal peer "Here are all the routes I know; feel free to use them and = please tell me about any you know that I don't." >=20 > But TRIP has not caught on. I've heard mixed answers, which boil down = to 1) its aggregation model for routes is broken, meaning Too Many = Routes (as a product of LNP which makes phone numbers messy), 2) it's = too complicated, and 3) Cisco owns the IPR, and I'm not sure they want = to share. I'm not sure I believe this is all there is to it. >=20 > The REAL problem with TRIP may be its fundamental routing model. It = assumes that the routing of a phone number is a property of a given = phone number (or aggregation range), and doesn't capitalize on the = actual peering relationships. Further, it doesn't really allows us to = talk about "routes to domains". just "routes to phone numbers", so it = doesn't help with a call to "sip:user@example.com" at all. And as we = know, given the peering models, RFC 3263 is also inadequate for = "sip@user@example.com". We can't go from here to there using = "example.com"'s SIP SRV record. Instead, we need to find the right = peering partner who can get us there, and we don't have a good way to do = that. >=20 >=20 >=20 > Another model: Inter-ITAD routing: >=20 > If we assume that each SIP Service Provider (SSP) is essentially the = same thing as an ITAD (Internet Telephony Administrative Domain), and = that ITADs peer with each other along well-defined channels (using = Session Border Elements, SBEs, known by other acronyms including Little = Spawns of Satan etc.), then this gives us another routing topology to = consider. >=20 > Assume a routing protocol that tells ITAD A that to reach ITAD Z, the = request should be sent to ITAD Q (or perhaps to a vector of Q and T) who = will act as an intermediary. If ITAD A can directly reach Q, then A = knows how to route the request. A can send the request to A's SBE that = is adjacent to Q, which then hands it to Q's SBE (adjacent to A), which = then consults its own routing tables to figure out how to move the = request on, either to Z, to the previously declared secondary route T, = or to some other ITAD known to Q that will serve as a relay. >=20 > With this model, we don't need to know the route for a given E.164 = number (or @domain part). All we need to know is which ITAD that target = is associated with. We then consult the ITAD routing table to send the = request. This means that the largest dynamic routing table required is = the inter-ITAD map, which is exponentially smaller than the number of = telephone routes. >=20 > So, given a dynamic inter/intra ITAD routing protocol that can tell us = what SBE to use to move towards a given ITAD, all we need to know is a = way to translate a phone number or a domain-part into an ITAD. >=20 > This is the easy part. ENUM gives us an excellent mechanism for = turning phone numbers into either numeric or domain-style ITAD = identifiers. The mapping of phone number (or phone number range) to ITAD = is relatively static, globally valid, and well-suited to the = recursive-lookup and cache model that ENUM inherited from DNS. >=20 > This gives us a new simple model for call routing at the LS for = phone-number targeted calls >=20 > 1) If the number isn't locally known, look up its ITAD in ENUM. This = might be range-matched or fully qualified; it's just a standard ENUM = lookup. > 2) Consult the ITAD routing table to select an SBE (and possibly = additional transit ITADs) to find the routing vector consisting of one = or more SBEs and zero or more transit ITADs. > 3) Canonicalize the request URI and add the SBEs/ITADs as loose route = hops > 4) Send the request. >=20 > For domain-targeted calls, we might also get to add in "Check to see = if the destination is reachable via RFC 3263, and if so, use that" = somewhere in the process. >=20 > The short form of this model is 1) Find the ITAD of the destination. = 2) Find a route to that ITAD (which might be one or more intermediaries. = 3) Send the request there. >=20 >=20 >=20 > Conclusion: >=20 > So, other than a dynamic routing protocol that meets inter/intra-ITAD = routing requirements and could be derived from TRIP (or built using some = other model, such as a SIP event package), what are we missing? >=20 >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From kpfleming@digium.com Fri Apr 30 14:22:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C263A6A42 for ; Fri, 30 Apr 2010 14:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.78 X-Spam-Level: X-Spam-Status: No, score=-103.78 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_50=0.001, MISSING_HEADERS=1.292, 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 Ka5togkBRd7Z for ; Fri, 30 Apr 2010 14:22:33 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 8BE5E3A69EB for ; Fri, 30 Apr 2010 14:22:29 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1O7xf4-0004qp-Aa for dispatch@ietf.org; Fri, 30 Apr 2010 16:22:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 3E483D8024 for ; Fri, 30 Apr 2010 16:22:14 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ManxpFemEusP for ; Fri, 30 Apr 2010 16:22:14 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 0F678D8023 for ; Fri, 30 Apr 2010 16:22:14 -0500 (CDT) Message-ID: <4BDB4A05.3020609@digium.com> Date: Fri, 30 Apr 2010 16:22:13 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 CC: dispatch@ietf.org References: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> <1AF232C1-9025-4C5E-9F52-DC3BD9CDDE68@cisco.com> In-Reply-To: <1AF232C1-9025-4C5E-9F52-DC3BD9CDDE68@cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.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, 30 Apr 2010 21:22:36 -0000 Cullen Jennings wrote: > There probably any number of reasons that TRIP and others were never deployed but I think one of the largest reasons is the questions about authorization of identities. There are any number of protocols where organization A can tell organization B that calls to phone number X should be routed to server Y. Some examples are TRIP, DUNI, flavors of ENUM, VIPR, and so on. The issue is you need a reason that B should trust what A told them. > > Without a good answer that question, it's hard to see how one would use the resulting solution. And as I experienced years ago when using DUNDi, the solution needs to allow for the entire chain of trust that resulted in A sending the call to B to be able to recorded somewhere along with the call records, in case there were quality/routing/etc. problems associated with the call. Most systems are really not prepared to handle truly dynamic call routing, and have no means in place for administrators to be able to troubleshoot problems post-mortem. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org