From partr@cisco.com Mon May 9 09:51:43 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAEFE07A3 for ; Mon, 9 May 2011 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.165 X-Spam-Level: X-Spam-Status: No, score=-9.165 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWtoEfWvIphy for ; Mon, 9 May 2011 09:51:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (unknown [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D354AE0740 for ; Mon, 9 May 2011 09:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=17306; q=dns/txt; s=iport; t=1304959887; x=1306169487; h=mime-version:subject:date:message-id:from:to:cc; bh=ZiMCy0s0U9ZUaHZA3RWEpLE3pBW/qasQDGPkrPNkosA=; b=aYL+52n3urLz/WCWw5uWPKskT/AJOfunSzQGPQ0+7Z4a0aJCgP2pu3QK qfZum8YKz480+TK/KtVg+Z0po+9a1ZnAjoapmflTA62hmHTqktg5XzfTD b8c52UdTw7S6oW1c+TDkH55liVU8rSYdHjxKIYA2NMXjzOmfb2PEmck81 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssDAJoayE2Q/khRgWdsb2JhbACmABQBARYmJak5nX2DH4JtBIY+jViKNA X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208,217";a="29364748" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 May 2011 16:51:26 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49GpP3a017142; Mon, 9 May 2011 16:51:25 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:21:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC0E69.54DDEBDF" Date: Mon, 9 May 2011 22:21:23 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Load balancing Problem statement Thread-Index: AcwOaVRpYPEDtXJlR0CZZrw6Fb6CAg== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 09 May 2011 16:51:24.0724 (UTC) FILETIME=[54FEC740:01CC0E69] Subject: [dispatch] SIP Load balancing Problem statement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:51:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0E69.54DDEBDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 In IETF 80, there was a Side-meeting on SIP load balancing and attendees were Dale Worley, Hadriel Kaplan, Keith Drage, Paul Kyzivat, Victor Pascual, Vijay Gurbani, Volker Hilt, Parthasarathi R. As we concluded in Side Meeting, Vijay and myself had written the initial draft for SIP Load balancing problem statement, shared with all attendees and Dale reviewed it.=20 =20 Could you please review SIP load balancing problem statement and provide your valuable comments which helps to move this work to the next level in IETF. =20 The initial problem statement is as follows: =20 Load balancing across a farm of SIP servers can be done today, but without=20 generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with=20 varying capabilities, example, a SIP proxy, a back-to-back user agent=20 (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media=20 servers etc. The capabilities and processing capacity on hosts in the=20 farm may be different, sometimes vastly, from each other. Furthermore,=20 the duration of time that a SIP host requires to process a SIP request may=20 vary. SIP proxies, operating at the transaction layer, may be more=20 efficient at processing transactions than a B2BUA would be, which may=20 need to maintain a long-lived dialogue state in addition to the=20 transaction state. PSTN gateways may have other limitations such=20 as media resources that may be depleted even though the gateway may=20 have enough processing power (i.e., CPU) to handle incoming requests. =20 In face of such diversity, simple load balancing schemes based on=20 round-robin selection tend to work only when many assumptions are met. First, the relative capacity and processing resources of all SIP servers in the farm should be nearly equal. Furthermore, because a round- robin scheme presents a load of (1/n)*N to each server, where n =3D = number of servers and N =3D arrival rate in requests per second, it assumes = that=20 the service time at each server is such that the utilization of each=20 server is not negatively impacted (i.e., utilization ratio of the =20 arrival rate over the mean service rate is less than 1.0). And finally, the round-robin load balancing does not have a backward feedback mechanism=20 whereby the load-balanced server can inform the load balancer of its=20 current utilization (i.e., round-robin load balancing acts as=20 an open-loop controller). =20 The problem statement for load balancing is, therefore, how to arrive=20 at a load balancing scheme that distributes SIP requests to a collection of servers to effectively utilize the resources at those servers.=20 These resources can include CPU, memory, network bandwidth,=20 input/output, DSP, DS0 or disk resources.=20 =20 In order to achieve such a load balancing scheme in practice, the following=20 considerations must be taken in account: =20 1) Should the load balancing scheme have a closed-loop model, i.e.,=20 should it report utilization to the load balancer to allow the load=20 balancer to distribute requests proportionally? =20 Note: The discussion that occurred before the Prague IETF seem to concur that some sort of an adaptive closed-loop model is effective. Reporting a number that signifies a dynamically calculated "weight" [1], or the number that signifies an estimate of additional sessions that a SIP host can accept [2] seems to be of use. =20 2) What diversity of SIP hosts in a farm should be accommodated? Is it=20 reasonable to assume that the same load balancing scheme should be=20 applicable to a pair of SIP servers, one of which can handle an order=20 of magnitude more requests per unit time that the other? =20 3) What information must be provisioned into the load balancer and=20 the servers? =20 4) As SIP request resource consumption in SIP signaling only=20 server varies drastically from SIP media servers [3], should the=20 solution be split such that load balancing of a pure signaling server=20 is different than that of a SIP server that handles signaling as=20 well as media? =20 The last consideration above is especially important since a solution to load balancing a media farm will require a model where the SIP=20 load balancer is closely coupled with the downstream SIP servers. In such a model, the SIP load balancer knows the resources available at each of the downstream SIP servers and is able to inspect an incoming request to determine its media-related requirements and thus dispatch it to the downstream SIP server that has the highest probability of servicing that request. In some architectures, such a coupling reduces post-dial delay. =20 =20 Keeping the SIP load balancer and the downstream SIP servers=20 loosely coupled suffices for load balancing to a farm of SIP servers that only handle signaling. A loosely coupled model operates purely on the feedback received from the downstream SIP servers and does not require the SIP load balancer to inspect an incoming request. =20 Any solution, or work towards a solution (a working group) needs to=20 clearly specify its scope. A solution also needs to clearly state=20 any limitations, in performance or otherwise, the specified load=20 balancing mechanism may have. In particular, the a solution shall=20 carefully define the deployment considerations for the effective=20 operation of the specified mechanisms and discuss, for example, when=20 a mechanism requires coordinated deployment and operation (if all servers=20 need to deploy the same mechanism, certain configuration values=20 need to be identical on all servers, etc), when a mechanism can become=20 less effective or ineffective under some conditions, or especially if=20 there are cases when a mechanism these considerations is to allow=20 potential deployers to make the best use of these mechanism in=20 their particular networks. =20 [1] http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balancing -00 [2] http://tools.ietf.org/html/draft-jones-sip-overload-sce-00 [3] http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-cont rol-00 =20 Thanks Vijay/Partha ------_=_NextPart_001_01CC0E69.54DDEBDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
In = IETF 80, there=20 was a Side-meeting on SIP load balancing and attendees were = Dale=20 Worley, Hadriel Kaplan, Keith Drage, Paul Kyzivat, Victor = Pascual,=20 Vijay Gurbani,  Volker Hilt, Parthasarathi R. As=20 we concluded in Side Meeting, Vijay and myself had written the = initial=20 draft for SIP Load balancing problem statement, shared with all = attendees and=20 Dale reviewed it.
 
Could you please review SIP = load=20 balancing problem statement and provide your valuable=20 comments which helps to move this work to the next level in=20 IETF.
 
The initial problem statement is as=20 follows:
 
Load=20 balancing across a farm of SIP servers can be done today, but without=20
generally agreed upon principles on how to best do accomplish=20 this.
Confounding the problem is that a SIP farm may consist of hosts = with=20
varying capabilities, example, a SIP proxy, a back-to-back user = agent=20
(B2BUA), a public-switched telephone system (PSTN) gateway, SIP = Media=20
servers etc. The capabilities and processing capacity on hosts in = the=20
farm may be different, sometimes vastly, from each other.  = Furthermore,=20
the duration of time that a SIP host requires to process a SIP = request may=20
vary. SIP proxies, operating at the transaction layer, may be more=20
efficient at processing transactions than a B2BUA would be, which = may=20
need to maintain a long-lived dialogue state in addition to the=20
transaction state.  PSTN gateways may have other limitations = such=20
as media resources that may be depleted even though the gateway may =
have=20 enough processing power (i.e., CPU) to handle incoming=20 requests.
 
In=20 face of such diversity, simple load balancing schemes based on =
round-robin=20 selection tend to work only when many assumptions are met.
First, the = relative capacity and processing resources of all SIP servers
in the = farm=20 should be nearly equal.  Furthermore, because a round-
robin = scheme=20 presents a load of (1/n)*N to each server, where n =3D number
of = servers and N=20 =3D arrival rate in requests per second, it assumes that
the service = time at=20 each server is such that the utilization of each
server is not = negatively=20 impacted (i.e., utilization ratio of the 
arrival rate over the = mean=20 service rate is less than 1.0).  And finally,
the round-robin = load=20 balancing does not have a backward feedback mechanism
whereby the=20 load-balanced server can inform the load balancer of its
current = utilization=20 (i.e., round-robin load balancing acts as
an open-loop=20 controller).
 
The=20 problem statement for load balancing is, therefore, how to arrive
at = a load=20 balancing scheme that distributes SIP requests to a collection
of = servers to=20 effectively utilize the resources at those servers.
These resources = can=20 include CPU, memory, network bandwidth,
input/output, DSP, DS0 or = disk=20 resources.
 
In=20 order to achieve such a load balancing scheme in practice, the following =
considerations must be taken in account:
 
1)=20 Should the load balancing scheme have a closed-loop model, i.e., =
should it=20 report utilization to the load balancer to allow the load
balancer = to=20 distribute requests proportionally?
 
    Note: The discussion that occurred before = the Prague=20 IETF seem to
    concur that some sort of an adaptive=20 closed-loop model is
    effective.  Reporting a = number=20 that signifies a dynamically
    calculated "weight" = [1], or=20 the number that signifies an estimate
    of = additional=20 sessions that a SIP host can accept [2] seems to = be
    of=20 use.
 
2)=20 What diversity of SIP hosts in a farm should be accommodated?  Is = it=20
reasonable to assume that the same load balancing scheme should be=20
applicable to a pair of SIP servers, one of which can handle an = order
of=20 magnitude more requests per unit time that the = other?
 
3)=20 What information must be provisioned into the load balancer and
the=20 servers?
 
4) As=20 SIP request resource consumption in SIP signaling only
server varies = drastically from SIP media servers [3], should the
solution be split = such=20 that load balancing of a pure signaling server
is different than = that of a=20 SIP server that handles signaling as
well as=20 media?
 
The=20 last consideration above is especially important since a solution
to = load=20 balancing a media farm will require a model where the SIP
load = balancer is=20 closely coupled with the downstream SIP servers.
In such a model, the = SIP=20 load balancer knows the resources available
at each of the downstream = SIP=20 servers and is able to inspect an
incoming request to determine its=20 media-related requirements and thus
dispatch it to the downstream SIP = server=20 that has the highest
probability of servicing that request.  In = some=20 architectures, such
a coupling reduces post-dial delay. =20
 
Keeping the SIP load balancer and the downstream SIP servers =
loosely=20 coupled suffices for load balancing to a farm of SIP
servers that = only handle=20 signaling.  A loosely coupled model
operates purely on the = feedback=20 received from the downstream
SIP servers and does not require the SIP = load=20 balancer to inspect
an incoming request.
 
Any=20 solution, or work towards a solution (a working group) needs to =
clearly=20 specify its scope.  A solution also needs to clearly state
any=20 limitations, in performance or otherwise, the specified load =
balancing=20 mechanism may have.  In particular, the a solution shall =
carefully=20 define the deployment considerations for the effective
operation of = the=20 specified mechanisms and discuss, for example, when
a mechanism = requires=20 coordinated deployment and operation (if all servers
need to deploy = the same=20 mechanism, certain configuration values
need to be identical on all = servers,=20 etc), when a mechanism can become
less effective or ineffective = under some=20 conditions, or especially if
there are cases when a mechanism these=20 considerations is to allow
potential deployers to make the best use = of these=20 mechanism in
their particular networks.
 
[1] http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-loa= d-balancing-00
[2]=20 http:= //tools.ietf.org/html/draft-jones-sip-overload-sce-00
[3]=20 http://tools.ietf.org/html/draft-partha-dispatch-sip-media= -overload-control-00
 
Thanks
Vijay/Partha

 ------_=_NextPart_001_01CC0E69.54DDEBDF-- From mary.ietf.barnes@gmail.com Mon May 9 10:37:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D961E06EF for ; Mon, 9 May 2011 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9erqWWmQ47Rd for ; Mon, 9 May 2011 10:37:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3AE06EC for ; Mon, 9 May 2011 10:37:53 -0700 (PDT) Received: by vxg33 with SMTP id 33so315528vxg.31 for ; Mon, 09 May 2011 10:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=o0VhErwgRGpc3AMiPKG4qKKNGgSYpZzkqZJ7PKIbfR4=; b=clT+HxpNA7cMeSrFUzSkgb+BRV4H2ZHeQBdKTQ/93sSlHMQUnPFxHHF5ja6ozxCEr0 4GJsBEwOGqStvmNA040JDVZAf+kUPEWObmYgXY0nNy5Y5U3Gpqy2gRVzV1sFQiAEM2bm yeVgSsoWAZ07AY4jdyuA5e5R6DmwC9o8tk28M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=LpeQPyv+3Yv+ojFnPKuJupP5w+7EuzPNq3k7W12D+YOQKCHQnof7QiGQglBiQJ9AgN iXyq/W8Tz+hyNEvIuhAti7ikz7A2UP0yl8YGy6RbAjeiG4EY9ka/2svTBmZLVKmtEd6q z24KY5jDnPhYJsdCk8s8RNCI6KCs98RERJidQ= MIME-Version: 1.0 Received: by 10.52.176.1 with SMTP id ce1mr3695587vdc.63.1304962208828; Mon, 09 May 2011 10:30:08 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Mon, 9 May 2011 10:30:08 -0700 (PDT) Date: Mon, 9 May 2011 12:30:08 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=bcaec517a812e70f3a04a2db305f Subject: [dispatch] Reminder: IETF-81 deadlines - Initial proposals due on May 16th. X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:37:54 -0000 --bcaec517a812e70f3a04a2db305f Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Just a reminder that the IETF-81 deadlines for DISPATCH are fast approaching. http://trac.tools.ietf.org/wg/dispatch/trac/wiki We need to know by next Monday whether you are intending to pursue a topic during the IETF-81 timeframe. * *May 16, 2011*. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 weeks before -00 deadline] * *May 23, 2011*. Cutoff for charter proposals for topics. [One week prior to BoF proposal deadline*, two weeks before announcement of topics] * *June 6, 2011*. Topics that are to be the focus of IETF-81 are announced. [Typically one week before AD BoF approval and deadline to request WG slot, 4 weeks before -00 deadline] * *July 4, 2011*. -00 draft deadline. * *July 11, 2011*. Draft deadline. Regards, Mary DISPATCH WG co-chair --bcaec517a812e70f3a04a2db305f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Just a reminder that the IETF-81 deadlines for= DISPATCH are fast approaching. =A0=A0

= We need to know by next Monday whether you are intending to pursue a topic = during the IETF-81 timeframe.
=A0

*=A0May 16, 2011.=A0Cutoff date to notify= the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to = BoF proposal deadline, 7 weeks before -00 deadline]

*=A0May 2= 3, 2011.=A0Cutoff for charter proposals for topics. [One week prio= r to BoF proposal deadline*, two weeks before announcement of topics]

*=A0June 6, 2011.=A0Topics that are to be the focus of = IETF-81 are announced. [Typically one week before AD BoF approval and deadl= ine to request WG slot, 4 weeks before -00 deadline]

*=A0July= 4, 2011.=A0-00 draft deadline.

*=A0July 11, 2011.=A0Draft deadline.

Regards,
Mary
DISPATCH WG co-chair
--bcaec517a812e70f3a04a2db305f-- From R.Jesske@telekom.de Fri May 13 00:18:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31F2E06D5 for ; Fri, 13 May 2011 00:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoc37qvP9psx for ; Fri, 13 May 2011 00:18:21 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC44E0657 for ; Fri, 13 May 2011 00:18:19 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 13 May 2011 09:18:11 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by he110890 ([10.134.92.131]) with mapi; Fri, 13 May 2011 09:18:11 +0200 From: To: , , Date: Fri, 13 May 2011 09:18:09 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcvziW99TxTdvSF2RWSq4ugDLe6iZgAsg++ABz8+3+A= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 07:18:22 -0000 Hi, Since my answer it looks that people would be OK with the change. So if no body comments within the next few days I would prepare a new draft= . So due to Gonzalo's proposal I would rewrite the paragraphs as shown below. For comparison reasons I have added also the text proposal of the current d= raft (draft-jesske-dispatch-update3326-reason-responses-02). Please indicate which text you would like to see finally. New proposal or c= urrent proposal. 3. RFC3326 1. Introduction Original Text: Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. Note that the Reason header field is usually not needed in responses because the status code and the reason phrase already provide sufficient information. New Text(new proposal): Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request independent of the protocol value used and in any response except 100 trying. New Text (text stated in the current draft draft-jesske-dispatch-update3= 326-reason-responses-02): Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request independent of the protocol value used and in any response except 100 trying if it contains only a Q.850 Cause Code. 4. RFC3326 2. The Reason Header Field Original Text The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. Jesske & Liess Expires October 2, 2011 [Page 3] Internet-Draft Reason Header March 2011 New Text(new proposal): The Reason header field MAY appear in any request within a dialog, in any CANCEL request . The appearance of the Reason header field is applicable to final responses 3= xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses [I-D.ietf-sipcore-199]. New Text(text stated in the current draft draft-jesske-dispatch-update33= 26-reason-responses-02): The Reason header field only containing a Q.850 Cause Code MAY appear in any request within a dialog, in any CANCEL request . The appearance of the Reason header field only containing a Q.850 Cause Code is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses [I-D.ietf-sipcore-199]. The Reason header field containing any other reason value MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. Best Regards Roland Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland 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: mailto:r.jesske@telekom.de http://www.telekom.de Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, 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. > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Jesske, Roland > Gesendet: Mittwoch, 6. April 2011 11:24 > An: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org > Betreff: Re: [dispatch] SIP responses carrying Q.850 cause > values in Reason header fields > > Hi Gonzalo, > I'm OK with your proposal so I could change it if people > would like it. > It makes it shorter. > The only I would propose to have in is the explicit > mentioning of the Response values due to the fact that a > 100OK or 200OK should not include a Reason header with a > Q.850 Cause Value. > > Best Regards > Roland Jesske > > > > > -----Urspr=FCngliche Nachricht----- > > Von: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > > Gesendet: Dienstag, 5. April 2011 14:03 > > An: DISPATCH > > Betreff: [dispatch] SIP responses carrying Q.850 cause values > > in Reason header fields > > > > Hi, > > > > last week in the DISPATCH session, there was consensus to allow SIP > > responses to carry Reason header fields with Q.850 cause > values. As I > > said some time ago, I am willing to AD sponsor this draft > if/when the > > DISPATCH chairs confirm such consensus on the list. > > > > In the mean time, I have some comments on how to document > > this decision. > > The following (fairly short) draft updates a couple of > > paragraphs in RFC > > 3326 in order to achieve the desired outcome: > > > > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason-response= s-02.txt > > > > > > I think this is not a particularly elegant way to define > what we want. > > For example, if we wanted to define a solution to HERFP in > the future > > based on the Reason header, we would need to update those paragraphs > > again, making them longer every time we added a new use case. > > > > Instead, I would prefer to explicitly define what we want > to do and be > > done with it. Such a (also fairly short) draft would say > > something along > > the following lines: > > > > "RFC 3326 allows the presence of the Reason header field in > > any response > > whose status code explicitly allows its presence. This document > > explicitly allows any SIP response to carry a Reason header > > field with a > > Q.850 cause value. SIP responses with Reason header fields carrying > > values other than Q.850 cause values are outside of the > scope of this > > document." > > > > I would like to know the opinion of the WG on this matter > > (i.e., how to > > document the WG's consensus). Note that reaching consensus was the > > difficult part. Agreeing on how to document it should be easy. > > > > Thanks, > > > > Gonzalo > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From salvatore.loreto@ericsson.com Fri May 13 07:35:55 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B9E0776 for ; Fri, 13 May 2011 07:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3auyHR9pbz0u for ; Fri, 13 May 2011 07:35:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 59791E076B for ; Fri, 13 May 2011 07:35:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.1E.02960.6B14DCD4; Fri, 13 May 2011 16:35:34 +0200 (CEST) X-AuditID: c1b4fb3d-b7c86ae000000b90-80-4dcd41b6d278 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.115.93]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E7.FE.21561.C353DCD4; Fri, 13 May 2011 15:42:20 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 13 May 2011 15:41:30 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ECB2124F7; Fri, 13 May 2011 16:41:30 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B01A050E9F; Fri, 13 May 2011 16:41:30 +0300 (EEST) Received: from n244.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4B79A50E9E; Fri, 13 May 2011 16:41:30 +0300 (EEST) Message-ID: <4DCD350A.8090106@ericsson.com> Date: Fri, 13 May 2011 16:41:30 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "dispatch@ietf.org" , Cullen Jennings , Mary Barnes References: <201105111916.p4BJGSq4019453@mtv-core-4.cisco.com> <013501cc1042$89607df0$9c2179d0$@packetizer.com> <009601cc1109$81f819c0$85e84d40$@packetizer.com> In-Reply-To: <009601cc1109$81f819c0$85e84d40$@packetizer.com> Content-Type: multipart/alternative; boundary="------------070102020009090402030706" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] End-to-End Session ID X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:35:56 -0000 --------------070102020009090402030706 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi there, we would like to propose a "new" dispatch topic on End to End session identifier in IP-based multimedia network. This is a functionality that seems to be necessary for different use cases, so we think it is necessary to have a general discussion on the problem statement, scope, etc. We are working on * a charter proposal for the topic and we hope to be able to submit at some point next week, well before the deadline on May 23rd. * an ID that cover the problem, the scope and requirements. cheers /Sal -- Salvatore Loreto www.sloreto.com --------------070102020009090402030706 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit Hi there,

we would like to propose a "new" dispatch topic on
End to End session identifier in IP-based multimedia network.

This is a functionality that seems to be necessary for different use cases,
so we think it is necessary to have a general discussion on the problem statement, scope, etc.

We are working on
  • a charter proposal for the topic and we hope to be able to submit at some point next week,
    well before the deadline on May 23rd.
  • an ID that cover the problem, the scope and requirements.

cheers
/Sal
-- 
Salvatore Loreto
www.sloreto.com
--------------070102020009090402030706-- From vkg@bell-labs.com Fri May 13 09:59:28 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C173E07E4 for ; Fri, 13 May 2011 09:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDavylByVPmA for ; Fri, 13 May 2011 09:59:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 36356E073B for ; Fri, 13 May 2011 09:59:27 -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 p4DGxMLJ000699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 May 2011 11:59:22 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4DGxMZM024374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2011 11:59:22 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4DGxMnP017025; Fri, 13 May 2011 11:59:22 -0500 (CDT) Message-ID: <4DCD6358.3020000@bell-labs.com> Date: Fri, 13 May 2011 11:59:04 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: "dispatch@ietf.org" , Mary Barnes , Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [dispatch] Proposal on SIP load balancing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:59:28 -0000 Mary, Cullen, and WG members: In the event that an earlier email on the SIP load balancing problem statement [1] was not sufficiently clear, we'd like this email to serve as a notification of submitting a new proposal on SIP load balancing to the dispatch WG. There was a good discussion before and during the Prague IETF. We will have a charter proposal before May 23rd deadline, but to really fine tune the charter, if folks do get the time, please take a look at [1] to make sure that the discussion during Prague was captured adequately. [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03615.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From salvatore.loreto@ericsson.com Mon May 16 06:54:52 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA4CE06B0 for ; Mon, 16 May 2011 06:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPvAIL1FEE7Z for ; Mon, 16 May 2011 06:54:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CB83EE067E for ; Mon, 16 May 2011 06:54:50 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae0000076dc-0e-4dd12ca98555 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.1B.30428.9AC21DD4; Mon, 16 May 2011 15:54:49 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 16 May 2011 15:54:48 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E734B246A; Mon, 16 May 2011 16:54:47 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A7AEE50ED3; Mon, 16 May 2011 16:54:47 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 57FD250ED2; Mon, 16 May 2011 16:54:47 +0300 (EEST) Message-ID: <4DD12CA7.3080409@ericsson.com> Date: Mon, 16 May 2011 16:54:47 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mary Barnes , Cullen Jennings , "dispatch@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] update Referred-by header : item proposal and charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 13:54:52 -0000 Mary, Cullen and WG members, this is a notification to propose as a new possible item for dispatch: the update of Referred-by header below there is also a first tentative of charter proposal for a wg to work on updating the Referred-by header. http://tools.ietf.org/html/draft-loreto-dispatch-3892bis-02 Thoughts and comments on the charter proposal are appreciate. ciao /Sal Charter Proposal (version 1) Possible WG Names: Open for ideas SIP uses the Referred-By (RFC3892) header field for conveying the identity of a REFER request. This header field may be used when exploding a SIP MESSAGE or a SIP INVITE request to an ad-hoc or pre-defined group URI. The Referred-By header is only included if the P-Asserted-Identify header field (RFC3325) or From header field needs to carry another value (e.g. the pre-defined group URI, or a conference focus URI). In those cases, the Referred-By header field in the resulting is set to the P-Asserted-Identity header field or to the From header field of the original SIP request received before exploding so as to convey to the receiver the identity of the original inviting sender. However Referred-by header as defined in RFC3892 restricts the value of the header to only one SIP URI. RFC5876 instead allows the P-Asserted-Identity to contain two or more URIs, that can be SIP/SIPS URI or TEL URI. This Working group will work on updating RFC3892 by allowing a Referred-by header to contain two or more URIs as defined for P-Asserted-Identity header field in (RFC5876). Deliverables March 2012 Updates to Referred-by to IESG. -- Salvatore Loreto www.sloreto.com From fluffy@cisco.com Wed May 18 11:10:42 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2295AE0724 for ; Wed, 18 May 2011 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXHMYywEFHFs for ; Wed, 18 May 2011 11:10:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 004ACE06B1 for ; Wed, 18 May 2011 11:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5772; q=dns/txt; s=iport; t=1305742240; x=1306951840; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ncCaa/43PDbfDMwsTmoJagtxvnUqJNqMBZQW18Otv8c=; b=ey5yIkLxPKdIaaQREmpJ7yg5A248jKi6Wtu3xD/JqPC0FyUDBxSLdDEM 84mCR1cCEbVBHdwr63Df8Xg80oy9SPEKCVbjJNghEDm8PY3QTVThZQ2qt y+Ro2FSFbhUYa+f1gz6CWZLG8kB5yt5mX/8pUlZm+PXFUcDvVp2WRPIf0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEwL1E2rRDoI/2dsb2JhbACmHHenRIEdnX2GGQSGUIlBhC+KZQ X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="359735889" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 18 May 2011 18:10:40 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4IIAdXs001691 for ; Wed, 18 May 2011 18:10:40 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 12:10:39 -0600 Message-Id: To: DISPATCH list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dispatch] draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 18:10:42 -0000 I have said in the past, I have several concerns around the combined = proposal in these two drafts. In this email, I've tried to focus on the = high level problems and ignore small problems in the drafts that can be = fixed by change a bit of text in the drat.=20 The biggest issues is that this is going to reduce interoperability with = systems that don't use this type of instance id yet this does not = provide features that could not be done in away that did not reduce = interoperability. To be concrete, let me offer an alternative solution = that would be interoperable, would not have any IPR that I am aware of, = and would provide the same functionality as the goals of these drafts - = or at least the goals that have been stated at the IETF.=20 To indicate the version of the software, I would suggest using the SIP = User Agent header. If a more structured form is required to specifically = line up with existing mobile systems, I would suggest defining an well = structured format to use inside the User Agent header field. The = advantage is that this is what most sip systems do today and many = management systems already can look at this header and use it. A more = structured form would be useful by systems outside the GSMA space and = would also be backwards compatible with existing systems that treat it = as an unstructured string.=20 For the issue of identifying stolen handsets and correlating devices = between SIP and non SIP calls, I would propose that you use a UUID as = the URN but that the UUID be created using IMEI or a hash of the IMEI = instead of the MAC. This would involve an extension to RFC 4122 but = would result in a system that meets the needs. Even if a hash is used, = the server side can do the same hash to match.=20 If the WG is interest in such an idea, I am glad to write up an ID for = each of these and submit it to the group so that it can be properly = considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid.=20= As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am = not in favor of publishing it as is because I believe it will result in = interoperability failures with the many SIP devices that don't support = it, and it has IPR that we can easily avoid and provide the same = functionality. I also have issues with some of the technical details in = it but theses could all be fairly easily resolved with a few back and = forth of suggested text. RIM is offering awful licensing terms for = something that I believe you would have to implement to be workable in = the bulk mobile SIP deployments. Give this is easily avoidable, I think = we should avoid it. It's not really a topic for this WG but if this = draft proceeded, it was very late IPR disclosure. When it came to IETF = LC, I would also want to point out that the only teeth IETF has to = enforce very late IPR disclosures is to say no. I'm not particularly = interested in talking about this here as I don't think it will help = solve the problem but I have brought this up in the past in context of = this draft and I don't want anyone to be surprised if I brought it up in = an IETF LC.=20 There are also significant privacy concerns around this proposal. A key = design of GRUU is being able to meet people goals of privacy while not = revealing private information. The IMEI is sometimes used as a security = identifier between a user and SP as a shared secret. This proposal would = break theses systems. The privacy and security aspects of this would = need to be addressed. It's conceivable that in many cases IMEI is = Personal Identifiable Information. The idea that every call would have = to have PII information in it or my call would be blocked as coming form = a stolen phone seems like a pretty serious flaw in this proposal. I'll = note I brought up the privacy issues in 2007 and have yet to get a reply = on it.=20 On the topic of draft-montemurro-gsma-imei-urn, I of course think it is = fine for the GSMA to be able to allocate a namespace where they need it. = However, there are bunch of changes that would be needed to make this = draft fit all the URN rules. They are all small actionable things like = defining how comparison of things such as svn is defined and how = allocation of new things works. As I have also brought up many times in = the past, what the relationship between GSMA and 3GPP on this is very = weird and I would want clarity on that before proceeding. In the time we = have been discussing this draft, people constantly tell me that GSMA is = the group that will handle the namespace allocation for the 3GPP = deployments yet at the same time we have approved RFC 5279 which oddly = looks like a better namespace for this than the GSMA one. I would want = to have a clear understanding of how these different spaces interact. = The more we splinter this namespace, the less interoperability we have.=20= On the topic of including the software version as part of the device = identifier, given the software is upgraded, I think this is a mistake = and it is better to consider the software version as a separate thing = from the unique device identifier. It does not seem consistent with the = goals and requirements of a device id URN.=20 I will also note that as far as process is concerned, I would prefer the = problem, not the solution was brought to dispatch and we could figure = out how to solve it. I do think the problem here is well worth solving, = I just think there are solutions that will work better that this when = considering the whole eco systems of SIP endpoints and not just the GSM = ones.=20 Cullen in my individual contributor role From R.Jesske@telekom.de Thu May 19 00:58:57 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B169E068C for ; Thu, 19 May 2011 00:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRXYMgnM+6Fg for ; Thu, 19 May 2011 00:58:56 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACC9E0681 for ; Thu, 19 May 2011 00:58:55 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 19 May 2011 09:58:40 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 May 2011 09:58:20 +0200 From: To: , Date: Thu, 19 May 2011 09:58:19 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 07:58:57 -0000 Dear all, So assuming that there was no comment people are happy with the new rewordi= ng I would like to prepare a new draft. This would be Option 1: General wording to allow the Reason header within r= esponses without any restrictions (except 100 Trying). And nobody wanted to have Option 2: Wording as stated in the current draft draft-jesske-dispatch-update3326-reason-responses-02 Agreed? Comments? Thank you and best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jesske, Roland > Gesendet: Donnerstag, 19. Mai 2011 09:50 > An: Jesske, Roland > Betreff: AW: [dispatch] SIP responses carrying Q.850 cause > values in Reason header fields > > > > On May 13, 2011, at 3:18 AM, wrote: > > > Hi, > Since my answer it looks that people would be > OK with the change. > So if no body comments within the next few days > I would prepare a new draft. > > So due to Gonzalo's proposal I would rewrite > the paragraphs as shown below. > For comparison reasons I have added also the > text proposal of the current draft > (draft-jesske-dispatch-update3326-reason-responses-02). > Please indicate which text you would like to > see finally. New proposal or current proposal. > > > 3. RFC3326 1. Introduction > > Original Text: > > Initially, the Reason header field defined > here appears to be most > useful for BYE and CANCEL requests, but it > can appear in any request > within a dialog, in any CANCEL request and in > any response whose > status code explicitly allows the presence of > this header field. > > Note that the Reason header field is usually > not needed in responses > because the status code and the reason phrase > already provide > sufficient information. > > New Text(new proposal): > > Initially, the Reason header field defined > here appears to be most > useful for BYE and CANCEL requests, but it > can appear in any request > within a dialog, in any CANCEL request > independent of the protocol > value used and in any response except 100 trying. > > New Text (text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > Initially, the Reason header field defined > here appears to be most > useful for BYE and CANCEL requests, but it > can appear in any request > within a dialog, in any CANCEL request > independent of the protocol > value used and in any response except 100 > trying if it contains only > a Q.850 Cause Code. > > 4. RFC3326 2. The Reason Header Field > > Original Text > > The Reason header field MAY appear in any > request within a dialog, in > any CANCEL request and in any response whose > status code explicitly > allows the presence of this header field. > > > > > Jesske & Liess Expires October 2, > 2011 [Page 3] > > Internet-Draft Reason Header > March 2011 > > > New Text(new proposal): > > The Reason header field MAY appear > in any request within a dialog, in any CANCEL > request . The > appearance of the Reason header field is > applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > > New Text(text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > The Reason header field only containing a > Q.850 Cause Code MAY appear > in any request within a dialog, in any CANCEL > request . The > appearance of the Reason header field only > containing a Q.850 Cause > Code is applicable to final responses 3xx, > 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > The Reason header field containing any other > reason value MAY appear > in any request within a dialog, in any CANCEL > request and in any > response whose status code explicitly allows > the presence of this > header field. > > > > > Best Regards > > > Roland > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > 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: mailto:r.jesske@telekom.de > http://www.telekom.de > > 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. > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Jesske, Roland > > > Gesendet: Mittwoch, 6. April 2011 11:24 > > > An: Gonzalo.Camarillo@ericsson.com; > dispatch@ietf.org > > > Betreff: Re: [dispatch] SIP responses > carrying Q.850 cause > > > values in Reason header fields > > > > Hi Gonzalo, > > > I'm OK with your proposal so I could > change it if people > > > would like it. > > > It makes it shorter. > > > The only I would propose to have in is > the explicit > > > mentioning of the Response values due > to the fact that a > > > 100OK or 200OK should not include a > Reason header with a > > > Q.850 Cause Value. > > > > Best Regards > > > Roland Jesske > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > > > Gesendet: Dienstag, 5. April 2011 14:03 > > > An: DISPATCH > > > Betreff: [dispatch] SIP > responses carrying Q.850 cause values > > > in Reason header fields > > > > Hi, > > > > last week in the DISPATCH > session, there was consensus to allow SIP > > > responses to carry Reason > header fields with Q.850 cause > > > values. As I > > > said some time ago, I am > willing to AD sponsor this draft > > > if/when the > > > DISPATCH chairs confirm such > consensus on the list. > > > > In the mean time, I have some > comments on how to document > > > this decision. > > > The following (fairly short) > draft updates a couple of > > > paragraphs in RFC > > > 3326 in order to achieve the > desired outcome: > > > > > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > -responses-02.txt > > > > > I think this is not a > particularly elegant way to define > > > what we want. > > > For example, if we wanted to > define a solution to HERFP in > > > the future > > > based on the Reason header, we > would need to update those paragraphs > > > again, making them longer every > time we added a new use case. > > > > Instead, I would prefer to > explicitly define what we want > > > to do and be > > > done with it. Such a (also > fairly short) draft would say > > > something along > > > the following lines: > > > > "RFC 3326 allows the presence > of the Reason header field in > > > any response > > > whose status code explicitly > allows its presence. This document > > > explicitly allows any SIP > response to carry a Reason header > > > field with a > > > Q.850 cause value. SIP > responses with Reason header fields carrying > > > values other than Q.850 cause > values are outside of the > > > scope of this > > > document." > > > > I would like to know the > opinion of the WG on this matter > > > (i.e., how to > > > document the WG's consensus). > Note that reaching consensus was the > > > difficult part. Agreeing on how > to document it should be easy. > > > > Thanks, > > > > Gonzalo > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > From md3135@att.com Thu May 19 01:07:53 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E77E068C for ; Thu, 19 May 2011 01:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q66BWi575oYV for ; Thu, 19 May 2011 01:07:52 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id C9219E067C for ; Thu, 19 May 2011 01:07:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1305792470!19866992!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 887 invoked from network); 19 May 2011 08:07:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2011 08:07:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4J86kjq010215 for ; Thu, 19 May 2011 04:06:46 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4J86hmU010199 for ; Thu, 19 May 2011 04:06:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 19 May 2011 04:07:46 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA093DBE45@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reasonheader fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhAAAJ6bpA== From: "DOLLY, MARTIN C (ATTSI)" To: , , Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 08:07:53 -0000 QWdyZWVkDQpNYXJ0aW4gQy4gRG9sbHkNClNlbnQgdG8geW91IGJ5IEFUJlQuLi4gQW1lcmljYSdz IEZhc3Rlc3QgTW9iaWxlIEJyb2FkYmFuZCBOZXR3b3JrLiBSZXRoaW5rIFBvc3NpYmxlLg0KKzEu NjA5LjkwMy4zMzYwDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmcgPGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogZGlz cGF0Y2hAaWV0Zi5vcmcgPGRpc3BhdGNoQGlldGYub3JnPjsgR29uemFsby5DYW1hcmlsbG9AZXJp Y3Nzb24uY29tIDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+DQpTZW50OiBUaHUgTWF5 IDE5IDAzOjU4OjE5IDIwMTENClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFNJUCByZXNwb25zZXMg Y2FycnlpbmcgUS44NTAgY2F1c2UgdmFsdWVzaW4JUmVhc29uCWhlYWRlciBmaWVsZHMNCg0KRGVh ciBhbGwsDQpTbyBhc3N1bWluZyB0aGF0IHRoZXJlIHdhcyBubyBjb21tZW50IHBlb3BsZSBhcmUg aGFwcHkgd2l0aCB0aGUgbmV3IHJld29yZGluZyBJIHdvdWxkIGxpa2UgdG8gcHJlcGFyZSBhIG5l dyBkcmFmdC4NCg0KVGhpcyB3b3VsZCBiZSBPcHRpb24gMTogR2VuZXJhbCB3b3JkaW5nIHRvIGFs bG93IHRoZSBSZWFzb24gaGVhZGVyIHdpdGhpbiByZXNwb25zZXMgd2l0aG91dCBhbnkgcmVzdHJp Y3Rpb25zIChleGNlcHQgMTAwIFRyeWluZykuDQpBbmQgbm9ib2R5IHdhbnRlZCB0byBoYXZlIE9w dGlvbiAyOiBXb3JkaW5nIGFzIHN0YXRlZCBpbiB0aGUgY3VycmVudCBkcmFmdA0KZHJhZnQtamVz c2tlLWRpc3BhdGNoLXVwZGF0ZTMzMjYtcmVhc29uLXJlc3BvbnNlcy0wMg0KDQpBZ3JlZWQ/IENv bW1lbnRzPw0KDQpUaGFuayB5b3UgYW5kIGJlc3QgUmVnYXJkcw0KDQpSb2xhbmQNCg0KPiAtLS0t LVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogSmVzc2tlLCBSb2xhbmQNCj4g R2VzZW5kZXQ6IERvbm5lcnN0YWcsIDE5LiBNYWkgMjAxMSAwOTo1MA0KPiBBbjogSmVzc2tlLCBS b2xhbmQNCj4gQmV0cmVmZjogQVc6IFtkaXNwYXRjaF0gU0lQIHJlc3BvbnNlcyBjYXJyeWluZyBR Ljg1MCBjYXVzZQ0KPiB2YWx1ZXMgaW4gUmVhc29uIGhlYWRlciBmaWVsZHMNCj4NCj4NCj4NCj4g ICAgICAgT24gTWF5IDEzLCAyMDExLCBhdCAzOjE4IEFNLCA8Ui5KZXNza2VAdGVsZWtvbS5kZT4g d3JvdGU6DQo+DQo+DQo+IEhpLA0KPiBTaW5jZSBteSBhbnN3ZXIgaXQgbG9va3MgdGhhdCBwZW9w bGUgd291bGQgYmUNCj4gT0sgd2l0aCAgdGhlIGNoYW5nZS4NCj4gU28gaWYgbm8gYm9keSBjb21t ZW50cyB3aXRoaW4gdGhlIG5leHQgZmV3IGRheXMNCj4gSSB3b3VsZCBwcmVwYXJlIGEgbmV3IGRy YWZ0Lg0KPg0KPiBTbyBkdWUgdG8gR29uemFsbydzIHByb3Bvc2FsIEkgd291bGQgcmV3cml0ZQ0K PiB0aGUgcGFyYWdyYXBocyBhcyBzaG93biBiZWxvdy4NCj4gRm9yIGNvbXBhcmlzb24gcmVhc29u cyBJIGhhdmUgYWRkZWQgYWxzbyB0aGUNCj4gdGV4dCBwcm9wb3NhbCBvZiB0aGUgY3VycmVudCBk cmFmdA0KPiAoZHJhZnQtamVzc2tlLWRpc3BhdGNoLXVwZGF0ZTMzMjYtcmVhc29uLXJlc3BvbnNl cy0wMikuDQo+IFBsZWFzZSBpbmRpY2F0ZSB3aGljaCB0ZXh0IHlvdSB3b3VsZCBsaWtlIHRvDQo+ IHNlZSBmaW5hbGx5LiBOZXcgcHJvcG9zYWwgb3IgY3VycmVudCBwcm9wb3NhbC4NCj4NCj4NCj4g My4gIFJGQzMzMjYgMS4gSW50cm9kdWN0aW9uDQo+DQo+ICAgT3JpZ2luYWwgVGV4dDoNCj4NCj4g ICBJbml0aWFsbHksIHRoZSBSZWFzb24gaGVhZGVyIGZpZWxkIGRlZmluZWQNCj4gaGVyZSBhcHBl YXJzIHRvIGJlIG1vc3QNCj4gICB1c2VmdWwgZm9yIEJZRSBhbmQgQ0FOQ0VMIHJlcXVlc3RzLCBi dXQgaXQNCj4gY2FuIGFwcGVhciBpbiBhbnkgcmVxdWVzdA0KPiAgIHdpdGhpbiBhIGRpYWxvZywg aW4gYW55IENBTkNFTCByZXF1ZXN0IGFuZCBpbg0KPiBhbnkgcmVzcG9uc2Ugd2hvc2UNCj4gICBz dGF0dXMgY29kZSBleHBsaWNpdGx5IGFsbG93cyB0aGUgcHJlc2VuY2Ugb2YNCj4gdGhpcyBoZWFk ZXIgZmllbGQuDQo+DQo+ICAgTm90ZSB0aGF0IHRoZSBSZWFzb24gaGVhZGVyIGZpZWxkIGlzIHVz dWFsbHkNCj4gbm90IG5lZWRlZCBpbiByZXNwb25zZXMNCj4gICBiZWNhdXNlIHRoZSBzdGF0dXMg Y29kZSBhbmQgdGhlIHJlYXNvbiBwaHJhc2UNCj4gYWxyZWFkeSBwcm92aWRlDQo+ICAgc3VmZmlj aWVudCBpbmZvcm1hdGlvbi4NCj4NCj4gICBOZXcgVGV4dChuZXcgcHJvcG9zYWwpOg0KPg0KPiAg IEluaXRpYWxseSwgdGhlIFJlYXNvbiBoZWFkZXIgZmllbGQgZGVmaW5lZA0KPiBoZXJlIGFwcGVh cnMgdG8gYmUgbW9zdA0KPiAgIHVzZWZ1bCBmb3IgQllFIGFuZCBDQU5DRUwgcmVxdWVzdHMsIGJ1 dCBpdA0KPiBjYW4gYXBwZWFyIGluIGFueSByZXF1ZXN0DQo+ICAgd2l0aGluIGEgZGlhbG9nLCBp biBhbnkgQ0FOQ0VMIHJlcXVlc3QNCj4gaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sDQo+ICAg dmFsdWUgdXNlZCBhbmQgaW4gYW55IHJlc3BvbnNlIGV4Y2VwdCAxMDAgdHJ5aW5nLg0KPg0KPiAg IE5ldyBUZXh0ICh0ZXh0IHN0YXRlZCBpbiB0aGUgY3VycmVudCBkcmFmdA0KPiBkcmFmdC1qZXNz a2UtZGlzcGF0Y2gtdXBkYXRlMzMyNi1yZWFzb24tcmVzcG9uc2VzLTAyKToNCj4NCj4gICBJbml0 aWFsbHksIHRoZSBSZWFzb24gaGVhZGVyIGZpZWxkIGRlZmluZWQNCj4gaGVyZSBhcHBlYXJzIHRv IGJlIG1vc3QNCj4gICB1c2VmdWwgZm9yIEJZRSBhbmQgQ0FOQ0VMIHJlcXVlc3RzLCBidXQgaXQN Cj4gY2FuIGFwcGVhciBpbiBhbnkgcmVxdWVzdA0KPiAgd2l0aGluIGEgZGlhbG9nLCBpbiBhbnkg Q0FOQ0VMIHJlcXVlc3QNCj4gaW5kZXBlbmRlbnQgb2YgdGhlIHByb3RvY29sDQo+ICAgdmFsdWUg dXNlZCBhbmQgaW4gYW55IHJlc3BvbnNlIGV4Y2VwdCAxMDANCj4gdHJ5aW5nIGlmIGl0IGNvbnRh aW5zIG9ubHkNCj4gICBhIFEuODUwIENhdXNlIENvZGUuDQo+DQo+IDQuICBSRkMzMzI2IDIuIFRo ZSBSZWFzb24gSGVhZGVyIEZpZWxkDQo+DQo+ICAgT3JpZ2luYWwgVGV4dA0KPg0KPiAgIFRoZSBS ZWFzb24gaGVhZGVyIGZpZWxkIE1BWSBhcHBlYXIgaW4gYW55DQo+IHJlcXVlc3Qgd2l0aGluIGEg ZGlhbG9nLCBpbg0KPiAgIGFueSBDQU5DRUwgcmVxdWVzdCBhbmQgaW4gYW55IHJlc3BvbnNlIHdo b3NlDQo+IHN0YXR1cyBjb2RlIGV4cGxpY2l0bHkNCj4gICBhbGxvd3MgdGhlIHByZXNlbmNlIG9m IHRoaXMgaGVhZGVyIGZpZWxkLg0KPg0KPg0KPg0KPg0KPiBKZXNza2UgJiBMaWVzcyAgICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDIsDQo+IDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgM10NCj4N Cj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgUmVhc29uIEhlYWRlcg0KPiAgICAgICAg ICBNYXJjaCAyMDExDQo+DQo+DQo+ICAgTmV3IFRleHQobmV3IHByb3Bvc2FsKToNCj4NCj4gICBU aGUgUmVhc29uIGhlYWRlciBmaWVsZCAgTUFZIGFwcGVhcg0KPiAgIGluIGFueSByZXF1ZXN0IHdp dGhpbiBhIGRpYWxvZywgaW4gYW55IENBTkNFTA0KPiByZXF1ZXN0IC4gIFRoZQ0KPiAgIGFwcGVh cmFuY2Ugb2YgdGhlIFJlYXNvbiBoZWFkZXIgZmllbGQgaXMNCj4gYXBwbGljYWJsZSB0byBmaW5h bCByZXNwb25zZXMgM3h4LCA0eHgsIDV4eCBhbmQgNnh4IGFuZCAxOHgNCj4gICBhbmQgMTk5IHBy b3Zpc2lvbmFsIHJlc3BvbnNlcyBbSS1ELmlldGYtc2lwY29yZS0xOTldLg0KPg0KPg0KPiAgIE5l dyBUZXh0KHRleHQgc3RhdGVkIGluIHRoZSBjdXJyZW50IGRyYWZ0DQo+IGRyYWZ0LWplc3NrZS1k aXNwYXRjaC11cGRhdGUzMzI2LXJlYXNvbi1yZXNwb25zZXMtMDIpOg0KPg0KPiAgIFRoZSBSZWFz b24gaGVhZGVyIGZpZWxkIG9ubHkgY29udGFpbmluZyBhDQo+IFEuODUwIENhdXNlIENvZGUgTUFZ IGFwcGVhcg0KPiAgIGluIGFueSByZXF1ZXN0IHdpdGhpbiBhIGRpYWxvZywgaW4gYW55IENBTkNF TA0KPiByZXF1ZXN0IC4gIFRoZQ0KPiAgIGFwcGVhcmFuY2Ugb2YgdGhlIFJlYXNvbiBoZWFkZXIg ZmllbGQgb25seQ0KPiBjb250YWluaW5nIGEgUS44NTAgQ2F1c2UNCj4gICBDb2RlIGlzIGFwcGxp Y2FibGUgdG8gZmluYWwgcmVzcG9uc2VzIDN4eCwNCj4gNHh4LCA1eHggYW5kIDZ4eCBhbmQgMTh4 DQo+ICAgYW5kIDE5OSBwcm92aXNpb25hbCByZXNwb25zZXMgW0ktRC5pZXRmLXNpcGNvcmUtMTk5 XS4NCj4NCj4gICBUaGUgUmVhc29uIGhlYWRlciBmaWVsZCBjb250YWluaW5nIGFueSBvdGhlcg0K PiByZWFzb24gdmFsdWUgTUFZIGFwcGVhcg0KPiAgIGluIGFueSByZXF1ZXN0IHdpdGhpbiBhIGRp YWxvZywgaW4gYW55IENBTkNFTA0KPiByZXF1ZXN0IGFuZCBpbiBhbnkNCj4gICByZXNwb25zZSB3 aG9zZSBzdGF0dXMgY29kZSBleHBsaWNpdGx5IGFsbG93cw0KPiB0aGUgcHJlc2VuY2Ugb2YgdGhp cw0KPiAgIGhlYWRlciBmaWVsZC4NCj4NCj4NCj4NCj4NCj4gQmVzdCBSZWdhcmRzDQo+DQo+DQo+ IFJvbGFuZA0KPg0KPg0KPiBEZXV0c2NoZSBUZWxla29tIE5ldHpwcm9kdWt0aW9uIEdtYkgNCj4g Rml4ZWQgTW9iaWxlIEVuZ2luZWVyaW5nIERldXRzY2hsYW5kDQo+IFJvbGFuZCBKZXNza2UNCj4g SGVpbnJpY2gtSGVydHotU3RyYcOfZSAzLTcsIDY0Mjk1IERhcm1zdGFkdA0KPiArNDkgNjE1MSA2 MjgtMjc2NiAoVGVsLikNCj4gKzQ5IDUyMSA5MjEwLTM3NTMgIChGYXgpDQo+ICs0OSAxNzEgODYx OC00NDUgIChNb2JpbCkNCj4gRS1NYWlsOiBtYWlsdG86ci5qZXNza2VAdGVsZWtvbS5kZQ0KPiBo dHRwOi8vd3d3LnRlbGVrb20uZGUNCj4NCj4gRXJsZWJlbiwgd2FzIHZlcmJpbmRldC4NCj4NCj4g RGV1dHNjaGUgVGVsZWtvbSBOZXR6cHJvZHVrdGlvbiBHbWJIDQo+IEF1ZnNpY2h0c3JhdDogRHIu IFN0ZWZmZW4gUm9laG4gKFZvcnNpdHplbmRlcikNCj4gR2VzY2jDpGZ0c2bDvGhydW5nOiBEci4g QnJ1bm8gSmFjb2JmZXVlcmJvcm4NCj4gKFZvcnNpdHplbmRlciksIEFsYmVydCBNYXRoZWlzLCBL bGF1cyBQZXJlbg0KPiBIYW5kZWxzcmVnaXN0ZXI6IEFtdHNnZXJpY2h0IEJvbm4gSFJCIDE0MTkw DQo+IFNpdHogZGVyIEdlc2VsbHNjaGFmdCBCb25uDQo+IFVTdC1JZE5yLiBERSA4MTQ2NDUyNjIN Cj4NCj4gR3Jvw59lIFZlcsOkbmRlcnVuZ2VuIGZhbmdlbiBrbGVpbiBhbiAtDQo+IFJlc3NvdXJj ZW4gc2Nob25lbiB1bmQgbmljaHQgamVkZSBFLU1haWwgZHJ1Y2tlbi4NCj4NCj4NCj4NCj4NCj4g ICAgICAgICAgICAgICAgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0N Cj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgIFZvbjogZGlzcGF0Y2gtYm91bmNlc0BpZXRm Lm9yZw0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgW21haWx0bzpkaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnXSBJbQ0KPiBBdWZ0cmFnIHZvbiBKZXNza2UsIFJvbGFuZA0KPg0KPg0KPiAg ICAgICAgICAgICAgICAgICAgICAgR2VzZW5kZXQ6IE1pdHR3b2NoLCA2LiBBcHJpbCAyMDExIDEx OjI0DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICBBbjogR29uemFsby5DYW1hcmlsbG9A ZXJpY3Nzb24uY29tOw0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPg0KPg0KPiAgICAgICAgICAgICAg ICAgICAgICAgQmV0cmVmZjogUmU6IFtkaXNwYXRjaF0gU0lQIHJlc3BvbnNlcw0KPiBjYXJyeWlu ZyBRLjg1MCBjYXVzZQ0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVzIGluIFJl YXNvbiBoZWFkZXIgZmllbGRzDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICBIaSBH b256YWxvLA0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgSSdtIE9LIHdpdGggeW91ciBw cm9wb3NhbCBzbyBJIGNvdWxkDQo+IGNoYW5nZSBpdCBpZiBwZW9wbGUNCj4NCj4NCj4gICAgICAg ICAgICAgICAgICAgICAgIHdvdWxkIGxpa2UgaXQuDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgICBJdCBtYWtlcyBpdCBzaG9ydGVyLg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAg VGhlIG9ubHkgSSB3b3VsZCBwcm9wb3NlIHRvIGhhdmUgaW4gaXMNCj4gdGhlIGV4cGxpY2l0DQo+ DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICBtZW50aW9uaW5nIG9mIHRoZSBSZXNwb25zZSB2 YWx1ZXMgZHVlDQo+IHRvIHRoZSBmYWN0IHRoYXQgYQ0KPg0KPg0KPiAgICAgICAgICAgICAgICAg ICAgICAgMTAwT0sgb3IgMjAwT0sgc2hvdWxkIG5vdCBpbmNsdWRlIGENCj4gUmVhc29uIGhlYWRl ciB3aXRoIGENCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgIFEuODUwIENhdXNlIFZhbHVl Lg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgQmVzdCBSZWdhcmRzDQo+DQo+DQo+ ICAgICAgICAgICAgICAgICAgICAgICBSb2xhbmQgSmVzc2tlDQo+DQo+DQo+DQo+DQo+DQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0 LS0tLS0NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVm9uOiBkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnDQo+DQo+DQo+DQo+IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0Bp ZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gR29uemFsbyBDYW1hcmlsbG8NCj4NCj4NCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgR2VzZW5kZXQ6IERpZW5zdGFnLCA1LiBBcHJpbCAyMDEx IDE0OjAzDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuOiBESVNQQVRD SA0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXRyZWZmOiBbZGlzcGF0 Y2hdIFNJUA0KPiByZXNwb25zZXMgY2FycnlpbmcgUS44NTAgY2F1c2UgdmFsdWVzDQo+DQo+DQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIFJlYXNvbiBoZWFkZXIgZmllbGRzDQo+ DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhpLA0KPg0KPg0KPg0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYXN0IHdlZWsgaW4gdGhlIERJU1BBVENIDQo+ IHNlc3Npb24sIHRoZXJlIHdhcyBjb25zZW5zdXMgdG8gYWxsb3cgU0lQDQo+DQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHJlc3BvbnNlcyB0byBjYXJyeSBSZWFzb24NCj4gaGVh ZGVyIGZpZWxkcyB3aXRoIFEuODUwIGNhdXNlDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAg ICB2YWx1ZXMuIEFzIEkNCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Fp ZCBzb21lIHRpbWUgYWdvLCBJIGFtDQo+IHdpbGxpbmcgdG8gQUQgc3BvbnNvciB0aGlzIGRyYWZ0 DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICBpZi93aGVuIHRoZQ0KPg0KPg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBESVNQQVRDSCBjaGFpcnMgY29uZmlybSBzdWNoDQo+ IGNvbnNlbnN1cyBvbiB0aGUgbGlzdC4NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSW4gdGhlIG1lYW4gdGltZSwgSSBoYXZlIHNvbWUNCj4gY29tbWVudHMgb24gaG93 IHRvIGRvY3VtZW50DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMg ZGVjaXNpb24uDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBmb2xs b3dpbmcgKGZhaXJseSBzaG9ydCkNCj4gZHJhZnQgdXBkYXRlcyBhIGNvdXBsZSBvZg0KPg0KPg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJhZ3JhcGhzIGluIFJGQw0KPg0KPg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzMzI2IGluIG9yZGVyIHRvIGFjaGlldmUg dGhlDQo+IGRlc2lyZWQgb3V0Y29tZToNCj4NCj4NCj4NCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1qZXNza2UtZGlzcGF0Y2gtdXBkYXRlMzMyNi1yZWFzb24NCj4gLXJlc3BvbnNl cy0wMi50eHQNCj4NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSB0 aGluayB0aGlzIGlzIG5vdCBhDQo+IHBhcnRpY3VsYXJseSBlbGVnYW50IHdheSB0byBkZWZpbmUN Cj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgIHdoYXQgd2Ugd2FudC4NCj4NCj4NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIGlmIHdlIHdhbnRlZCB0bw0K PiBkZWZpbmUgYSBzb2x1dGlvbiB0byBIRVJGUCBpbg0KPg0KPg0KPiAgICAgICAgICAgICAgICAg ICAgICAgdGhlIGZ1dHVyZQ0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBi YXNlZCBvbiB0aGUgUmVhc29uIGhlYWRlciwgd2UNCj4gd291bGQgbmVlZCB0byB1cGRhdGUgdGhv c2UgcGFyYWdyYXBocw0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZ2Fp biwgbWFraW5nIHRoZW0gbG9uZ2VyIGV2ZXJ5DQo+IHRpbWUgd2UgYWRkZWQgYSBuZXcgdXNlIGNh c2UuDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEluc3RlYWQsIEkg d291bGQgcHJlZmVyIHRvDQo+IGV4cGxpY2l0bHkgZGVmaW5lIHdoYXQgd2Ugd2FudA0KPg0KPg0K PiAgICAgICAgICAgICAgICAgICAgICAgdG8gZG8gYW5kIGJlDQo+DQo+DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGRvbmUgd2l0aCBpdC4gU3VjaCBhIChhbHNvDQo+IGZhaXJseSBz aG9ydCkgZHJhZnQgd291bGQgc2F5DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHNvbWV0aGluZyBhbG9uZw0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aGUgZm9sbG93aW5nIGxpbmVzOg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAiUkZDIDMzMjYgYWxsb3dzIHRoZSBwcmVzZW5jZQ0KPiBvZiB0aGUgUmVhc29uIGhl YWRlciBmaWVsZCBpbg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbnkg cmVzcG9uc2UNCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hvc2Ugc3Rh dHVzIGNvZGUgZXhwbGljaXRseQ0KPiBhbGxvd3MgaXRzIHByZXNlbmNlLiBUaGlzIGRvY3VtZW50 DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGxpY2l0bHkgYWxsb3dz IGFueSBTSVANCj4gcmVzcG9uc2UgdG8gY2FycnkgYSBSZWFzb24gaGVhZGVyDQo+DQo+DQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZpZWxkIHdpdGggYQ0KPg0KPg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBRLjg1MCBjYXVzZSB2YWx1ZS4gU0lQDQo+IHJlc3BvbnNl cyB3aXRoIFJlYXNvbiBoZWFkZXIgZmllbGRzIGNhcnJ5aW5nDQo+DQo+DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHZhbHVlcyBvdGhlciB0aGFuIFEuODUwIGNhdXNlDQo+IHZhbHVl cyBhcmUgb3V0c2lkZSBvZiB0aGUNCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgIHNjb3Bl IG9mIHRoaXMNCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9jdW1lbnQu Ig0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHdvdWxkIGxpa2Ug dG8ga25vdyB0aGUNCj4gb3BpbmlvbiBvZiB0aGUgV0cgb24gdGhpcyBtYXR0ZXINCj4NCj4NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGkuZS4sIGhvdyB0bw0KPg0KPg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBkb2N1bWVudCB0aGUgV0cncyBjb25zZW5zdXMpLg0K PiBOb3RlIHRoYXQgcmVhY2hpbmcgY29uc2Vuc3VzIHdhcyB0aGUNCj4NCj4NCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZGlmZmljdWx0IHBhcnQuIEFncmVlaW5nIG9uIGhvdw0KPiB0 byBkb2N1bWVudCBpdCBzaG91bGQgYmUgZWFzeS4NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGhhbmtzLA0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBHb256YWxvDQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBkaXNwYXRjaEBpZXRmLm9yZw0KPg0KPg0KPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0K Pg0KPiAgICAgICAgICAgICAgICAgICAgICAgZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+DQo+DQo+ ICAgICAgICAgICAgICAgICAgICAgICBkaXNwYXRjaEBpZXRmLm9yZw0KPg0KPg0KPiAgICAgICAg ICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNw YXRjaA0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgICAgICAgICAgZGlzcGF0Y2ggbWFpbGluZyBs aXN0DQo+ICAgICAgICAgICAgICAgZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gICAgICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQo+DQo+DQo+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGlzcGF0 Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From christer.holmberg@ericsson.com Thu May 19 01:13:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59EE0711 for ; Thu, 19 May 2011 01:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfPnGQUlGcvn for ; Thu, 19 May 2011 01:13:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1D331E068C for ; Thu, 19 May 2011 01:13:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e3-4dd4d13a56d6 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.FE.09774.A31D4DD4; Thu, 19 May 2011 10:13:46 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 19 May 2011 10:13:45 +0200 From: Christer Holmberg To: "'R.Jesske@telekom.de'" , "dispatch@ietf.org" , Gonzalo Camarillo Date: Thu, 19 May 2011 10:13:45 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhAAANFRMA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C83B@ESESSCMS0356.eemea.ericsson.se> References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 08:13:48 -0000 Sounds good. Regards, Christer=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of R.Jesske@telekom.de Sent: 19. toukokuuta 2011 10:58 To: dispatch@ietf.org; Gonzalo Camarillo Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason= header fields Dear all, So assuming that there was no comment people are happy with the new rewordi= ng I would like to prepare a new draft. This would be Option 1: General wording to allow the Reason header within r= esponses without any restrictions (except 100 Trying). And nobody wanted to have Option 2: Wording as stated in the current draft draft-jesske-dispatch-update3326-reason-responses-02 Agreed? Comments? Thank you and best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jesske, Roland > Gesendet: Donnerstag, 19. Mai 2011 09:50 > An: Jesske, Roland > Betreff: AW: [dispatch] SIP responses carrying Q.850 cause values in=20 > Reason header fields > > > > On May 13, 2011, at 3:18 AM, wrote: > > > Hi, > Since my answer it looks that people would be OK with the change. > So if no body comments within the next few days I would prepare a new=20 > draft. > > So due to Gonzalo's proposal I would rewrite the paragraphs as shown=20 > below. > For comparison reasons I have added also the text proposal of the=20 > current draft (draft-jesske-dispatch-update3326-reason-responses-02). > Please indicate which text you would like to see finally. New proposal=20 > or current proposal. > > > 3. RFC3326 1. Introduction > > Original Text: > > Initially, the Reason header field defined here appears to be most > useful for BYE and CANCEL requests, but it can appear in any request > within a dialog, in any CANCEL request and in any response whose > status code explicitly allows the presence of this header field. > > Note that the Reason header field is usually not needed in responses > because the status code and the reason phrase already provide > sufficient information. > > New Text(new proposal): > > Initially, the Reason header field defined here appears to be most > useful for BYE and CANCEL requests, but it can appear in any request > within a dialog, in any CANCEL request independent of the protocol > value used and in any response except 100 trying. > > New Text (text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > Initially, the Reason header field defined here appears to be most > useful for BYE and CANCEL requests, but it can appear in any request =20 > within a dialog, in any CANCEL request independent of the protocol > value used and in any response except 100 trying if it contains only > a Q.850 Cause Code. > > 4. RFC3326 2. The Reason Header Field > > Original Text > > The Reason header field MAY appear in any request within a dialog,=20 > in > any CANCEL request and in any response whose status code explicitly > allows the presence of this header field. > > > > > Jesske & Liess Expires October 2, > 2011 [Page 3] > > Internet-Draft Reason Header > March 2011 > > > New Text(new proposal): > > The Reason header field MAY appear > in any request within a dialog, in any CANCEL request . The > appearance of the Reason header field is applicable to final=20 > responses 3xx, 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > > New Text(text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > The Reason header field only containing a Q.850 Cause Code MAY=20 > appear > in any request within a dialog, in any CANCEL request . The > appearance of the Reason header field only containing a Q.850 Cause > Code is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > The Reason header field containing any other reason value MAY appear > in any request within a dialog, in any CANCEL request and in any > response whose status code explicitly allows the presence of this > header field. > > > > > Best Regards > > > Roland > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > 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: mailto:r.jesske@telekom.de > http://www.telekom.de > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert=20 > Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft Bonn=20 > USt-IdNr. DE 814645262 > > Gro=DFe Ver=E4nderungen fangen klein an - > Ressourcen schonen und nicht jede E-Mail drucken. > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag=20 > von Jesske, Roland > > > Gesendet: Mittwoch, 6. April 2011 11:24 > > > An: Gonzalo.Camarillo@ericsson.com;=20 > dispatch@ietf.org > > > Betreff: Re: [dispatch] SIP responses carrying=20 > Q.850 cause > > > values in Reason header fields > > > > Hi Gonzalo, > > > I'm OK with your proposal so I could change it=20 > if people > > > would like it. > > > It makes it shorter. > > > The only I would propose to have in is the=20 > explicit > > > mentioning of the Response values due to the=20 > fact that a > > > 100OK or 200OK should not include a Reason=20 > header with a > > > Q.850 Cause Value. > > > > Best Regards > > > Roland Jesske > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > > > Gesendet: Dienstag, 5. April 2011 14:03 > > > An: DISPATCH > > > Betreff: [dispatch] SIP responses=20 > carrying Q.850 cause values > > > in Reason header fields > > > > Hi, > > > > last week in the DISPATCH session, there=20 > was consensus to allow SIP > > > responses to carry Reason header fields=20 > with Q.850 cause > > > values. As I > > > said some time ago, I am willing to AD=20 > sponsor this draft > > > if/when the > > > DISPATCH chairs confirm such consensus=20 > on the list. > > > > In the mean time, I have some comments=20 > on how to document > > > this decision. > > > The following (fairly short) draft=20 > updates a couple of > > > paragraphs in RFC > > > 3326 in order to achieve the desired=20 > outcome: > > > > > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > -responses-02.txt > > > > > I think this is not a particularly=20 > elegant way to define > > > what we want. > > > For example, if we wanted to define a=20 > solution to HERFP in > > > the future > > > based on the Reason header, we would=20 > need to update those paragraphs > > > again, making them longer every time we=20 > added a new use case. > > > > Instead, I would prefer to explicitly=20 > define what we want > > > to do and be > > > done with it. Such a (also fairly short)=20 > draft would say > > > something along > > > the following lines: > > > > "RFC 3326 allows the presence of the=20 > Reason header field in > > > any response > > > whose status code explicitly allows its=20 > presence. This document > > > explicitly allows any SIP response to=20 > carry a Reason header > > > field with a > > > Q.850 cause value. SIP responses with=20 > Reason header fields carrying > > > values other than Q.850 cause values are=20 > outside of the > > > scope of this > > > document." > > > > I would like to know the opinion of the=20 > WG on this matter > > > (i.e., how to > > > document the WG's consensus). > Note that reaching consensus was the > > > difficult part. Agreeing on how to=20 > document it should be easy. > > > > Thanks, > > > > Gonzalo > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jan.van.geel@belgacom.be Thu May 19 03:56:21 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5696E066C for ; Thu, 19 May 2011 03:56:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieZVR3opM1NC for ; Thu, 19 May 2011 03:56:21 -0700 (PDT) Received: from mx14.belgacom.be (mx14.belgacom.be [195.13.15.234]) by ietfa.amsl.com (Postfix) with ESMTP id EFB29E065D for ; Thu, 19 May 2011 03:56:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,236,1304287200"; d="scan'208";a="20458434" Received: from a03007.bgc.net ([10.120.129.162]) by mx14.belgacom.be with ESMTP; 19 May 2011 12:56:19 +0200 X-TM-IMSS-Message-ID: <03a0fb360000af7d@belgacom.be> Received: from AE7212.BGC.NET ([45.223.1.31]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 03a0fb360000af7d ; Thu, 19 May 2011 12:56:17 +0200 Received: from CMS03.BGC.NET ([169.254.1.6]) by AE7212.BGC.NET ([45.223.1.31]) with mapi; Thu, 19 May 2011 12:56:18 +0200 From: "VAN GEEL Jan (SDV/PSE)" To: "dispatch@ietf.org" Date: Thu, 19 May 2011 12:56:17 +0200 Thread-Topic: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields Thread-Index: AcwWE2DrWv7/PgpWQia2kNtV0qcUYQ== Message-ID: <208EAE1DFA28FC419529619ABB8622441B38935D53@CMS03.BGC.NET> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 10:56:22 -0000 OK=20for=20option=201 Jan=20Van=20Geel IT=20and=20Network=20Specialist Belgacom=20SDE/SDV/PSE/FVC Tel:=20+32=202=20202=201035 Tel:=20+32=202=20207=209032 Email=20:=20jan.van.geel@belgacom.be www.cyberwezz.tk Dear=20all, So=20assuming=20that=20there=20was=20no=20comment=20people=20are=20happy= =20with=20the=20new=20rewording=20I=20would=20like=20to=20prepare=20a=20n= ew=20draft. This=20would=20be=20Option=201:=20General=20wording=20to=20allow=20the=20= Reason=20header=20within=20responses=20without=20any=20restrictions=20(ex= cept=20100=20Trying). And=20nobody=20wanted=20to=20have=20Option=202:=20Wording=20as=20stated= =20in=20the=20current=20draft draft-jesske-dispatch-update3326-reason-responses-02 Agreed?=20Comments? Thank=20you=20and=20best=20Regards Roland ****=20DISCLAIMER=20**** http://www.belgacom.be/maildisclaimer From georg.mayer@huawei.com Thu May 19 04:13:33 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BF1E07A4 for ; Thu, 19 May 2011 04:13:33 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E6sVL72fLX1 for ; Thu, 19 May 2011 04:13:32 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id B07D6E06E2 for ; Thu, 19 May 2011 04:13:32 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLF00F34WIKTE@usaga03-in.huawei.com> for dispatch@ietf.org; Thu, 19 May 2011 06:13:32 -0500 (CDT) Received: from laptopserver (chello062178012102.5.11.vie.surfer.at [62.178.12.102]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLF00CYPWIIMH@usaga03-in.huawei.com> for dispatch@ietf.org; Thu, 19 May 2011 06:13:32 -0500 (CDT) Date: Thu, 19 May 2011 13:13:30 +0200 From: Georg Mayer In-reply-to: <208EAE1DFA28FC419529619ABB8622441B38935D53@CMS03.BGC.NET> To: dispatch@ietf.org Message-id: <032f01cc1615$c9509ed0$5bf1dc70$%mayer@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: de Content-transfer-encoding: 7BIT Thread-index: AcwWE2DrWv7/PgpWQia2kNtV0qcUYQAAkY8g References: <208EAE1DFA28FC419529619ABB8622441B38935D53@CMS03.BGC.NET> Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 11:13:33 -0000 Option 1 is gooood. Agreed! Greetings, Georg -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of VAN GEEL Jan (SDV/PSE) Sent: Donnerstag, 19. Mai 2011 12:56 To: dispatch@ietf.org Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields OK for option 1 Jan Van Geel IT and Network Specialist Belgacom SDE/SDV/PSE/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be www.cyberwezz.tk Dear all, So assuming that there was no comment people are happy with the new rewording I would like to prepare a new draft. This would be Option 1: General wording to allow the Reason header within responses without any restrictions (except 100 Trying). And nobody wanted to have Option 2: Wording as stated in the current draft draft-jesske-dispatch-update3326-reason-responses-02 Agreed? Comments? Thank you and best Regards Roland **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu May 19 06:12:06 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17EBE075B for ; Thu, 19 May 2011 06:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.822 X-Spam-Level: X-Spam-Status: No, score=-109.822 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovA+wCXC-ryo for ; Thu, 19 May 2011 06:12:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id AA6F2E06D9 for ; Thu, 19 May 2011 06:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11440; q=dns/txt; s=iport; t=1305810724; x=1307020324; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dHwlxy1OZT7d1oP9gw8Wml0rJLbjaOcCSQ8KTywINWE=; b=DVwM/yytH65TNNVKlieCVjiYkWEdH2n9z5xrZriNWEf0xxHeni07HhR9 SuQiIIkfqKeJhN3rDdsKPrs3AIMgshKZ9ZC61R5Ob20gpUspL87J09EGE 0kXBk+mkBqmRDfUXjvGPjvQybMsP2UzzLVjkNukT6iY+wOGQJO1khoeYb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMkW1U2tJV2c/2dsb2JhbACmDXerOJ4UhhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208";a="234005556" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2011 13:12:03 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4JDC3UR002382 for ; Thu, 19 May 2011 13:12:03 GMT Message-ID: <4DD51723.2040804@cisco.com> Date: Thu, 19 May 2011 09:12:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dispatch@ietf.org References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 13:12:06 -0000 I am getting confused by all the options mentioned, to the point that I don't understand what is being proposed now. It *sounds* like you are proposing to allow *any* reason (including sip reason codes) in any response. I am concerned that that will cause considerable confusion. I apologize if that is not what you are proposing. Thanks, Paul On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: > Dear all, > So assuming that there was no comment people are happy with the new rewording I would like to prepare a new draft. > > This would be Option 1: General wording to allow the Reason header within responses without any restrictions (except 100 Trying). > And nobody wanted to have Option 2: Wording as stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02 > > Agreed? Comments? > > Thank you and best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Jesske, Roland >> Gesendet: Donnerstag, 19. Mai 2011 09:50 >> An: Jesske, Roland >> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >> values in Reason header fields >> >> >> >> On May 13, 2011, at 3:18 AM, wrote: >> >> >> Hi, >> Since my answer it looks that people would be >> OK with the change. >> So if no body comments within the next few days >> I would prepare a new draft. >> >> So due to Gonzalo's proposal I would rewrite >> the paragraphs as shown below. >> For comparison reasons I have added also the >> text proposal of the current draft >> (draft-jesske-dispatch-update3326-reason-responses-02). >> Please indicate which text you would like to >> see finally. New proposal or current proposal. >> >> >> 3. RFC3326 1. Introduction >> >> Original Text: >> >> Initially, the Reason header field defined >> here appears to be most >> useful for BYE and CANCEL requests, but it >> can appear in any request >> within a dialog, in any CANCEL request and in >> any response whose >> status code explicitly allows the presence of >> this header field. >> >> Note that the Reason header field is usually >> not needed in responses >> because the status code and the reason phrase >> already provide >> sufficient information. >> >> New Text(new proposal): >> >> Initially, the Reason header field defined >> here appears to be most >> useful for BYE and CANCEL requests, but it >> can appear in any request >> within a dialog, in any CANCEL request >> independent of the protocol >> value used and in any response except 100 trying. >> >> New Text (text stated in the current draft >> draft-jesske-dispatch-update3326-reason-responses-02): >> >> Initially, the Reason header field defined >> here appears to be most >> useful for BYE and CANCEL requests, but it >> can appear in any request >> within a dialog, in any CANCEL request >> independent of the protocol >> value used and in any response except 100 >> trying if it contains only >> a Q.850 Cause Code. >> >> 4. RFC3326 2. The Reason Header Field >> >> Original Text >> >> The Reason header field MAY appear in any >> request within a dialog, in >> any CANCEL request and in any response whose >> status code explicitly >> allows the presence of this header field. >> >> >> >> >> Jesske& Liess Expires October 2, >> 2011 [Page 3] >> >> Internet-Draft Reason Header >> March 2011 >> >> >> New Text(new proposal): >> >> The Reason header field MAY appear >> in any request within a dialog, in any CANCEL >> request . The >> appearance of the Reason header field is >> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >> and 199 provisional responses [I-D.ietf-sipcore-199]. >> >> >> New Text(text stated in the current draft >> draft-jesske-dispatch-update3326-reason-responses-02): >> >> The Reason header field only containing a >> Q.850 Cause Code MAY appear >> in any request within a dialog, in any CANCEL >> request . The >> appearance of the Reason header field only >> containing a Q.850 Cause >> Code is applicable to final responses 3xx, >> 4xx, 5xx and 6xx and 18x >> and 199 provisional responses [I-D.ietf-sipcore-199]. >> >> The Reason header field containing any other >> reason value MAY appear >> in any request within a dialog, in any CANCEL >> request and in any >> response whose status code explicitly allows >> the presence of this >> header field. >> >> >> >> >> Best Regards >> >> >> Roland >> >> >> Deutsche Telekom Netzproduktion GmbH >> Fixed Mobile Engineering Deutschland >> Roland Jesske >> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt >> +49 6151 628-2766 (Tel.) >> +49 521 9210-3753 (Fax) >> +49 171 8618-445 (Mobil) >> E-Mail: mailto:r.jesske@telekom.de >> http://www.telekom.de >> >> Erleben, was verbindet. >> >> Deutsche Telekom Netzproduktion GmbH >> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) >> Geschäftsführung: Dr. Bruno Jacobfeuerborn >> (Vorsitzender), Albert Matheis, Klaus Peren >> Handelsregister: Amtsgericht Bonn HRB 14190 >> Sitz der Gesellschaft Bonn >> USt-IdNr. DE 814645262 >> >> Große Veränderungen fangen klein an - >> Ressourcen schonen und nicht jede E-Mail drucken. >> >> >> >> >> -----Ursprüngliche Nachricht----- >> >> >> Von: dispatch-bounces@ietf.org >> >> >> [mailto:dispatch-bounces@ietf.org] Im >> Auftrag von Jesske, Roland >> >> >> Gesendet: Mittwoch, 6. April 2011 11:24 >> >> >> An: Gonzalo.Camarillo@ericsson.com; >> dispatch@ietf.org >> >> >> Betreff: Re: [dispatch] SIP responses >> carrying Q.850 cause >> >> >> values in Reason header fields >> >> >> >> Hi Gonzalo, >> >> >> I'm OK with your proposal so I could >> change it if people >> >> >> would like it. >> >> >> It makes it shorter. >> >> >> The only I would propose to have in is >> the explicit >> >> >> mentioning of the Response values due >> to the fact that a >> >> >> 100OK or 200OK should not include a >> Reason header with a >> >> >> Q.850 Cause Value. >> >> >> >> Best Regards >> >> >> Roland Jesske >> >> >> >> >> >> -----Ursprüngliche Nachricht----- >> >> >> Von: dispatch-bounces@ietf.org >> >> >> >> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo >> >> >> Gesendet: Dienstag, 5. April 2011 14:03 >> >> >> An: DISPATCH >> >> >> Betreff: [dispatch] SIP >> responses carrying Q.850 cause values >> >> >> in Reason header fields >> >> >> >> Hi, >> >> >> >> last week in the DISPATCH >> session, there was consensus to allow SIP >> >> >> responses to carry Reason >> header fields with Q.850 cause >> >> >> values. As I >> >> >> said some time ago, I am >> willing to AD sponsor this draft >> >> >> if/when the >> >> >> DISPATCH chairs confirm such >> consensus on the list. >> >> >> >> In the mean time, I have some >> comments on how to document >> >> >> this decision. >> >> >> The following (fairly short) >> draft updates a couple of >> >> >> paragraphs in RFC >> >> >> 3326 in order to achieve the >> desired outcome: >> >> >> >> >> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >> -responses-02.txt >> >> >> >> >> I think this is not a >> particularly elegant way to define >> >> >> what we want. >> >> >> For example, if we wanted to >> define a solution to HERFP in >> >> >> the future >> >> >> based on the Reason header, we >> would need to update those paragraphs >> >> >> again, making them longer every >> time we added a new use case. >> >> >> >> Instead, I would prefer to >> explicitly define what we want >> >> >> to do and be >> >> >> done with it. Such a (also >> fairly short) draft would say >> >> >> something along >> >> >> the following lines: >> >> >> >> "RFC 3326 allows the presence >> of the Reason header field in >> >> >> any response >> >> >> whose status code explicitly >> allows its presence. This document >> >> >> explicitly allows any SIP >> response to carry a Reason header >> >> >> field with a >> >> >> Q.850 cause value. SIP >> responses with Reason header fields carrying >> >> >> values other than Q.850 cause >> values are outside of the >> >> >> scope of this >> >> >> document." >> >> >> >> I would like to know the >> opinion of the WG on this matter >> >> >> (i.e., how to >> >> >> document the WG's consensus). >> Note that reaching consensus was the >> >> >> difficult part. Agreeing on how >> to document it should be easy. >> >> >> >> Thanks, >> >> >> >> Gonzalo >> >> >> >> >> _______________________________________________ >> >> >> dispatch mailing list >> >> >> dispatch@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> _______________________________________________ >> >> >> dispatch mailing list >> >> >> dispatch@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From fluffy@cisco.com Thu May 19 07:08:23 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B764CE07D5 for ; Thu, 19 May 2011 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3vQP6t36zDZ for ; Thu, 19 May 2011 07:08:22 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E605AE07BC for ; Thu, 19 May 2011 07:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2056; q=dns/txt; s=iport; t=1305814102; x=1307023702; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EmcqjNVsjq47bxmf2ot5lYDUhEdEdOkDxd8l6pBpIN8=; b=LFRm8DFPhlfkquMaNQ7Rx7Bmnxn6bCRQNMlJB5uRfUQnBeTvwBJbJoof OXlGzSal1uYx1uNe86vuskzj2w/BcB+iS1xSjF/AzWArk+noDDCN6a2X8 /e5NC9VuSKQGsLBYqjEOkz5rTfH5v1LdzNeGw2YJekvazLSm99Fvw0pft 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGUj1U2rRDoJ/2dsb2JhbACmDnerVJ4dhhkEhlCJQYQvimU X-IronPort-AV: E=Sophos;i="4.65,237,1304294400"; d="scan'208";a="700174877" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 19 May 2011 14:08:22 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4JE8LcG014784; Thu, 19 May 2011 14:08:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DD12CA7.3080409@ericsson.com> Date: Thu, 19 May 2011 08:08:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DD12CA7.3080409@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1084) Cc: DISPATCH list Subject: [dispatch] goals of draft-loreto-dispatch-3892bis-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 14:08:23 -0000 On May 16, 2011, at 7:54 AM, Salvatore Loreto wrote: >=20 >=20 > below there is also a first tentative of charter proposal for a wg > to work on updating the Referred-by header. > http://tools.ietf.org/html/draft-loreto-dispatch-3892bis-02 It's been a long time since I looked the message exploder stuff. So A = sends a message to the exploder, called E, that explodes it to B. If A = had a PAI with with a sip and tel URI it sent to E. Now the message from = E to B is going to have some stuff in it but the goal is that if B = supports sip URIs, a return message would go to E, but if B only support = tel URI then the return message would go to A. Did I get this about = right? (and by return message I mean a new out of dialog request).=20 I can get my head around the requirement for E to massacred as A, or for = E to show up as E, but I have a hard time seeing how B is going to have = a good user experience if E tries to do both at the same time. I'm sure = you have considered the option of the E sends the same PAI as it = received from A. I seem to recall that is what the message exploder RFC = says to do in the case the PAI is trusted.=20 Don't take this wrong way - I'm not saying there is no problem here - = I'm just not understanding the use case that leads to it and what the = type of behavior on the B would be needed to make it all work.=20 I'm also not clear if fixing this is need to update things like RFC5365 = or just be a new RFC - I was sort of surprised your draft did not = reference the 5363 group of stuff as it seem it is proposing an = extension to theses - it would be good to get some feedback on that for = sorting out the charter.=20 I think it would also be worth thinking about requirements around = backwards compatibility with existing UA. If B in the example above = receives an SIP message that is not consistent with the 3261 ABNF, it = very well may discard the whole message. A SIP firewall may do the same.=20= Cullen, in my individual contributor role From dworley@avaya.com Thu May 19 07:26:34 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C5E0704 for ; Thu, 19 May 2011 07:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZbz3y8Q4SLT for ; Thu, 19 May 2011 07:26:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 268E5E06C9 for ; Thu, 19 May 2011 07:26:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABco1U2HCzI1/2dsb2JhbACmDneuBAKbYYYZBJRdikU X-IronPort-AV: E=Sophos;i="4.65,237,1304308800"; d="scan'208";a="280765268" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 May 2011 10:26:32 -0400 X-IronPort-AV: E=Sophos;i="4.65,237,1304308800"; d="scan'208";a="653850064" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 May 2011 10:26:32 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 19 May 2011 10:26:32 -0400 From: "Worley, Dale R (Dale)" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" , "Gonzalo.Camarillo@ericsson.com" Date: Thu, 19 May 2011 10:26:04 -0400 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhAADdTeVQ== Message-ID: References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com>, <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 14:26:34 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of R.= Jesske@telekom.de [R.Jesske@telekom.de] So assuming that there was no comment people are happy with the new rewordi= ng I would like to prepare a new draft. _______________________________________________ I'm not particular, as long as this goes forward. Dale From dworley@avaya.com Thu May 19 07:45:30 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDDAE07D2 for ; Thu, 19 May 2011 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmAeUrnmocoe for ; Thu, 19 May 2011 07:45:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 40A45E06DD for ; Thu, 19 May 2011 07:45:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHYq1U3GmAcF/2dsb2JhbACmDneIcKUiAptfgyeCcgSUXYpF X-IronPort-AV: E=Sophos;i="4.65,237,1304308800"; d="scan'208";a="280769478" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 May 2011 10:45:29 -0400 X-IronPort-AV: E=Sophos;i="4.65,237,1304308800"; d="scan'208";a="623877909" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 May 2011 10:45:29 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 19 May 2011 10:45:29 -0400 From: "Worley, Dale R (Dale)" To: Cullen Jennings , DISPATCH list Date: Thu, 19 May 2011 10:45:29 -0400 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AcwVhvRWfU4diZ7qQ1WU2IcHhQHLZwAqxtBN Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 14:45:30 -0000 > From: Cullen Jennings [fluffy@cisco.com] >=20 > The biggest issues is that this is going to reduce interoperability > with systems that don't use this type of instance id [...] Could you explain this? The system I'm familiar treats the instance-id largely as an opaque string. Certainly, any SIP system must be prepared to see instance-id values from namespaces that it does not understand. How could a device using a new instance-id namespace break any existing registrar, unless the registrar was only able to deal with a limited set of namespaces? > To indicate the version of the software, I would suggest using the SIP > User Agent header. That sounds like a good idea, unless the "Software Version" is not just an attribute of the device but somehow a qualifier of the meaning of the IMEI. I'm more worried that the "Software Version" is a declaration of the capabilities of the handset, in which case it should really be encoded in the Supported header in some way. Is there a list of specified Software Versions? > There are also significant privacy concerns around this proposal. That's true, but it seems to me that that's the whole point of it -- to make the endpoint rigidly identifiable to the user and mobile account. Dale From thomas.belling@nsn.com Thu May 19 08:51:11 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03939E0810 for ; Thu, 19 May 2011 08:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjsxcsON9jUV for ; Thu, 19 May 2011 08:51:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5975DE080F for ; Thu, 19 May 2011 08:51:08 -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 p4JFp6G0010179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2011 17:51:06 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4JFp1DQ003361; Thu, 19 May 2011 17:51:06 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 17:51:05 +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: Thu, 19 May 2011 17:51:04 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F2507A4@DEMUEXC014.nsn-intra.net> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhAAELXO4A== References: <4D9B04E3.2090301@ericsson.com><580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> From: "Belling, Thomas (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 19 May 2011 15:51:05.0870 (UTC) FILETIME=[901EFAE0:01CC163C] Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 15:51:11 -0000 +1 for option 1. Having ITU-T style delta specs, where you describe textual modifications = per paragraph, is quite uncommon in RFCs that update other RFCs. Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext R.Jesske@telekom.de Sent: Thursday, May 19, 2011 9:58 AM To: dispatch@ietf.org; Gonzalo.Camarillo@ericsson.com Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin = Reason header fields Dear all, So assuming that there was no comment people are happy with the new = rewording I would like to prepare a new draft. This would be Option 1: General wording to allow the Reason header = within responses without any restrictions (except 100 Trying). And nobody wanted to have Option 2: Wording as stated in the current = draft draft-jesske-dispatch-update3326-reason-responses-02 Agreed? Comments? Thank you and best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jesske, Roland > Gesendet: Donnerstag, 19. Mai 2011 09:50 > An: Jesske, Roland > Betreff: AW: [dispatch] SIP responses carrying Q.850 cause values in=20 > Reason header fields > > > > On May 13, 2011, at 3:18 AM, wrote: > > > Hi, > Since my answer it looks that people would be OK with the change. > So if no body comments within the next few days I would prepare a new=20 > draft. > > So due to Gonzalo's proposal I would rewrite the paragraphs as shown=20 > below. > For comparison reasons I have added also the text proposal of the=20 > current draft (draft-jesske-dispatch-update3326-reason-responses-02). > Please indicate which text you would like to see finally. New proposal = > or current proposal. > > > 3. RFC3326 1. Introduction > > Original Text: > > Initially, the Reason header field defined here appears to be most > useful for BYE and CANCEL requests, but it can appear in any request > within a dialog, in any CANCEL request and in any response whose > status code explicitly allows the presence of this header field. > > Note that the Reason header field is usually not needed in responses > because the status code and the reason phrase already provide > sufficient information. > > New Text(new proposal): > > Initially, the Reason header field defined here appears to be most > useful for BYE and CANCEL requests, but it can appear in any request > within a dialog, in any CANCEL request independent of the protocol > value used and in any response except 100 trying. > > New Text (text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > Initially, the Reason header field defined here appears to be most > useful for BYE and CANCEL requests, but it can appear in any request = =20 > within a dialog, in any CANCEL request independent of the protocol > value used and in any response except 100 trying if it contains only > a Q.850 Cause Code. > > 4. RFC3326 2. The Reason Header Field > > Original Text > > The Reason header field MAY appear in any request within a dialog,=20 > in > any CANCEL request and in any response whose status code explicitly > allows the presence of this header field. > > > > > Jesske & Liess Expires October 2, > 2011 [Page 3] > > Internet-Draft Reason Header > March 2011 > > > New Text(new proposal): > > The Reason header field MAY appear > in any request within a dialog, in any CANCEL request . The > appearance of the Reason header field is applicable to final=20 > responses 3xx, 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > > New Text(text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > The Reason header field only containing a Q.850 Cause Code MAY=20 > appear > in any request within a dialog, in any CANCEL request . The > appearance of the Reason header field only containing a Q.850 Cause > Code is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > The Reason header field containing any other reason value MAY appear > in any request within a dialog, in any CANCEL request and in any > response whose status code explicitly allows the presence of this > header field. > > > > > Best Regards > > > Roland > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > 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: mailto:r.jesske@telekom.de > http://www.telekom.de > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert=20 > 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. > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag=20 > von Jesske, Roland > > > Gesendet: Mittwoch, 6. April 2011 11:24 > > > An: Gonzalo.Camarillo@ericsson.com;=20 > dispatch@ietf.org > > > Betreff: Re: [dispatch] SIP responses carrying=20 > Q.850 cause > > > values in Reason header fields > > > > Hi Gonzalo, > > > I'm OK with your proposal so I could change it=20 > if people > > > would like it. > > > It makes it shorter. > > > The only I would propose to have in is the=20 > explicit > > > mentioning of the Response values due to the=20 > fact that a > > > 100OK or 200OK should not include a Reason=20 > header with a > > > Q.850 Cause Value. > > > > Best Regards > > > Roland Jesske > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > > > Gesendet: Dienstag, 5. April 2011 14:03 > > > An: DISPATCH > > > Betreff: [dispatch] SIP responses=20 > carrying Q.850 cause values > > > in Reason header fields > > > > Hi, > > > > last week in the DISPATCH session, there = > was consensus to allow SIP > > > responses to carry Reason header fields=20 > with Q.850 cause > > > values. As I > > > said some time ago, I am willing to AD=20 > sponsor this draft > > > if/when the > > > DISPATCH chairs confirm such consensus=20 > on the list. > > > > In the mean time, I have some comments=20 > on how to document > > > this decision. > > > The following (fairly short) draft=20 > updates a couple of > > > paragraphs in RFC > > > 3326 in order to achieve the desired=20 > outcome: > > > > > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > -responses-02.txt > > > > > I think this is not a particularly=20 > elegant way to define > > > what we want. > > > For example, if we wanted to define a=20 > solution to HERFP in > > > the future > > > based on the Reason header, we would=20 > need to update those paragraphs > > > again, making them longer every time we=20 > added a new use case. > > > > Instead, I would prefer to explicitly=20 > define what we want > > > to do and be > > > done with it. Such a (also fairly short) = > draft would say > > > something along > > > the following lines: > > > > "RFC 3326 allows the presence of the=20 > Reason header field in > > > any response > > > whose status code explicitly allows its=20 > presence. This document > > > explicitly allows any SIP response to=20 > carry a Reason header > > > field with a > > > Q.850 cause value. SIP responses with=20 > Reason header fields carrying > > > values other than Q.850 cause values are = > outside of the > > > scope of this > > > document." > > > > I would like to know the opinion of the=20 > WG on this matter > > > (i.e., how to > > > document the WG's consensus). > Note that reaching consensus was the > > > difficult part. Agreeing on how to=20 > document it should be easy. > > > > Thanks, > > > > Gonzalo > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From marianne.mohali@orange-ftgroup.com Thu May 19 10:01:38 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54438E081C for ; Thu, 19 May 2011 10:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ6AnmnrvSRf for ; Thu, 19 May 2011 10:01:37 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 93CCBE073B for ; Thu, 19 May 2011 10:01:37 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 18107FC400C for ; Thu, 19 May 2011 19:01:36 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1040DFC4007 for ; Thu, 19 May 2011 19:01:36 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 19:01:35 +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: Thu, 19 May 2011 19:01:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] New Version Notification fordraft-mohali-dispatch-reason-for-applications-00 Thread-Index: AcwWQ91pqkj7CpSOQ5GPwQqrYQ6xYQAAMhmA From: To: X-OriginalArrivalTime: 19 May 2011 17:01:35.0824 (UTC) FILETIME=[695EBD00:01CC1646] Subject: [dispatch] New Version Notification fordraft-mohali-dispatch-reason-for-applications-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 17:01:38 -0000 Hello, Here is a new version of the draft previously discussed in SIPCORE WG = and quickly presented at the last DISPATCH meeting by Mary. http://www.ietf.org/id/draft-mohali-dispatch-reason-for-applications-00.t= xt=20 The draft proposes to extend the Reason header, allowing proxies to = indicate an application-specific reason in the SIP message. We think that it would be usefull to have this kind of = application-specific reasons especially in the History-Info header when = a call has been retargeted by an Application. We would like to get some feedback on the proposed I-D and a = confirmation of interest from the IETF community (DISPATCH). Best Regards, Marianne Mohali -----Message d'origine----- De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Envoy=E9 : jeudi 19 mai 2011 18:43 =C0 : MOHALI Marianne RD-CORE-ISS Cc : CHATRAS Bruno RD-CORE-ISS; MOHALI Marianne RD-CORE-ISS Objet : New Version Notification = fordraft-mohali-dispatch-reason-for-applications-00.txt A new version of I-D, = draft-mohali-dispatch-reason-for-applications-00.txt has been = successfully submitted by Marianne Mohali and posted to the IETF = repository. Filename: draft-mohali-dispatch-reason-for-applications Revision: 00 Title: Extending the Session Initiation Protocol (SIP) Reason Header = for Applications Creation date: 2011-05-19 WG ID: Individual Submission Number of pages: 11 Abstract: This document defines a new protocol value "Application" = for the Reason Header field and a new IANA Registry for registering application types. This new value enables signaling that a request or response has been issued as a result of a decision made by a particular type of application or that an initial request has been retargeted as a result of an application decision. = =20 The IETF Secretariat From fluffy@cisco.com Thu May 19 13:19:20 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0958BE06BE for ; Thu, 19 May 2011 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKNgOXyqW6Md for ; Thu, 19 May 2011 13:19:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id D6305E06B9 for ; Thu, 19 May 2011 13:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=563; q=dns/txt; s=iport; t=1305836358; x=1307045958; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dXYf7E6BIc5TvpbKQn/+v/xIrH/jaaQXfHHfvBznKNU=; b=d9WQHUGVAR5AdgrUCns2Rr3986uY4lkDNk3j/kr/WXtUsHEDCeD1mJ+h DMrM+5mrMvb9zuFujmKnFFsyyinJaudEaBo2O3jkeLhtODb3OTOjGT5bx l0ACABBmlncC/GgDt0glUhXZ5J2P8vLg3/8sddxAJUMTVMGFZiozOMqOO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABV71U2rRDoJ/2dsb2JhbACmFHepBJ4TgyeCcgSGUIlBhC+KZQ X-IronPort-AV: E=Sophos;i="4.65,238,1304294400"; d="scan'208";a="319539065" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 19 May 2011 20:19:18 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4JKJHhV017060; Thu, 19 May 2011 20:19:18 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 19 May 2011 14:19:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <70F0AEBE-8C8D-436C-A139-D21E45A290E2@cisco.com> References: To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1084) Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 20:19:20 -0000 On May 19, 2011, at 8:45 AM, Worley, Dale R (Dale) wrote: >>=20 >> There are also significant privacy concerns around this proposal. >=20 > That's true, but it seems to me that that's the whole point of it -- > to make the endpoint rigidly identifiable to the user and mobile > account. well making it identifiable to the home network or even the roaming = network could make sense but this would be delivered to everyone you = ever call. We been trying to move away from PII identifiers that are = delivered to everyone you communicate with.=20 From vkg@bell-labs.com Thu May 19 14:56:13 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E093BE06D3 for ; Thu, 19 May 2011 14:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGRzFHUnSmNI for ; Thu, 19 May 2011 14:56:12 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B5B5EE0699 for ; Thu, 19 May 2011 14:56:12 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p4JLuBhn012419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 May 2011 16:56:11 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4JLuB5Y011105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 May 2011 16:56:11 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4JLuBHK024248 for ; Thu, 19 May 2011 16:56:11 -0500 (CDT) Message-ID: <4DD591F6.7000009@bell-labs.com> Date: Thu, 19 May 2011 16:56:06 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: "dispatch@ietf.org" 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 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [dispatch] Prelude to a charter for SIP Load Balancing work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 21:56:14 -0000 Folks: As a prelude to putting together a charter for the SIP Load Balancing work, it would be great to get some input on the SIP Load Balancing problem statement that resulted from the side-meeting in Prague [1]. I suspect that a draft charter will be available by May 23 to hash out on the dispatch mailing list, but before Partha and I unilaterally put our thoughts into a charter, we will like to get some sense of the working group on the problem statement, especially considerations 3-4 from [1]. This is especially important to narrow down what will be considered in-scope and out-of-scope in the charter. If you can find some time to look at [1], please do so and post your thoughts. [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03615.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From R.Jesske@telekom.de Fri May 20 00:52:26 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5CFE06D7 for ; Fri, 20 May 2011 00:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX6uZDK7aIvt for ; Fri, 20 May 2011 00:52:25 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id BACEDE06C4 for ; Fri, 20 May 2011 00:52:24 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 May 2011 09:51:54 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 20 May 2011 09:51:54 +0200 From: To: , , Date: Fri, 20 May 2011 09:51:53 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwWKJwbcmYEObkQQ5W6HTv5NFV4awAlrINw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com> References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> <4DD51723.2040804@cisco.com> In-Reply-To: <4DD51723.2040804@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 07:52:26 -0000 Hi Paul, that was my understanding what Gonzalo proposed. He wanted to have it described as general approach. Without any restriction= to ISUP Causes to be future proof. I have this send around a couple weeks ago. Nobody answered and I was in as= sumption that everybody agreed on this. Therefore I asked again for the agreement on the change again and what grou= p name (DISPATCH? SIPCORE?) I should use for the next draft. I really don't care what way we go as long as we progress the draft properl= y and get the work done. I have 5 for progress with option 1 and one with don't care and you. How to proceed now? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Donnerstag, 19. Mai 2011 15:12 > An: dispatch@ietf.org > Betreff: Re: [dispatch] SIP responses carrying Q.850 cause > values in Reason header fields > > I am getting confused by all the options mentioned, to the > point that I > don't understand what is being proposed now. > > It *sounds* like you are proposing to allow *any* reason > (including sip > reason codes) in any response. I am concerned that that will cause > considerable confusion. > > I apologize if that is not what you are proposing. > > Thanks, > Paul > > On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: > > Dear all, > > So assuming that there was no comment people are happy with > the new rewording I would like to prepare a new draft. > > > > This would be Option 1: General wording to allow the Reason > header within responses without any restrictions (except 100 Trying). > > And nobody wanted to have Option 2: Wording as stated in > the current draft > > draft-jesske-dispatch-update3326-reason-responses-02 > > > > Agreed? Comments? > > > > Thank you and best Regards > > > > Roland > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Jesske, Roland > >> Gesendet: Donnerstag, 19. Mai 2011 09:50 > >> An: Jesske, Roland > >> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause > >> values in Reason header fields > >> > >> > >> > >> On May 13, 2011, at 3:18 AM, wrote: > >> > >> > >> Hi, > >> Since my answer it looks that people would be > >> OK with the change. > >> So if no body comments within the next few days > >> I would prepare a new draft. > >> > >> So due to Gonzalo's proposal I would rewrite > >> the paragraphs as shown below. > >> For comparison reasons I have added also the > >> text proposal of the current draft > >> (draft-jesske-dispatch-update3326-reason-responses-02). > >> Please indicate which text you would like to > >> see finally. New proposal or current proposal. > >> > >> > >> 3. RFC3326 1. Introduction > >> > >> Original Text: > >> > >> Initially, the Reason header field defined > >> here appears to be most > >> useful for BYE and CANCEL requests, but it > >> can appear in any request > >> within a dialog, in any CANCEL request and in > >> any response whose > >> status code explicitly allows the presence of > >> this header field. > >> > >> Note that the Reason header field is usually > >> not needed in responses > >> because the status code and the reason phrase > >> already provide > >> sufficient information. > >> > >> New Text(new proposal): > >> > >> Initially, the Reason header field defined > >> here appears to be most > >> useful for BYE and CANCEL requests, but it > >> can appear in any request > >> within a dialog, in any CANCEL request > >> independent of the protocol > >> value used and in any response except 100 trying. > >> > >> New Text (text stated in the current draft > >> draft-jesske-dispatch-update3326-reason-responses-02): > >> > >> Initially, the Reason header field defined > >> here appears to be most > >> useful for BYE and CANCEL requests, but it > >> can appear in any request > >> within a dialog, in any CANCEL request > >> independent of the protocol > >> value used and in any response except 100 > >> trying if it contains only > >> a Q.850 Cause Code. > >> > >> 4. RFC3326 2. The Reason Header Field > >> > >> Original Text > >> > >> The Reason header field MAY appear in any > >> request within a dialog, in > >> any CANCEL request and in any response whose > >> status code explicitly > >> allows the presence of this header field. > >> > >> > >> > >> > >> Jesske& Liess Expires October 2, > >> 2011 [Page 3] > >> > >> Internet-Draft Reason Header > >> March 2011 > >> > >> > >> New Text(new proposal): > >> > >> The Reason header field MAY appear > >> in any request within a dialog, in any CANCEL > >> request . The > >> appearance of the Reason header field is > >> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x > >> and 199 provisional responses [I-D.ietf-sipcore-199]. > >> > >> > >> New Text(text stated in the current draft > >> draft-jesske-dispatch-update3326-reason-responses-02): > >> > >> The Reason header field only containing a > >> Q.850 Cause Code MAY appear > >> in any request within a dialog, in any CANCEL > >> request . The > >> appearance of the Reason header field only > >> containing a Q.850 Cause > >> Code is applicable to final responses 3xx, > >> 4xx, 5xx and 6xx and 18x > >> and 199 provisional responses [I-D.ietf-sipcore-199]. > >> > >> The Reason header field containing any other > >> reason value MAY appear > >> in any request within a dialog, in any CANCEL > >> request and in any > >> response whose status code explicitly allows > >> the presence of this > >> header field. > >> > >> > >> > >> > >> Best Regards > >> > >> > >> Roland > >> > >> > >> Deutsche Telekom Netzproduktion GmbH > >> Fixed Mobile Engineering Deutschland > >> 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: mailto:r.jesske@telekom.de > >> http://www.telekom.de > >> > >> 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. > >> > >> > >> > >> > >> -----Urspr=FCngliche Nachricht----- > >> > >> > >> Von: dispatch-bounces@ietf.org > >> > >> > >> [mailto:dispatch-bounces@ietf.org] Im > >> Auftrag von Jesske, Roland > >> > >> > >> Gesendet: Mittwoch, 6. April 2011 11:24 > >> > >> > >> An: Gonzalo.Camarillo@ericsson.com; > >> dispatch@ietf.org > >> > >> > >> Betreff: Re: [dispatch] SIP responses > >> carrying Q.850 cause > >> > >> > >> values in Reason header fields > >> > >> > >> > >> Hi Gonzalo, > >> > >> > >> I'm OK with your proposal so I could > >> change it if people > >> > >> > >> would like it. > >> > >> > >> It makes it shorter. > >> > >> > >> The only I would propose to have in is > >> the explicit > >> > >> > >> mentioning of the Response values due > >> to the fact that a > >> > >> > >> 100OK or 200OK should not include a > >> Reason header with a > >> > >> > >> Q.850 Cause Value. > >> > >> > >> > >> Best Regards > >> > >> > >> Roland Jesske > >> > >> > >> > >> > >> > >> -----Urspr=FCngliche Nachricht----- > >> > >> > >> Von: dispatch-bounces@ietf.org > >> > >> > >> > >> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > >> > >> > >> Gesendet: Dienstag, 5. > April 2011 14:03 > >> > >> > >> An: DISPATCH > >> > >> > >> Betreff: [dispatch] SIP > >> responses carrying Q.850 cause values > >> > >> > >> in Reason header fields > >> > >> > >> > >> Hi, > >> > >> > >> > >> last week in the DISPATCH > >> session, there was consensus to allow SIP > >> > >> > >> responses to carry Reason > >> header fields with Q.850 cause > >> > >> > >> values. As I > >> > >> > >> said some time ago, I am > >> willing to AD sponsor this draft > >> > >> > >> if/when the > >> > >> > >> DISPATCH chairs confirm such > >> consensus on the list. > >> > >> > >> > >> In the mean time, I have some > >> comments on how to document > >> > >> > >> this decision. > >> > >> > >> The following (fairly short) > >> draft updates a couple of > >> > >> > >> paragraphs in RFC > >> > >> > >> 3326 in order to achieve the > >> desired outcome: > >> > >> > >> > >> > >> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > >> -responses-02.txt > >> > >> > >> > >> > >> I think this is not a > >> particularly elegant way to define > >> > >> > >> what we want. > >> > >> > >> For example, if we wanted to > >> define a solution to HERFP in > >> > >> > >> the future > >> > >> > >> based on the Reason header, we > >> would need to update those paragraphs > >> > >> > >> again, making them longer every > >> time we added a new use case. > >> > >> > >> > >> Instead, I would prefer to > >> explicitly define what we want > >> > >> > >> to do and be > >> > >> > >> done with it. Such a (also > >> fairly short) draft would say > >> > >> > >> something along > >> > >> > >> the following lines: > >> > >> > >> > >> "RFC 3326 allows the presence > >> of the Reason header field in > >> > >> > >> any response > >> > >> > >> whose status code explicitly > >> allows its presence. This document > >> > >> > >> explicitly allows any SIP > >> response to carry a Reason header > >> > >> > >> field with a > >> > >> > >> Q.850 cause value. SIP > >> responses with Reason header fields carrying > >> > >> > >> values other than Q.850 cause > >> values are outside of the > >> > >> > >> scope of this > >> > >> > >> document." > >> > >> > >> > >> I would like to know the > >> opinion of the WG on this matter > >> > >> > >> (i.e., how to > >> > >> > >> document the WG's consensus). > >> Note that reaching consensus was the > >> > >> > >> difficult part. Agreeing on how > >> to document it should be easy. > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Gonzalo > >> > >> > >> > >> > >> _______________________________________________ > >> > >> > >> dispatch mailing list > >> > >> > >> dispatch@ietf.org > >> > >> > >> > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> > >> > >> > _______________________________________________ > >> > >> > >> dispatch mailing list > >> > >> > >> dispatch@ietf.org > >> > >> > >> > https://www.ietf.org/mailman/listinfo/dispatch > >> > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> > >> > >> > > _______________________________________________ > > 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 christian.1.schmidt@nsn.com Fri May 20 01:32:33 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD46E0682 for ; Fri, 20 May 2011 01:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqq7uS9XXf1F for ; Fri, 20 May 2011 01:32:31 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11EE067C for ; Fri, 20 May 2011 01:32:29 -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 p4K8WQs8010109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 May 2011 10:32:26 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4K8WPFq028097; Fri, 20 May 2011 10:32:26 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 May 2011 10:32:25 +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, 20 May 2011 10:32:22 +0200 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhAAM748cA== References: <4D9B04E3.2090301@ericsson.com><580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 20 May 2011 08:32:25.0793 (UTC) FILETIME=[728BB310:01CC16C8] Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 08:32:33 -0000 Take option 1 Christian -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext R.Jesske@telekom.de Sent: Thursday, May 19, 2011 9:58 AM To: dispatch@ietf.org; Gonzalo.Camarillo@ericsson.com Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin = Reason header fields Dear all, So assuming that there was no comment people are happy with the new = rewording I would like to prepare a new draft. This would be Option 1: General wording to allow the Reason header = within responses without any restrictions (except 100 Trying). And nobody wanted to have Option 2: Wording as stated in the current = draft draft-jesske-dispatch-update3326-reason-responses-02 Agreed? Comments? Thank you and best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Jesske, Roland > Gesendet: Donnerstag, 19. Mai 2011 09:50 > An: Jesske, Roland > Betreff: AW: [dispatch] SIP responses carrying Q.850 cause > values in Reason header fields > > > > On May 13, 2011, at 3:18 AM, wrote: > > > Hi, > Since my answer it looks that people would be > OK with the change. > So if no body comments within the next few days > I would prepare a new draft. > > So due to Gonzalo's proposal I would rewrite > the paragraphs as shown below. > For comparison reasons I have added also the > text proposal of the current draft > (draft-jesske-dispatch-update3326-reason-responses-02). > Please indicate which text you would like to > see finally. New proposal or current proposal. > > > 3. RFC3326 1. Introduction > > Original Text: > > Initially, the Reason header field defined > here appears to be most > useful for BYE and CANCEL requests, but it > can appear in any request > within a dialog, in any CANCEL request and in > any response whose > status code explicitly allows the presence of > this header field. > > Note that the Reason header field is usually > not needed in responses > because the status code and the reason phrase > already provide > sufficient information. > > New Text(new proposal): > > Initially, the Reason header field defined > here appears to be most > useful for BYE and CANCEL requests, but it > can appear in any request > within a dialog, in any CANCEL request > independent of the protocol > value used and in any response except 100 trying. > > New Text (text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > Initially, the Reason header field defined > here appears to be most > useful for BYE and CANCEL requests, but it > can appear in any request > within a dialog, in any CANCEL request > independent of the protocol > value used and in any response except 100 > trying if it contains only > a Q.850 Cause Code. > > 4. RFC3326 2. The Reason Header Field > > Original Text > > The Reason header field MAY appear in any > request within a dialog, in > any CANCEL request and in any response whose > status code explicitly > allows the presence of this header field. > > > > > Jesske & Liess Expires October 2, > 2011 [Page 3] > > Internet-Draft Reason Header > March 2011 > > > New Text(new proposal): > > The Reason header field MAY appear > in any request within a dialog, in any CANCEL > request . The > appearance of the Reason header field is > applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > > New Text(text stated in the current draft > draft-jesske-dispatch-update3326-reason-responses-02): > > The Reason header field only containing a > Q.850 Cause Code MAY appear > in any request within a dialog, in any CANCEL > request . The > appearance of the Reason header field only > containing a Q.850 Cause > Code is applicable to final responses 3xx, > 4xx, 5xx and 6xx and 18x > and 199 provisional responses [I-D.ietf-sipcore-199]. > > The Reason header field containing any other > reason value MAY appear > in any request within a dialog, in any CANCEL > request and in any > response whose status code explicitly allows > the presence of this > header field. > > > > > Best Regards > > > Roland > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > 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: mailto:r.jesske@telekom.de > http://www.telekom.de > > 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. > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Jesske, Roland > > > Gesendet: Mittwoch, 6. April 2011 11:24 > > > An: Gonzalo.Camarillo@ericsson.com; > dispatch@ietf.org > > > Betreff: Re: [dispatch] SIP responses > carrying Q.850 cause > > > values in Reason header fields > > > > Hi Gonzalo, > > > I'm OK with your proposal so I could > change it if people > > > would like it. > > > It makes it shorter. > > > The only I would propose to have in is > the explicit > > > mentioning of the Response values due > to the fact that a > > > 100OK or 200OK should not include a > Reason header with a > > > Q.850 Cause Value. > > > > Best Regards > > > Roland Jesske > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > > > Gesendet: Dienstag, 5. April 2011 14:03 > > > An: DISPATCH > > > Betreff: [dispatch] SIP > responses carrying Q.850 cause values > > > in Reason header fields > > > > Hi, > > > > last week in the DISPATCH > session, there was consensus to allow SIP > > > responses to carry Reason > header fields with Q.850 cause > > > values. As I > > > said some time ago, I am > willing to AD sponsor this draft > > > if/when the > > > DISPATCH chairs confirm such > consensus on the list. > > > > In the mean time, I have some > comments on how to document > > > this decision. > > > The following (fairly short) > draft updates a couple of > > > paragraphs in RFC > > > 3326 in order to achieve the > desired outcome: > > > > > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > -responses-02.txt > > > > > I think this is not a > particularly elegant way to define > > > what we want. > > > For example, if we wanted to > define a solution to HERFP in > > > the future > > > based on the Reason header, we > would need to update those paragraphs > > > again, making them longer every > time we added a new use case. > > > > Instead, I would prefer to > explicitly define what we want > > > to do and be > > > done with it. Such a (also > fairly short) draft would say > > > something along > > > the following lines: > > > > "RFC 3326 allows the presence > of the Reason header field in > > > any response > > > whose status code explicitly > allows its presence. This document > > > explicitly allows any SIP > response to carry a Reason header > > > field with a > > > Q.850 cause value. SIP > responses with Reason header fields carrying > > > values other than Q.850 cause > values are outside of the > > > scope of this > > > document." > > > > I would like to know the > opinion of the WG on this matter > > > (i.e., how to > > > document the WG's consensus). > Note that reaching consensus was the > > > difficult part. Agreeing on how > to document it should be easy. > > > > Thanks, > > > > Gonzalo > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From marianne.mohali@orange-ftgroup.com Fri May 20 02:20:27 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7775E06F2 for ; Fri, 20 May 2011 02:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48iK+S4Vjc1V for ; Fri, 20 May 2011 02:20:27 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7141DE068C for ; Fri, 20 May 2011 02:20:25 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BCF65738004; Fri, 20 May 2011 11:21:39 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id ADA2C6F8002; Fri, 20 May 2011 11:21:39 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 May 2011 11:20:24 +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, 20 May 2011 11:20:22 +0200 Message-ID: In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields Thread-Index: AcwRb6qWCnpYkkfcRZ+/DXEXyYajFQEiY96gAAAIdhAANWUBcA== References: <4D9B04E3.2090301@ericsson.com><580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> From: To: , , X-OriginalArrivalTime: 20 May 2011 09:20:24.0596 (UTC) FILETIME=[26722D40:01CC16CF] Subject: Re: [dispatch] SIP responses carrying Q.850 cause valuesin Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 09:20:28 -0000 Option 1 is good ! Regards, Marianne=20 > -----Message d'origine----- > De : dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] De la part de R.Jesske@telekom.de > Envoy=E9 : jeudi 19 mai 2011 09:58 > =C0 : dispatch@ietf.org; Gonzalo.Camarillo@ericsson.com > Objet : Re: [dispatch] SIP responses carrying Q.850 cause=20 > valuesin Reason header fields >=20 > Dear all, > So assuming that there was no comment people are happy with=20 > the new rewording I would like to prepare a new draft. >=20 > This would be Option 1: General wording to allow the Reason=20 > header within responses without any restrictions (except 100 Trying). > And nobody wanted to have Option 2: Wording as stated in the=20 > current draft > draft-jesske-dispatch-update3326-reason-responses-02 >=20 > Agreed? Comments? >=20 > Thank you and best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jesske, Roland > > Gesendet: Donnerstag, 19. Mai 2011 09:50 > > An: Jesske, Roland > > Betreff: AW: [dispatch] SIP responses carrying Q.850 cause=20 > values in=20 > > Reason header fields > > > > > > > > On May 13, 2011, at 3:18 AM, wrote: > > > > > > Hi, > > Since my answer it looks that people would be OK with the change. > > So if no body comments within the next few days I would=20 > prepare a new=20 > > draft. > > > > So due to Gonzalo's proposal I would rewrite the paragraphs=20 > as shown=20 > > below. > > For comparison reasons I have added also the text proposal of the=20 > > current draft=20 > (draft-jesske-dispatch-update3326-reason-responses-02). > > Please indicate which text you would like to see finally.=20 > New proposal=20 > > or current proposal. > > > > > > 3. RFC3326 1. Introduction > > > > Original Text: > > > > Initially, the Reason header field defined here appears to be most > > useful for BYE and CANCEL requests, but it can appear in=20 > any request > > within a dialog, in any CANCEL request and in any response whose > > status code explicitly allows the presence of this header field. > > > > Note that the Reason header field is usually not needed=20 > in responses > > because the status code and the reason phrase already provide > > sufficient information. > > > > New Text(new proposal): > > > > Initially, the Reason header field defined here appears to be most > > useful for BYE and CANCEL requests, but it can appear in=20 > any request > > within a dialog, in any CANCEL request independent of the protocol > > value used and in any response except 100 trying. > > > > New Text (text stated in the current draft > > draft-jesske-dispatch-update3326-reason-responses-02): > > > > Initially, the Reason header field defined here appears to be most > > useful for BYE and CANCEL requests, but it can appear in=20 > any request =20 > > within a dialog, in any CANCEL request independent of the protocol > > value used and in any response except 100 trying if it=20 > contains only > > a Q.850 Cause Code. > > > > 4. RFC3326 2. The Reason Header Field > > > > Original Text > > > > The Reason header field MAY appear in any request within=20 > a dialog,=20 > > in > > any CANCEL request and in any response whose status code=20 > explicitly > > allows the presence of this header field. > > > > > > > > > > Jesske & Liess Expires October 2, > > 2011 [Page 3] > > > > Internet-Draft Reason Header > > March 2011 > > > > > > New Text(new proposal): > > > > The Reason header field MAY appear > > in any request within a dialog, in any CANCEL request . The > > appearance of the Reason header field is applicable to final=20 > > responses 3xx, 4xx, 5xx and 6xx and 18x > > and 199 provisional responses [I-D.ietf-sipcore-199]. > > > > > > New Text(text stated in the current draft > > draft-jesske-dispatch-update3326-reason-responses-02): > > > > The Reason header field only containing a Q.850 Cause Code MAY=20 > > appear > > in any request within a dialog, in any CANCEL request . The > > appearance of the Reason header field only containing a=20 > Q.850 Cause > > Code is applicable to final responses 3xx, 4xx, 5xx and=20 > 6xx and 18x > > and 199 provisional responses [I-D.ietf-sipcore-199]. > > > > The Reason header field containing any other reason value=20 > MAY appear > > in any request within a dialog, in any CANCEL request and in any > > response whose status code explicitly allows the presence of this > > header field. > > > > > > > > > > Best Regards > > > > > > Roland > > > > > > Deutsche Telekom Netzproduktion GmbH > > Fixed Mobile Engineering Deutschland > > 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: mailto:r.jesske@telekom.de > > http://www.telekom.de > > > > Erleben, was verbindet. > > > > Deutsche Telekom Netzproduktion GmbH > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), = Albert=20 > > Matheis, Klaus Peren > > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > Gesellschaft Bonn=20 > > USt-IdNr. DE 814645262 > > > > Gro=DFe Ver=E4nderungen fangen klein an - > > Ressourcen schonen und nicht jede E-Mail drucken. > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: dispatch-bounces@ietf.org > > > > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag=20 > > von Jesske, Roland > > > > > > Gesendet: Mittwoch, 6. April 2011 11:24 > > > > > > An: Gonzalo.Camarillo@ericsson.com;=20 > > dispatch@ietf.org > > > > > > Betreff: Re: [dispatch] SIP responses=20 > carrying=20 > > Q.850 cause > > > > > > values in Reason header fields > > > > > > > > Hi Gonzalo, > > > > > > I'm OK with your proposal so I could=20 > change it=20 > > if people > > > > > > would like it. > > > > > > It makes it shorter. > > > > > > The only I would propose to have in is the=20 > > explicit > > > > > > mentioning of the Response values due to the=20 > > fact that a > > > > > > 100OK or 200OK should not include a Reason=20 > > header with a > > > > > > Q.850 Cause Value. > > > > > > > > Best Regards > > > > > > Roland Jesske > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: dispatch-bounces@ietf.org > > > > > > > > [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo > > > > > > Gesendet: Dienstag, 5. April=20 > 2011 14:03 > > > > > > An: DISPATCH > > > > > > Betreff: [dispatch] SIP responses=20 > > carrying Q.850 cause values > > > > > > in Reason header fields > > > > > > > > Hi, > > > > > > > > last week in the DISPATCH=20 > session, there=20 > > was consensus to allow SIP > > > > > > responses to carry Reason=20 > header fields=20 > > with Q.850 cause > > > > > > values. As I > > > > > > said some time ago, I am=20 > willing to AD=20 > > sponsor this draft > > > > > > if/when the > > > > > > DISPATCH chairs confirm such=20 > consensus=20 > > on the list. > > > > > > > > In the mean time, I have some=20 > comments=20 > > on how to document > > > > > > this decision. > > > > > > The following (fairly short) draft=20 > > updates a couple of > > > > > > paragraphs in RFC > > > > > > 3326 in order to achieve the desired=20 > > outcome: > > > > > > > > > > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > > -responses-02.txt > > > > > > > > > > I think this is not a particularly=20 > > elegant way to define > > > > > > what we want. > > > > > > For example, if we wanted to define a=20 > > solution to HERFP in > > > > > > the future > > > > > > based on the Reason header, we would=20 > > need to update those paragraphs > > > > > > again, making them longer=20 > every time we=20 > > added a new use case. > > > > > > > > Instead, I would prefer to explicitly=20 > > define what we want > > > > > > to do and be > > > > > > done with it. Such a (also=20 > fairly short)=20 > > draft would say > > > > > > something along > > > > > > the following lines: > > > > > > > > "RFC 3326 allows the presence of the=20 > > Reason header field in > > > > > > any response > > > > > > whose status code explicitly=20 > allows its=20 > > presence. This document > > > > > > explicitly allows any SIP response to=20 > > carry a Reason header > > > > > > field with a > > > > > > Q.850 cause value. SIP responses with=20 > > Reason header fields carrying > > > > > > values other than Q.850 cause=20 > values are=20 > > outside of the > > > > > > scope of this > > > > > > document." > > > > > > > > I would like to know the=20 > opinion of the=20 > > WG on this matter > > > > > > (i.e., how to > > > > > > document the WG's consensus). > > Note that reaching consensus was the > > > > > > difficult part. Agreeing on how to=20 > > document it should be easy. > > > > > > > > Thanks, > > > > > > > > Gonzalo > > > > > > > > > > _______________________________________________ > > > > > > dispatch mailing list > > > > > > dispatch@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > =20 > _______________________________________________ > > > > > > dispatch mailing list > > > > > > dispatch@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Fri May 20 05:45:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08EE06FE for ; Fri, 20 May 2011 05:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.642 X-Spam-Level: X-Spam-Status: No, score=-109.642 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DouZURtt66SV for ; Fri, 20 May 2011 05:45:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7CEE06F7 for ; Fri, 20 May 2011 05:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=14082; q=dns/txt; s=iport; t=1305895530; x=1307105130; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sJ+Il86CmUf3XOneWNhUc2oXeXiybhaVOvpN5+bnPiQ=; b=cXt7R4lxfbdgajTjYDdeCTFNszyllplLI79Tiv9biIDmvINH8B0ztWos oSRLCiI/ZlcmQFZIjzGG278KtY198xhPChjgX6FzmYvpF3RJJgcepGoHL ajRCXvpKzqsVUYFeegdwWWZkH6BYxUNn0aWr6mexqSsayX69yAhMn0RfA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtADACZi1k2Q/khMgWdsb2JhbACmHBQBARYmJYhwnRSeCoYZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,242,1304294400"; d="scan'208";a="31357873" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 20 May 2011 12:45:28 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4KCjRJU026174; Fri, 20 May 2011 12:45:27 GMT Message-ID: <4DD66266.4080001@cisco.com> Date: Fri, 20 May 2011 08:45:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> <4DD51723.2040804@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch-chairs@tools.ietf.org, dispatch@ietf.org Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 12:45:32 -0000 On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: > Hi Paul, > that was my understanding what Gonzalo proposed. > He wanted to have it described as general approach. Without any restriction to ISUP Causes to be future proof. > > I have this send around a couple weeks ago. Nobody answered and I was in assumption that everybody agreed on this. > Therefore I asked again for the agreement on the change again and what group name (DISPATCH? SIPCORE?) I should use for the next draft. > > I really don't care what way we go as long as we progress the draft properly and get the work done. > > I have 5 for progress with option 1 and one with don't care and you. The concern is that that sip reason codes in sip responses are like having multiple responses to the same request. How should one behave? Fundamentally the problem isn't with the mechanics of delivering the reason - its with the semantics of what has been sent. This has the potential to lead to interoperation problems. We can let the chairs/ADs decide what to do. Thanks, Paul > How to proceed now? > > Best Regards > > Roland > > >> -----Ursprüngliche Nachricht----- >> Von: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Donnerstag, 19. Mai 2011 15:12 >> An: dispatch@ietf.org >> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause >> values in Reason header fields >> >> I am getting confused by all the options mentioned, to the >> point that I >> don't understand what is being proposed now. >> >> It *sounds* like you are proposing to allow *any* reason >> (including sip >> reason codes) in any response. I am concerned that that will cause >> considerable confusion. >> >> I apologize if that is not what you are proposing. >> >> Thanks, >> Paul >> >> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: >>> Dear all, >>> So assuming that there was no comment people are happy with >> the new rewording I would like to prepare a new draft. >>> >>> This would be Option 1: General wording to allow the Reason >> header within responses without any restrictions (except 100 Trying). >>> And nobody wanted to have Option 2: Wording as stated in >> the current draft >>> draft-jesske-dispatch-update3326-reason-responses-02 >>> >>> Agreed? Comments? >>> >>> Thank you and best Regards >>> >>> Roland >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Jesske, Roland >>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 >>>> An: Jesske, Roland >>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >>>> values in Reason header fields >>>> >>>> >>>> >>>> On May 13, 2011, at 3:18 AM, wrote: >>>> >>>> >>>> Hi, >>>> Since my answer it looks that people would be >>>> OK with the change. >>>> So if no body comments within the next few days >>>> I would prepare a new draft. >>>> >>>> So due to Gonzalo's proposal I would rewrite >>>> the paragraphs as shown below. >>>> For comparison reasons I have added also the >>>> text proposal of the current draft >>>> (draft-jesske-dispatch-update3326-reason-responses-02). >>>> Please indicate which text you would like to >>>> see finally. New proposal or current proposal. >>>> >>>> >>>> 3. RFC3326 1. Introduction >>>> >>>> Original Text: >>>> >>>> Initially, the Reason header field defined >>>> here appears to be most >>>> useful for BYE and CANCEL requests, but it >>>> can appear in any request >>>> within a dialog, in any CANCEL request and in >>>> any response whose >>>> status code explicitly allows the presence of >>>> this header field. >>>> >>>> Note that the Reason header field is usually >>>> not needed in responses >>>> because the status code and the reason phrase >>>> already provide >>>> sufficient information. >>>> >>>> New Text(new proposal): >>>> >>>> Initially, the Reason header field defined >>>> here appears to be most >>>> useful for BYE and CANCEL requests, but it >>>> can appear in any request >>>> within a dialog, in any CANCEL request >>>> independent of the protocol >>>> value used and in any response except 100 trying. >>>> >>>> New Text (text stated in the current draft >>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>> >>>> Initially, the Reason header field defined >>>> here appears to be most >>>> useful for BYE and CANCEL requests, but it >>>> can appear in any request >>>> within a dialog, in any CANCEL request >>>> independent of the protocol >>>> value used and in any response except 100 >>>> trying if it contains only >>>> a Q.850 Cause Code. >>>> >>>> 4. RFC3326 2. The Reason Header Field >>>> >>>> Original Text >>>> >>>> The Reason header field MAY appear in any >>>> request within a dialog, in >>>> any CANCEL request and in any response whose >>>> status code explicitly >>>> allows the presence of this header field. >>>> >>>> >>>> >>>> >>>> Jesske& Liess Expires October 2, >>>> 2011 [Page 3] >>>> >>>> Internet-Draft Reason Header >>>> March 2011 >>>> >>>> >>>> New Text(new proposal): >>>> >>>> The Reason header field MAY appear >>>> in any request within a dialog, in any CANCEL >>>> request . The >>>> appearance of the Reason header field is >>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>> >>>> >>>> New Text(text stated in the current draft >>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>> >>>> The Reason header field only containing a >>>> Q.850 Cause Code MAY appear >>>> in any request within a dialog, in any CANCEL >>>> request . The >>>> appearance of the Reason header field only >>>> containing a Q.850 Cause >>>> Code is applicable to final responses 3xx, >>>> 4xx, 5xx and 6xx and 18x >>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>> >>>> The Reason header field containing any other >>>> reason value MAY appear >>>> in any request within a dialog, in any CANCEL >>>> request and in any >>>> response whose status code explicitly allows >>>> the presence of this >>>> header field. >>>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> Roland >>>> >>>> >>>> Deutsche Telekom Netzproduktion GmbH >>>> Fixed Mobile Engineering Deutschland >>>> Roland Jesske >>>> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt >>>> +49 6151 628-2766 (Tel.) >>>> +49 521 9210-3753 (Fax) >>>> +49 171 8618-445 (Mobil) >>>> E-Mail: mailto:r.jesske@telekom.de >>>> http://www.telekom.de >>>> >>>> Erleben, was verbindet. >>>> >>>> Deutsche Telekom Netzproduktion GmbH >>>> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) >>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn >>>> (Vorsitzender), Albert Matheis, Klaus Peren >>>> Handelsregister: Amtsgericht Bonn HRB 14190 >>>> Sitz der Gesellschaft Bonn >>>> USt-IdNr. DE 814645262 >>>> >>>> Große Veränderungen fangen klein an - >>>> Ressourcen schonen und nicht jede E-Mail drucken. >>>> >>>> >>>> >>>> >>>> -----Ursprüngliche Nachricht----- >>>> >>>> >>>> Von: dispatch-bounces@ietf.org >>>> >>>> >>>> [mailto:dispatch-bounces@ietf.org] Im >>>> Auftrag von Jesske, Roland >>>> >>>> >>>> Gesendet: Mittwoch, 6. April 2011 11:24 >>>> >>>> >>>> An: Gonzalo.Camarillo@ericsson.com; >>>> dispatch@ietf.org >>>> >>>> >>>> Betreff: Re: [dispatch] SIP responses >>>> carrying Q.850 cause >>>> >>>> >>>> values in Reason header fields >>>> >>>> >>>> >>>> Hi Gonzalo, >>>> >>>> >>>> I'm OK with your proposal so I could >>>> change it if people >>>> >>>> >>>> would like it. >>>> >>>> >>>> It makes it shorter. >>>> >>>> >>>> The only I would propose to have in is >>>> the explicit >>>> >>>> >>>> mentioning of the Response values due >>>> to the fact that a >>>> >>>> >>>> 100OK or 200OK should not include a >>>> Reason header with a >>>> >>>> >>>> Q.850 Cause Value. >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> Roland Jesske >>>> >>>> >>>> >>>> >>>> >>>> -----Ursprüngliche Nachricht----- >>>> >>>> >>>> Von: dispatch-bounces@ietf.org >>>> >>>> >>>> >>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo >>>> >>>> >>>> Gesendet: Dienstag, 5. >> April 2011 14:03 >>>> >>>> >>>> An: DISPATCH >>>> >>>> >>>> Betreff: [dispatch] SIP >>>> responses carrying Q.850 cause values >>>> >>>> >>>> in Reason header fields >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> last week in the DISPATCH >>>> session, there was consensus to allow SIP >>>> >>>> >>>> responses to carry Reason >>>> header fields with Q.850 cause >>>> >>>> >>>> values. As I >>>> >>>> >>>> said some time ago, I am >>>> willing to AD sponsor this draft >>>> >>>> >>>> if/when the >>>> >>>> >>>> DISPATCH chairs confirm such >>>> consensus on the list. >>>> >>>> >>>> >>>> In the mean time, I have some >>>> comments on how to document >>>> >>>> >>>> this decision. >>>> >>>> >>>> The following (fairly short) >>>> draft updates a couple of >>>> >>>> >>>> paragraphs in RFC >>>> >>>> >>>> 3326 in order to achieve the >>>> desired outcome: >>>> >>>> >>>> >>>> >>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >>>> -responses-02.txt >>>> >>>> >>>> >>>> >>>> I think this is not a >>>> particularly elegant way to define >>>> >>>> >>>> what we want. >>>> >>>> >>>> For example, if we wanted to >>>> define a solution to HERFP in >>>> >>>> >>>> the future >>>> >>>> >>>> based on the Reason header, we >>>> would need to update those paragraphs >>>> >>>> >>>> again, making them longer every >>>> time we added a new use case. >>>> >>>> >>>> >>>> Instead, I would prefer to >>>> explicitly define what we want >>>> >>>> >>>> to do and be >>>> >>>> >>>> done with it. Such a (also >>>> fairly short) draft would say >>>> >>>> >>>> something along >>>> >>>> >>>> the following lines: >>>> >>>> >>>> >>>> "RFC 3326 allows the presence >>>> of the Reason header field in >>>> >>>> >>>> any response >>>> >>>> >>>> whose status code explicitly >>>> allows its presence. This document >>>> >>>> >>>> explicitly allows any SIP >>>> response to carry a Reason header >>>> >>>> >>>> field with a >>>> >>>> >>>> Q.850 cause value. SIP >>>> responses with Reason header fields carrying >>>> >>>> >>>> values other than Q.850 cause >>>> values are outside of the >>>> >>>> >>>> scope of this >>>> >>>> >>>> document." >>>> >>>> >>>> >>>> I would like to know the >>>> opinion of the WG on this matter >>>> >>>> >>>> (i.e., how to >>>> >>>> >>>> document the WG's consensus). >>>> Note that reaching consensus was the >>>> >>>> >>>> difficult part. Agreeing on how >>>> to document it should be easy. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Gonzalo >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> >>>> dispatch mailing list >>>> >>>> >>>> dispatch@ietf.org >>>> >>>> >>>> >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> >> _______________________________________________ >>>> >>>> >>>> dispatch mailing list >>>> >>>> >>>> dispatch@ietf.org >>>> >>>> >>>> >> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> 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 md3135@att.com Fri May 20 05:48:21 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E61EE06F7 for ; Fri, 20 May 2011 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFVTk0ThGy2w for ; Fri, 20 May 2011 05:48:19 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3837EE0695 for ; Fri, 20 May 2011 05:48:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1305895697!20056800!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2016 invoked from network); 20 May 2011 12:48:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2011 12:48:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4KClDug004070; Fri, 20 May 2011 08:47:13 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4KClAiZ004030; Fri, 20 May 2011 08:47:10 -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: Fri, 20 May 2011 08:48:12 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A120D03@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4DD66266.4080001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwW69J34/uEQfNiTdqz8GxcVyUomAAAC0Ww References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com><4DD51723.2040804@cisco.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com> <4DD66266.4080001@cisco.com> From: "DOLLY, MARTIN C (ATTSI)" To: "Paul Kyzivat" , Cc: dispatch-chairs@tools.ietf.org, dispatch@ietf.org Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 12:48:21 -0000 Paul, I do not understand your concern. Please give a REAL life example, not a = what if. Thank you, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat Sent: Friday, May 20, 2011 8:45 AM To: R.Jesske@telekom.de Cc: dispatch-chairs@tools.ietf.org; dispatch@ietf.org Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in = Reason header fields On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: > Hi Paul, > that was my understanding what Gonzalo proposed. > He wanted to have it described as general approach. Without any = restriction to ISUP Causes to be future proof. > > I have this send around a couple weeks ago. Nobody answered and I was = in assumption that everybody agreed on this. > Therefore I asked again for the agreement on the change again and what = group name (DISPATCH? SIPCORE?) I should use for the next draft. > > I really don't care what way we go as long as we progress the draft = properly and get the work done. > > I have 5 for progress with option 1 and one with don't care and you. The concern is that that sip reason codes in sip responses are like=20 having multiple responses to the same request. How should one behave? Fundamentally the problem isn't with the mechanics of delivering the=20 reason - its with the semantics of what has been sent. This has the=20 potential to lead to interoperation problems. We can let the chairs/ADs decide what to do. Thanks, Paul > How to proceed now? > > Best Regards > > Roland > > >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Donnerstag, 19. Mai 2011 15:12 >> An: dispatch@ietf.org >> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause >> values in Reason header fields >> >> I am getting confused by all the options mentioned, to the >> point that I >> don't understand what is being proposed now. >> >> It *sounds* like you are proposing to allow *any* reason >> (including sip >> reason codes) in any response. I am concerned that that will cause >> considerable confusion. >> >> I apologize if that is not what you are proposing. >> >> Thanks, >> Paul >> >> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: >>> Dear all, >>> So assuming that there was no comment people are happy with >> the new rewording I would like to prepare a new draft. >>> >>> This would be Option 1: General wording to allow the Reason >> header within responses without any restrictions (except 100 Trying). >>> And nobody wanted to have Option 2: Wording as stated in >> the current draft >>> draft-jesske-dispatch-update3326-reason-responses-02 >>> >>> Agreed? Comments? >>> >>> Thank you and best Regards >>> >>> Roland >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Jesske, Roland >>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 >>>> An: Jesske, Roland >>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >>>> values in Reason header fields >>>> >>>> >>>> >>>> On May 13, 2011, at 3:18 AM, wrote: >>>> >>>> >>>> Hi, >>>> Since my answer it looks that people would be >>>> OK with the change. >>>> So if no body comments within the next few days >>>> I would prepare a new draft. >>>> >>>> So due to Gonzalo's proposal I would rewrite >>>> the paragraphs as shown below. >>>> For comparison reasons I have added also the >>>> text proposal of the current draft >>>> (draft-jesske-dispatch-update3326-reason-responses-02). >>>> Please indicate which text you would like to >>>> see finally. New proposal or current proposal. >>>> >>>> >>>> 3. RFC3326 1. Introduction >>>> >>>> Original Text: >>>> >>>> Initially, the Reason header field defined >>>> here appears to be most >>>> useful for BYE and CANCEL requests, but it >>>> can appear in any request >>>> within a dialog, in any CANCEL request and in >>>> any response whose >>>> status code explicitly allows the presence of >>>> this header field. >>>> >>>> Note that the Reason header field is usually >>>> not needed in responses >>>> because the status code and the reason phrase >>>> already provide >>>> sufficient information. >>>> >>>> New Text(new proposal): >>>> >>>> Initially, the Reason header field defined >>>> here appears to be most >>>> useful for BYE and CANCEL requests, but it >>>> can appear in any request >>>> within a dialog, in any CANCEL request >>>> independent of the protocol >>>> value used and in any response except 100 trying. >>>> >>>> New Text (text stated in the current draft >>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>> >>>> Initially, the Reason header field defined >>>> here appears to be most >>>> useful for BYE and CANCEL requests, but it >>>> can appear in any request >>>> within a dialog, in any CANCEL request >>>> independent of the protocol >>>> value used and in any response except 100 >>>> trying if it contains only >>>> a Q.850 Cause Code. >>>> >>>> 4. RFC3326 2. The Reason Header Field >>>> >>>> Original Text >>>> >>>> The Reason header field MAY appear in any >>>> request within a dialog, in >>>> any CANCEL request and in any response whose >>>> status code explicitly >>>> allows the presence of this header field. >>>> >>>> >>>> >>>> >>>> Jesske& Liess Expires October 2, >>>> 2011 [Page 3] >>>> >>>> Internet-Draft Reason Header >>>> March 2011 >>>> >>>> >>>> New Text(new proposal): >>>> >>>> The Reason header field MAY appear >>>> in any request within a dialog, in any CANCEL >>>> request . The >>>> appearance of the Reason header field is >>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>> >>>> >>>> New Text(text stated in the current draft >>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>> >>>> The Reason header field only containing a >>>> Q.850 Cause Code MAY appear >>>> in any request within a dialog, in any CANCEL >>>> request . The >>>> appearance of the Reason header field only >>>> containing a Q.850 Cause >>>> Code is applicable to final responses 3xx, >>>> 4xx, 5xx and 6xx and 18x >>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>> >>>> The Reason header field containing any other >>>> reason value MAY appear >>>> in any request within a dialog, in any CANCEL >>>> request and in any >>>> response whose status code explicitly allows >>>> the presence of this >>>> header field. >>>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> Roland >>>> >>>> >>>> Deutsche Telekom Netzproduktion GmbH >>>> Fixed Mobile Engineering Deutschland >>>> 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: mailto:r.jesske@telekom.de >>>> http://www.telekom.de >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> -----Urspr=FCngliche Nachricht----- >>>> >>>> >>>> Von: dispatch-bounces@ietf.org >>>> >>>> >>>> [mailto:dispatch-bounces@ietf.org] Im >>>> Auftrag von Jesske, Roland >>>> >>>> >>>> Gesendet: Mittwoch, 6. April 2011 11:24 >>>> >>>> >>>> An: Gonzalo.Camarillo@ericsson.com; >>>> dispatch@ietf.org >>>> >>>> >>>> Betreff: Re: [dispatch] SIP responses >>>> carrying Q.850 cause >>>> >>>> >>>> values in Reason header fields >>>> >>>> >>>> >>>> Hi Gonzalo, >>>> >>>> >>>> I'm OK with your proposal so I could >>>> change it if people >>>> >>>> >>>> would like it. >>>> >>>> >>>> It makes it shorter. >>>> >>>> >>>> The only I would propose to have in is >>>> the explicit >>>> >>>> >>>> mentioning of the Response values due >>>> to the fact that a >>>> >>>> >>>> 100OK or 200OK should not include a >>>> Reason header with a >>>> >>>> >>>> Q.850 Cause Value. >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> Roland Jesske >>>> >>>> >>>> >>>> >>>> >>>> -----Urspr=FCngliche Nachricht----- >>>> >>>> >>>> Von: dispatch-bounces@ietf.org >>>> >>>> >>>> >>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo >>>> >>>> >>>> Gesendet: Dienstag, 5. >> April 2011 14:03 >>>> >>>> >>>> An: DISPATCH >>>> >>>> >>>> Betreff: [dispatch] SIP >>>> responses carrying Q.850 cause values >>>> >>>> >>>> in Reason header fields >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> last week in the DISPATCH >>>> session, there was consensus to allow SIP >>>> >>>> >>>> responses to carry Reason >>>> header fields with Q.850 cause >>>> >>>> >>>> values. As I >>>> >>>> >>>> said some time ago, I am >>>> willing to AD sponsor this draft >>>> >>>> >>>> if/when the >>>> >>>> >>>> DISPATCH chairs confirm such >>>> consensus on the list. >>>> >>>> >>>> >>>> In the mean time, I have some >>>> comments on how to document >>>> >>>> >>>> this decision. >>>> >>>> >>>> The following (fairly short) >>>> draft updates a couple of >>>> >>>> >>>> paragraphs in RFC >>>> >>>> >>>> 3326 in order to achieve the >>>> desired outcome: >>>> >>>> >>>> >>>> >>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >>>> -responses-02.txt >>>> >>>> >>>> >>>> >>>> I think this is not a >>>> particularly elegant way to define >>>> >>>> >>>> what we want. >>>> >>>> >>>> For example, if we wanted to >>>> define a solution to HERFP in >>>> >>>> >>>> the future >>>> >>>> >>>> based on the Reason header, we >>>> would need to update those paragraphs >>>> >>>> >>>> again, making them longer every >>>> time we added a new use case. >>>> >>>> >>>> >>>> Instead, I would prefer to >>>> explicitly define what we want >>>> >>>> >>>> to do and be >>>> >>>> >>>> done with it. Such a (also >>>> fairly short) draft would say >>>> >>>> >>>> something along >>>> >>>> >>>> the following lines: >>>> >>>> >>>> >>>> "RFC 3326 allows the presence >>>> of the Reason header field in >>>> >>>> >>>> any response >>>> >>>> >>>> whose status code explicitly >>>> allows its presence. This document >>>> >>>> >>>> explicitly allows any SIP >>>> response to carry a Reason header >>>> >>>> >>>> field with a >>>> >>>> >>>> Q.850 cause value. SIP >>>> responses with Reason header fields carrying >>>> >>>> >>>> values other than Q.850 cause >>>> values are outside of the >>>> >>>> >>>> scope of this >>>> >>>> >>>> document." >>>> >>>> >>>> >>>> I would like to know the >>>> opinion of the WG on this matter >>>> >>>> >>>> (i.e., how to >>>> >>>> >>>> document the WG's consensus). >>>> Note that reaching consensus was the >>>> >>>> >>>> difficult part. Agreeing on how >>>> to document it should be easy. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Gonzalo >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> >>>> dispatch mailing list >>>> >>>> >>>> dispatch@ietf.org >>>> >>>> >>>> >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> >> _______________________________________________ >>>> >>>> >>>> dispatch mailing list >>>> >>>> >>>> dispatch@ietf.org >>>> >>>> >>>> >> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Fri May 20 06:04:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657B0E0684 for ; Fri, 20 May 2011 06:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.631 X-Spam-Level: X-Spam-Status: No, score=-109.631 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtuREMcyuwzL for ; Fri, 20 May 2011 06:04:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 11590E0657 for ; Fri, 20 May 2011 06:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=16143; q=dns/txt; s=iport; t=1305896671; x=1307106271; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sxjy90ny3jMU6Jif3TDIrzHz5MkHvrir8cC6T7Zjo/U=; b=ThIcSWxWsa8vFtGpjRRbvOtIO5AXhP9BeT1nKZPlVTxfHsqqwsUA9mND Ukn7hoQISFc2bOa1K2SrLa6Rpfb7m7tUCGIM3L8JK6Ow4MHyQlwPVNfgi Db1BRhvLKj4iZQpvVaGunKXGUbFKLWnvdjlXZUjc3fEbnKqUwsejRZB7z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhABAK5l1k2tJV2Z/2dsb2JhbACXXo4+d4hwnGmeC4MugmsEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,242,1304294400"; d="scan'208";a="700790380" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 20 May 2011 13:04:30 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4KD4TMm014346; Fri, 20 May 2011 13:04:29 GMT Message-ID: <4DD666DD.5010701@cisco.com> Date: Fri, 20 May 2011 09:04:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTSI)" References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com><4DD51723.2040804@cisco.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com> <4DD66266.4080001@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA0A120D03@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A120D03@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch-chairs@tools.ietf.org, dispatch@ietf.org Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 13:04:32 -0000 On 5/20/2011 8:48 AM, DOLLY, MARTIN C (ATTSI) wrote: > Paul, > > I do not understand your concern. Please give a REAL life example, not a what if. To start with, I am having difficulty understanding a use case for when you would *want* to send a sip reason code in a sip response. The motivation for the Reason header in the first place was to explain why a particular *request* was being sent. The justification for Q.850 reasons in *responses* is because the sip response codes don't carry all the nuances that the Q.850 codes do. Suppose I get SIP 486 response with a sip 503 reason code, or a sip 503 response code with a sip 486 reason code. What am I supposed to do with that? What does it *mean*? Thanks, Paul > Thank you, > > Martin Dolly > Lead Member Technical Staff > Core& Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 > > > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, May 20, 2011 8:45 AM > To: R.Jesske@telekom.de > Cc: dispatch-chairs@tools.ietf.org; dispatch@ietf.org > Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields > > > > On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: >> Hi Paul, >> that was my understanding what Gonzalo proposed. >> He wanted to have it described as general approach. Without any restriction to ISUP Causes to be future proof. >> >> I have this send around a couple weeks ago. Nobody answered and I was in assumption that everybody agreed on this. >> Therefore I asked again for the agreement on the change again and what group name (DISPATCH? SIPCORE?) I should use for the next draft. >> >> I really don't care what way we go as long as we progress the draft properly and get the work done. >> >> I have 5 for progress with option 1 and one with don't care and you. > > The concern is that that sip reason codes in sip responses are like > having multiple responses to the same request. How should one behave? > > Fundamentally the problem isn't with the mechanics of delivering the > reason - its with the semantics of what has been sent. This has the > potential to lead to interoperation problems. > > We can let the chairs/ADs decide what to do. > > Thanks, > Paul > >> How to proceed now? >> >> Best Regards >> >> Roland >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>> Gesendet: Donnerstag, 19. Mai 2011 15:12 >>> An: dispatch@ietf.org >>> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause >>> values in Reason header fields >>> >>> I am getting confused by all the options mentioned, to the >>> point that I >>> don't understand what is being proposed now. >>> >>> It *sounds* like you are proposing to allow *any* reason >>> (including sip >>> reason codes) in any response. I am concerned that that will cause >>> considerable confusion. >>> >>> I apologize if that is not what you are proposing. >>> >>> Thanks, >>> Paul >>> >>> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: >>>> Dear all, >>>> So assuming that there was no comment people are happy with >>> the new rewording I would like to prepare a new draft. >>>> >>>> This would be Option 1: General wording to allow the Reason >>> header within responses without any restrictions (except 100 Trying). >>>> And nobody wanted to have Option 2: Wording as stated in >>> the current draft >>>> draft-jesske-dispatch-update3326-reason-responses-02 >>>> >>>> Agreed? Comments? >>>> >>>> Thank you and best Regards >>>> >>>> Roland >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Jesske, Roland >>>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 >>>>> An: Jesske, Roland >>>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >>>>> values in Reason header fields >>>>> >>>>> >>>>> >>>>> On May 13, 2011, at 3:18 AM, wrote: >>>>> >>>>> >>>>> Hi, >>>>> Since my answer it looks that people would be >>>>> OK with the change. >>>>> So if no body comments within the next few days >>>>> I would prepare a new draft. >>>>> >>>>> So due to Gonzalo's proposal I would rewrite >>>>> the paragraphs as shown below. >>>>> For comparison reasons I have added also the >>>>> text proposal of the current draft >>>>> (draft-jesske-dispatch-update3326-reason-responses-02). >>>>> Please indicate which text you would like to >>>>> see finally. New proposal or current proposal. >>>>> >>>>> >>>>> 3. RFC3326 1. Introduction >>>>> >>>>> Original Text: >>>>> >>>>> Initially, the Reason header field defined >>>>> here appears to be most >>>>> useful for BYE and CANCEL requests, but it >>>>> can appear in any request >>>>> within a dialog, in any CANCEL request and in >>>>> any response whose >>>>> status code explicitly allows the presence of >>>>> this header field. >>>>> >>>>> Note that the Reason header field is usually >>>>> not needed in responses >>>>> because the status code and the reason phrase >>>>> already provide >>>>> sufficient information. >>>>> >>>>> New Text(new proposal): >>>>> >>>>> Initially, the Reason header field defined >>>>> here appears to be most >>>>> useful for BYE and CANCEL requests, but it >>>>> can appear in any request >>>>> within a dialog, in any CANCEL request >>>>> independent of the protocol >>>>> value used and in any response except 100 trying. >>>>> >>>>> New Text (text stated in the current draft >>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>> >>>>> Initially, the Reason header field defined >>>>> here appears to be most >>>>> useful for BYE and CANCEL requests, but it >>>>> can appear in any request >>>>> within a dialog, in any CANCEL request >>>>> independent of the protocol >>>>> value used and in any response except 100 >>>>> trying if it contains only >>>>> a Q.850 Cause Code. >>>>> >>>>> 4. RFC3326 2. The Reason Header Field >>>>> >>>>> Original Text >>>>> >>>>> The Reason header field MAY appear in any >>>>> request within a dialog, in >>>>> any CANCEL request and in any response whose >>>>> status code explicitly >>>>> allows the presence of this header field. >>>>> >>>>> >>>>> >>>>> >>>>> Jesske& Liess Expires October 2, >>>>> 2011 [Page 3] >>>>> >>>>> Internet-Draft Reason Header >>>>> March 2011 >>>>> >>>>> >>>>> New Text(new proposal): >>>>> >>>>> The Reason header field MAY appear >>>>> in any request within a dialog, in any CANCEL >>>>> request . The >>>>> appearance of the Reason header field is >>>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>> >>>>> >>>>> New Text(text stated in the current draft >>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>> >>>>> The Reason header field only containing a >>>>> Q.850 Cause Code MAY appear >>>>> in any request within a dialog, in any CANCEL >>>>> request . The >>>>> appearance of the Reason header field only >>>>> containing a Q.850 Cause >>>>> Code is applicable to final responses 3xx, >>>>> 4xx, 5xx and 6xx and 18x >>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>> >>>>> The Reason header field containing any other >>>>> reason value MAY appear >>>>> in any request within a dialog, in any CANCEL >>>>> request and in any >>>>> response whose status code explicitly allows >>>>> the presence of this >>>>> header field. >>>>> >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> >>>>> Roland >>>>> >>>>> >>>>> Deutsche Telekom Netzproduktion GmbH >>>>> Fixed Mobile Engineering Deutschland >>>>> Roland Jesske >>>>> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt >>>>> +49 6151 628-2766 (Tel.) >>>>> +49 521 9210-3753 (Fax) >>>>> +49 171 8618-445 (Mobil) >>>>> E-Mail: mailto:r.jesske@telekom.de >>>>> http://www.telekom.de >>>>> >>>>> Erleben, was verbindet. >>>>> >>>>> Deutsche Telekom Netzproduktion GmbH >>>>> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) >>>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn >>>>> (Vorsitzender), Albert Matheis, Klaus Peren >>>>> Handelsregister: Amtsgericht Bonn HRB 14190 >>>>> Sitz der Gesellschaft Bonn >>>>> USt-IdNr. DE 814645262 >>>>> >>>>> Große Veränderungen fangen klein an - >>>>> Ressourcen schonen und nicht jede E-Mail drucken. >>>>> >>>>> >>>>> >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> >>>>> >>>>> Von: dispatch-bounces@ietf.org >>>>> >>>>> >>>>> [mailto:dispatch-bounces@ietf.org] Im >>>>> Auftrag von Jesske, Roland >>>>> >>>>> >>>>> Gesendet: Mittwoch, 6. April 2011 11:24 >>>>> >>>>> >>>>> An: Gonzalo.Camarillo@ericsson.com; >>>>> dispatch@ietf.org >>>>> >>>>> >>>>> Betreff: Re: [dispatch] SIP responses >>>>> carrying Q.850 cause >>>>> >>>>> >>>>> values in Reason header fields >>>>> >>>>> >>>>> >>>>> Hi Gonzalo, >>>>> >>>>> >>>>> I'm OK with your proposal so I could >>>>> change it if people >>>>> >>>>> >>>>> would like it. >>>>> >>>>> >>>>> It makes it shorter. >>>>> >>>>> >>>>> The only I would propose to have in is >>>>> the explicit >>>>> >>>>> >>>>> mentioning of the Response values due >>>>> to the fact that a >>>>> >>>>> >>>>> 100OK or 200OK should not include a >>>>> Reason header with a >>>>> >>>>> >>>>> Q.850 Cause Value. >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> >>>>> Roland Jesske >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> >>>>> >>>>> Von: dispatch-bounces@ietf.org >>>>> >>>>> >>>>> >>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo >>>>> >>>>> >>>>> Gesendet: Dienstag, 5. >>> April 2011 14:03 >>>>> >>>>> >>>>> An: DISPATCH >>>>> >>>>> >>>>> Betreff: [dispatch] SIP >>>>> responses carrying Q.850 cause values >>>>> >>>>> >>>>> in Reason header fields >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> last week in the DISPATCH >>>>> session, there was consensus to allow SIP >>>>> >>>>> >>>>> responses to carry Reason >>>>> header fields with Q.850 cause >>>>> >>>>> >>>>> values. As I >>>>> >>>>> >>>>> said some time ago, I am >>>>> willing to AD sponsor this draft >>>>> >>>>> >>>>> if/when the >>>>> >>>>> >>>>> DISPATCH chairs confirm such >>>>> consensus on the list. >>>>> >>>>> >>>>> >>>>> In the mean time, I have some >>>>> comments on how to document >>>>> >>>>> >>>>> this decision. >>>>> >>>>> >>>>> The following (fairly short) >>>>> draft updates a couple of >>>>> >>>>> >>>>> paragraphs in RFC >>>>> >>>>> >>>>> 3326 in order to achieve the >>>>> desired outcome: >>>>> >>>>> >>>>> >>>>> >>>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >>>>> -responses-02.txt >>>>> >>>>> >>>>> >>>>> >>>>> I think this is not a >>>>> particularly elegant way to define >>>>> >>>>> >>>>> what we want. >>>>> >>>>> >>>>> For example, if we wanted to >>>>> define a solution to HERFP in >>>>> >>>>> >>>>> the future >>>>> >>>>> >>>>> based on the Reason header, we >>>>> would need to update those paragraphs >>>>> >>>>> >>>>> again, making them longer every >>>>> time we added a new use case. >>>>> >>>>> >>>>> >>>>> Instead, I would prefer to >>>>> explicitly define what we want >>>>> >>>>> >>>>> to do and be >>>>> >>>>> >>>>> done with it. Such a (also >>>>> fairly short) draft would say >>>>> >>>>> >>>>> something along >>>>> >>>>> >>>>> the following lines: >>>>> >>>>> >>>>> >>>>> "RFC 3326 allows the presence >>>>> of the Reason header field in >>>>> >>>>> >>>>> any response >>>>> >>>>> >>>>> whose status code explicitly >>>>> allows its presence. This document >>>>> >>>>> >>>>> explicitly allows any SIP >>>>> response to carry a Reason header >>>>> >>>>> >>>>> field with a >>>>> >>>>> >>>>> Q.850 cause value. SIP >>>>> responses with Reason header fields carrying >>>>> >>>>> >>>>> values other than Q.850 cause >>>>> values are outside of the >>>>> >>>>> >>>>> scope of this >>>>> >>>>> >>>>> document." >>>>> >>>>> >>>>> >>>>> I would like to know the >>>>> opinion of the WG on this matter >>>>> >>>>> >>>>> (i.e., how to >>>>> >>>>> >>>>> document the WG's consensus). >>>>> Note that reaching consensus was the >>>>> >>>>> >>>>> difficult part. Agreeing on how >>>>> to document it should be easy. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> Gonzalo >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> >>>>> dispatch mailing list >>>>> >>>>> >>>>> dispatch@ietf.org >>>>> >>>>> >>>>> >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> >>>>> >>>>> >>> _______________________________________________ >>>>> >>>>> >>>>> dispatch mailing list >>>>> >>>>> >>>>> dispatch@ietf.org >>>>> >>>>> >>>>> >>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 dworley@avaya.com Fri May 20 08:02:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A75E069B for ; Fri, 20 May 2011 08:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNW2j9MtH3S5 for ; Fri, 20 May 2011 08:01:59 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 88529E064E for ; Fri, 20 May 2011 08:01:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIqB1k3GmAcF/2dsb2JhbACmGninRwKbQIYZBJRdikU X-IronPort-AV: E=Sophos;i="4.65,242,1304308800"; d="scan'208";a="189320528" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 May 2011 11:01:57 -0400 X-IronPort-AV: E=Sophos;i="4.65,242,1304308800"; d="scan'208";a="624432325" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 May 2011 11:01:57 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 20 May 2011 11:01:56 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "R.Jesske@telekom.de" Date: Fri, 20 May 2011 10:59:32 -0400 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwW69mo+oXuCdZRTPCrLwU4qgIoPwAEqz+H Message-ID: References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com> <4DD51723.2040804@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com>, <4DD66266.4080001@cisco.com> In-Reply-To: <4DD66266.4080001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 15:02:00 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] The concern is that that sip reason codes in sip responses are like having multiple responses to the same request. How should one behave? Fundamentally the problem isn't with the mechanics of delivering the reason - its with the semantics of what has been sent. This has the potential to lead to interoperation problems. _______________________________________________ My memory is that in Prage there was general agreement that in a Reason hea= der in a SIP response, there should be no reason-value (clause) with protocol "SIP". That avoids = the Reason header giving one SIP response code while the containing response gives another SI= P response code. Dale From christer.holmberg@ericsson.com Fri May 20 13:00:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F65E07DB for ; Fri, 20 May 2011 13:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl+nl64VWUEe for ; Fri, 20 May 2011 13:00:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B1969E07D5 for ; Fri, 20 May 2011 13:00:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-cf-4dd6c8732a54 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.6B.09774.378C6DD4; Fri, 20 May 2011 22:00:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 20 May 2011 22:00:51 +0200 From: Christer Holmberg To: "Worley, Dale R (Dale)" , Paul Kyzivat , "R.Jesske@telekom.de" Date: Fri, 20 May 2011 21:59:05 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AQHMFyiekRe9l3DTvkSFuVzUiPR0rQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3B2@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 20:00:54 -0000 Hi, >>The concern is that that sip reason codes in sip responses are like >>having multiple responses to the same request. How should one behave? >> >>Fundamentally the problem isn't with the mechanics of delivering the >>reason - its with the semantics of what has been sent. This has the >>potential to lead to interoperation problems. > >My memory is that in Prage there was general agreement that in a Reason he= ader in a SIP response, >there should be no reason-value (clause) with protocol "SIP". That avoids= the Reason header >giving one SIP response code while the containing response gives another S= IP response code. ...with the exception being the case when a forking proxy generates a 199 r= esponse, when it MUST insert a Reason header field with the SIP response co= de that triggered the 199 response. Regards, Christer= From pkyzivat@cisco.com Fri May 20 13:21:21 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A83E07F1 for ; Fri, 20 May 2011 13:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.221 X-Spam-Level: X-Spam-Status: No, score=-110.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUwr5N-4S-lk for ; Fri, 20 May 2011 13:21:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 102A8E0742 for ; Fri, 20 May 2011 13:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1256; q=dns/txt; s=iport; t=1305922881; x=1307132481; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+BbhYPz9O4D5njbmjHLGo6a+fbxU8qKmOkC0sSA7XAA=; b=IY56aWFszXgbauy+Co56UCZOHV7Xaql78QSolt2q9n4Fc5FgwCD6Yj6M 95q4TrkCymWdQjxRu1qJjI5OoQH1BHxv/t0/JHMFKw2OaYpxpcR/saWOB z3J3p4A/VhUeDV8qd68rToYaHZXdz6HtAVO4SQz1b115qZq/K64DB7RFp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMXM1k2rRDoI/2dsb2JhbACmH3ikeZ1xhhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,243,1304294400"; d="scan'208";a="701033060" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 20 May 2011 20:21:20 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4KKLKRK002113; Fri, 20 May 2011 20:21:20 GMT Message-ID: <4DD6CD3F.4000007@cisco.com> Date: Fri, 20 May 2011 16:21:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3B2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3B2@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 20:21:22 -0000 OK, its coming back to me now. The idea was that the rule about reason codes in responses would be relaxed for Q.850 codes only, not for sip codes. Then 199 is *defined* as a case when sip response codes are allowed - but its not generalized to allowing sip response codes in *other* responses. Thanks, Paul On 5/20/2011 3:59 PM, Christer Holmberg wrote: > Hi, > >>> The concern is that that sip reason codes in sip responses are like >>> having multiple responses to the same request. How should one behave? >>> >>> Fundamentally the problem isn't with the mechanics of delivering the >>> reason - its with the semantics of what has been sent. This has the >>> potential to lead to interoperation problems. >> >> My memory is that in Prage there was general agreement that in a Reason header in a SIP response, >> there should be no reason-value (clause) with protocol "SIP". That avoids the Reason header >> giving one SIP response code while the containing response gives another SIP response code. > > ...with the exception being the case when a forking proxy generates a 199 response, when it MUST insert a Reason header field with the SIP response code that triggered the 199 response. > > Regards, > > Christer From christer.holmberg@ericsson.com Fri May 20 13:30:33 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF43E0762 for ; Fri, 20 May 2011 13:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU2pe1XnBOhe for ; Fri, 20 May 2011 13:30:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BF1FDE0715 for ; Fri, 20 May 2011 13:30:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ca-4dd6cf67ff31 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 85.AE.20773.76FC6DD4; Fri, 20 May 2011 22:30:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 20 May 2011 22:30:31 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Date: Fri, 20 May 2011 22:30:30 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwXK30yjpAkjDv1TrSYT1w3hRmdIAAAOrUg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3B2@ESESSCMS0356.eemea.ericsson.se> <4DD6CD3F.4000007@cisco.com> In-Reply-To: <4DD6CD3F.4000007@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-Brightmail-Tracker: AAAAAA== Cc: "dispatch-chairs@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 20:30:33 -0000 Hi,=20 >OK, its coming back to me now. > >The idea was that the rule about reason codes in responses would be relaxe= d for Q.850 codes only, not for sip codes. Then 199 is *defined* as a case = when sip response codes are allowed - but its not=20 >generalized to allowing sip response codes in *other* responses. Couldn't we then simply say that sip response codes in Reason headers of SI= P responses is only allowed in cases when explicitly defined for the the re= sponse code of the SIP response? Regards, Christer On 5/20/2011 3:59 PM, Christer Holmberg wrote: > Hi, > >>> The concern is that that sip reason codes in sip responses are like=20 >>> having multiple responses to the same request. How should one behave? >>> >>> Fundamentally the problem isn't with the mechanics of delivering the=20 >>> reason - its with the semantics of what has been sent. This has the=20 >>> potential to lead to interoperation problems. >> >> My memory is that in Prage there was general agreement that in a=20 >> Reason header in a SIP response, there should be no reason-value=20 >> (clause) with protocol "SIP". That avoids the Reason header giving one = SIP response code while the containing response gives another SIP response = code. > > ...with the exception being the case when a forking proxy generates a 199= response, when it MUST insert a Reason header field with the SIP response = code that triggered the 199 response. > > Regards, > > Christer From dworley@avaya.com Fri May 20 14:29:50 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3887E06CD for ; Fri, 20 May 2011 14:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.016 X-Spam-Level: X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrBF8GxHNMnk for ; Fri, 20 May 2011 14:29:49 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5BE06AD for ; Fri, 20 May 2011 14:29:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfc1k3GmAcF/2dsb2JhbACmIHiIcJ5eApsxhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,243,1304308800"; d="scan'208";a="189381265" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 May 2011 17:29:38 -0400 X-IronPort-AV: E=Sophos;i="4.65,243,1304308800"; d="scan'208";a="624591609" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 May 2011 17:29:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 20 May 2011 17:29:38 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg , 'Paul Kyzivat' Date: Fri, 20 May 2011 17:27:46 -0400 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwXK30yjpAkjDv1TrSYT1w3hRmdIAAAOrUgAAIWyCI= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3B2@ESESSCMS0356.eemea.ericsson.se> <4DD6CD3F.4000007@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C84E@ESESSCMS0356.eemea.ericsson.se> 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] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 21:29:50 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > >The idea was that the rule about reason codes in responses would be > >relaxed for Q.850 codes only, not for sip codes. Then 199 is > >*defined* as a case when sip response codes are allowed - but its > >not generalized to allowing sip response codes in *other* responses. >=20 > Couldn't we then simply say that sip response codes in Reason > headers of SIP responses is only allowed in cases when explicitly > defined for the the response code of the SIP response? That would work. (The goal being that any additional "protocol" values would be handled like "Q.850" rather than like "SIP".) Dale From pkyzivat@cisco.com Fri May 20 16:34:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44715E0772 for ; Fri, 20 May 2011 16:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.236 X-Spam-Level: X-Spam-Status: No, score=-110.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf2tGwrHUA2A for ; Fri, 20 May 2011 16:34:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7B268E0699 for ; Fri, 20 May 2011 16:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4111; q=dns/txt; s=iport; t=1305934461; x=1307144061; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=v2sx2Wh4EoC/f62kAGsdE5I5XXkvCHu26BJ3WZP1zSQ=; b=XsrR7rBFxCjpMx5YA7740V0A8iEkUzijf5J/tIhN3rwdwNqgwtHslVhN IkfImO1lCS6/6f5Fhao00uyT+SV0qn2wfHsoIPQXOfTr+SmZODf8NvhpP WAPUjBvhJjL9wK0MkiGEoC87g2OXBLw1bKqjeMs9Uq2w+IBcxaa/fPwhM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEb61k2tJV2Z/2dsb2JhbACmIHilH51yhhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,244,1304294400"; d="scan'208";a="320410208" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 20 May 2011 23:34:12 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4KNYBkU002031 for ; Fri, 20 May 2011 23:34:12 GMT Message-ID: <4DD6FA73.8090202@cisco.com> Date: Fri, 20 May 2011 19:34:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] New Version Notification fordraft-mohali-dispatch-reason-for-applications-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 23:34:22 -0000 marianne, I continue to be troubled by this draft. I'll try to explain: IIUC, these reasons are important to resolving "feature interaction" problems in systems you are involved with. Hence, I presume its important that the reasons be used "properly". But I have very little idea what most of these applications are, so I don't see how I figure out to use them properly. For instance, suppose I've implemented a sip "pbx" system that connects to the orange network via Martini. If I decide (somehow) that one of these codes applies to something I'm doing, is is ok for me to return the cause code? (E.g. I can certainly see my pbx implementing Voice Activated Dialing.) I'm guessing the answer will be that this is all filtered out at the boundary to your network - that you would not honor any such reason code coming from in over the martini connection. (Did I guess right?) Or perhaps you would permit it for certain systems that are certified as complying to your requirements, or maybe that are operated by you. What I'm getting at is that the definitions of these "applications" in this document is probably not a complete definition - that in reality it will be some 3GPP/IMS definition that matters. If that is so, then this document *at least* needs a scope of applicability statement that it is intended only for IMS networks (or whatever the scope is.) Perhaps I'm wrong. Perhaps its ok for any UA/proxy to decide when its appropriate to signal one of these based on the meager definitions in this document. If so, please tell me. As a minor note, regarding the example in 3.1: I fail to understand what added value the application reason code provides over the sip 402 reason code. The sip code seems *more* precise. Is it that you put more credence in the 402 code if you believe it came from the "prepaid" application that you otherwise would? Thanks, Paul On 5/19/2011 1:01 PM, marianne.mohali@orange-ftgroup.com wrote: > Hello, > > Here is a new version of the draft previously discussed in SIPCORE WG and quickly presented at the last DISPATCH meeting by Mary. > http://www.ietf.org/id/draft-mohali-dispatch-reason-for-applications-00.txt > > The draft proposes to extend the Reason header, allowing proxies to indicate an application-specific reason in the SIP message. > > We think that it would be usefull to have this kind of application-specific reasons especially in the History-Info header when a call has been retargeted by an Application. > > We would like to get some feedback on the proposed I-D and a confirmation of interest from the IETF community (DISPATCH). > > > Best Regards, > > Marianne Mohali > > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Envoyé : jeudi 19 mai 2011 18:43 > À : MOHALI Marianne RD-CORE-ISS > Cc : CHATRAS Bruno RD-CORE-ISS; MOHALI Marianne RD-CORE-ISS > Objet : New Version Notification fordraft-mohali-dispatch-reason-for-applications-00.txt > > A new version of I-D, draft-mohali-dispatch-reason-for-applications-00.txt has been successfully submitted by Marianne Mohali and posted to the IETF repository. > > Filename: draft-mohali-dispatch-reason-for-applications > Revision: 00 > Title: Extending the Session Initiation Protocol (SIP) Reason Header for Applications > Creation date: 2011-05-19 > WG ID: Individual Submission > Number of pages: 11 > > Abstract: > This document defines a new protocol value"Application" for the > Reason Header field and a new IANA Registry for registering > application types. This new value enables signaling that a request > or response has been issued as a result of a decision made by a > particular type of application or that an initial request has been > retargeted as a result of an application decision. > > > > > > The IETF Secretariat > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From salvatore.loreto@ericsson.com Sun May 22 23:49:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B792E070C for ; Sun, 22 May 2011 23:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZdE8DAFR365 for ; Sun, 22 May 2011 23:49:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1971AE0720 for ; Sun, 22 May 2011 23:49:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ca-4dda0389c277 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 32.F3.20773.9830ADD4; Mon, 23 May 2011 08:49:45 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 May 2011 08:49:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 01821232B; Mon, 23 May 2011 09:49:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ABB7A50C32; Mon, 23 May 2011 09:49:44 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 55B5850A44; Mon, 23 May 2011 09:49:44 +0300 (EEST) Message-ID: <4DDA0388.60702@ericsson.com> Date: Mon, 23 May 2011 09:49:44 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="------------010509060602070006050303" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] charter proposal: SIP end-to-end Session Identifier X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 06:49:49 -0000 --------------010509060602070006050303 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, below a charter proposal for a new wg working on End-to-end Session Identifier in SIP. In an effort to make progress and to facilitate the discussion we have also created an Internet Draft that captures, at a high level, the requirements and use cases. (It was submitted by Paul E. Jones last Friday; here the link: http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt ) cheers /Sal End-to-end Session Identifier in SIP (charter proposal ) ---------------------------------------------- The end-to-end Session Identifier in an SIP-based multimedia communication refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices and hops. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers as defined in SIP is not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments devices like Session Border Controllers (SBC) often change the current call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end Session Identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end Session Identifier has been consideredas possible solution of different use cases like troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth. Some of these requirements have also been identified and come directly from other existing working group within the RAI area (e.g. SIPRec, Splices). Moreover, otherSDOs have identified the need for SIP and H.323 to carry the same "session ID" value(s) so that it is possible identify a call end-to end even when performing inter working between protocols. This group will first focus on adocument that will identify, collect and discuss all the requirements and the use cases that have been identified. The document may identify the possibility to design a general mechanism or the need to design multiple purpose built identifiers. Once the needs are clear and identified, the working group will specify the mechanism(s). Specifically, the proposed working group will develop the following deliverable: 1. A requirement and use case document with key consideration for SIP Session End-to-End identifier. The document will discuss the possibility of designing a general mechanism or the needs to design multiple purpose build identifier. 2. Specification of new mechanism(s). Goal and Milestone: October 2011 - Requirement and use case document sent to the IESG (Information) --------------010509060602070006050303 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

Hi there,

below a charter proposal for a new wg working on End-to-end Session Identifier in SIP.


In an effort to make progress and to facilitate the discussion
we have also created an Internet Draft that captures, at a high level,
the requirements and use cases.
(It was submitted by Paul E. Jones last Friday; here the link:
http://www.ietf.org/id/draft-jones-ipmc-session-id-reqts-00.txt )


cheers
/Sal

End-to-end Session Identifier in SIP (charter proposal )
----------------------------------------------


The end-to-end Session Identifier in an SIP-based multimedia communication refers to the ability
for endpoints, intermediate devices, and management and monitoring system to identify
and correlate SIP messages and dialogs of the same higher-level end-to-end "communication
session" across multiple SIP devices and hops.

Unfortunately, there are a number of factors that contribute to the fact that the current
dialog identifiers as defined in SIP is not suitable for end-to-end session identification.
Perhaps the most important factor worth describing is that in real-world
deployments devices like Session Border Controllers (SBC) often change the current call
identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header
to make the dialog-id) as the session signaling passes through.



An end-to-end Session Identifier should allow the possibility to identify the communication session
from the point of origin, passing through any number of intermediaries, to the ultimate point
of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction,
but should not be mangled by intermediaries.


A SIP end-to-end Session Identifier has been considered as possible solution of different use cases like
troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth.
Some of these requirements have also been identified and come directly from other existing
working group within the RAI area (e.g. SIPRec, Splices).


Moreover, other SDOs have identified the need for SIP and H.323 to carry the same "session ID" value(s)
so that it is possible identify a call end-to end even when performing inter working between
protocols.


This group will first focus on a document that will identify, collect and discuss all the
requirements and the use cases that have been identified.
The document may identify the possibility to design a general mechanism or the need
to design multiple purpose built identifiers.
Once the needs are clear and identified, the working group will specify the mechanism(s).


Specifically, the proposed working group will develop the following deliverable:

  1. A requirement and use case document with key consideration for SIP Session
    End-to-End identifier. The document will discuss the possibility of designing
    a general mechanism or the needs to design multiple purpose build identifier.
  2. Specification of new mechanism(s).


Goal and Milestone:
    October 2011 - Requirement and use case document sent to the IESG (Information)

 

--------------010509060602070006050303-- From paulej@packetizer.com Fri May 20 14:05:37 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3CE0797 for ; Fri, 20 May 2011 14:05:37 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7T745+FkA2p for ; Fri, 20 May 2011 14:05:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B559FE070E for ; Fri, 20 May 2011 14:05:36 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p4KL4fio008034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 May 2011 17:04:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1305925487; bh=R4Gg/m94TsdMunX5Bcvvr9A8Gg/9Wbg+Oi4UsvcSxjU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=b5n9FU6tbOkzkO6dpqXucFiUAPHitaaPOq8pBdzYvnBGxSgs2gAx84JJIc4o0hL2M qFqSxXJDY6vYoFtedS1wXhK9qwzk53LKo1L4sJ0KjaK/rQmV+WmsQJJ4ZULW9AqDnl 9ZTLxMc6pVmDQqF3WE/iYqPflT7ZPFI7qlBnfXcY= From: "Paul E. Jones" To: References: <20110520205914.2156.8113.idtracker@ietfa.amsl.com> In-Reply-To: <20110520205914.2156.8113.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2011 17:04:17 -0400 Message-ID: <05e701cc1731$7f37a010$7da6e030$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEgEArfDATa3Se0M85ggKim7oeUOZXuQaHQ Content-Language: en-us X-Mailman-Approved-At: Mon, 23 May 2011 07:23:37 -0700 Cc: 'Gerold Pinker' , 'Peter Musgrave' Subject: [dispatch] FW: I-D Action: draft-jones-ipmc-session-id-reqts-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 21:05:37 -0000 DISPATCH WG, In an effort to make progress in defining a new end-to-end Session Identifier for SIP, we have created an Internet Draft that captures, at a high level, the requirements and use cases. We look forward to continued discussion on this topic. Cheers! Paul > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, May 20, 2011 4:59 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-jones-ipmc-session-id-reqts-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Requirements for an End-to-End Session > Identification in IP-Based Multimedia Communication Networks > Author(s) : Paul E. Jones > Gonzalo Salgueiro > James Polk > Parthasarathi Ravindran > Laura Liess > Roland Jesske > Salvatore Loreto > Hadriel Kaplan > Filename : draft-jones-ipmc-session-id-reqts-00.txt > Pages : 8 > Date : 2011-05-20 > > This document specifies the requirements for an end-to-end session > identifier in IP-based multimedia communication networks. This > identifier would enable endpoints, intermediate devices, and > management and monitoring systems to identify a session end-to-end, > associate multiple endpoints with a given multipoint conference, > track communication sessions when they are redirected, and associate > one or more media flows with a given communication session. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-ipmc-session-id-reqts- > 00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-jones-ipmc-session-id-reqts- > 00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From partr@cisco.com Mon May 23 08:04:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D65E0781 for ; Mon, 23 May 2011 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.313 X-Spam-Level: X-Spam-Status: No, score=-9.313 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVRUBRagku6q for ; Mon, 23 May 2011 08:04:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07F20E0671 for ; Mon, 23 May 2011 08:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=18236; q=dns/txt; s=iport; t=1306163069; x=1307372669; h=mime-version:subject:date:message-id:from:to:cc; bh=I/jngSI9HGOuyEjeGNqixbvRq0eNXy9nXYfMMHNqhcU=; b=T58TuGEoI/U+9CJS+/MGWiL283EAPpJa7dqSV16WBNi2IMK01vGVkawd CoqlCzzK6zGaT96/EvgzK3Hj25Mz1B8Uc7+o7DcxBwm9guhre5nGQBIal hYMYgRjuu9K4gYaM3dQPhRQR5NKGchY/XNIHBTpXwJppk1RpQPAQ5UKyW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigEAJF22k1Io8UQeGdsb2JhbACmJRQBF0umDJ0bgxQTgnIEhk6Ne4pF X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208,217";a="90215230" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 23 May 2011 15:04:26 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4NF4Qvb010749; Mon, 23 May 2011 15:04:26 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 May 2011 20:34:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC195A.B4BE5DF8" Date: Mon, 23 May 2011 20:34:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Load balancing (SIPLB) Charter proposal Thread-Index: AcwZVtBeNaZm1dRbQuqPlztWqYWALQAA7TCw From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 23 May 2011 15:04:25.0966 (UTC) FILETIME=[B4E688E0:01CC195A] Subject: [dispatch] SIP Load balancing (SIPLB) Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 15:04:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC195A.B4BE5DF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 Charter proposal for SIP load balancing (SIPLB) is written in this mail to create a new WG related to SIP based load balancing. =20 There are lot of interest in SIP load balancing work during the time of IETF-80 and the side meeting leads to the creation of this charter. There are lot of draft submitted in Dispatch related to this work and the list is as follows: =20 [1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balanc ing-00 [2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00 [3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-c ontrol-00 =20 To make the progress in the work, the charter currently focus on two types of SIP based load balancing namely signaling only SIP load balancing and Media-related SIP based load balancing.=20 =20 Please provide your value inputs and comments in the below charter. =20 Thanks Vijay/Partha =20 SIP Load balancing (SIPLB) Charter ---------------------------------- =20 Session Load balancing (SIPLB) working group is chartered to define a=20 SIP-based protocol for load balancing SIP sessions. =20 Load balancing across a farm of SIP servers can be done today, but without=20 generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with=20 varying capabilities, example, a SIP proxy, a back-to-back user agent=20 (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media=20 servers etc. The capabilities and processing capacity on hosts in the farm=20 may be different, sometimes vastly, from each other. Furthermore, the=20 duration of time that a SIP host requires to process a SIP request=20 may vary. SIP proxies, operating at the transaction layer, may be=20 more efficient at processing transactions than a B2BUA would be,=20 which may need to maintain a long-lived dialogue state in addition to=20 the transaction state. PSTN gateways may have other limitations such=20 as media resources that may be depleted even though the gateway may=20 have enough processing power (i.e., CPU) to handle incoming requests. =20 In face of such diversity, simple load balancing schemes based on=20 round-robin selection tend to work only when many assumptions are met. First, the relative capacity and processing resources of all SIP servers in the farm should be nearly equal. Furthermore, because a round-robin=20 scheme presents a load of (1/n)*N to each server, where n =3D number of=20 servers and N =3D arrival rate in requests per second, it assumes that=20 the service time at each server is such that the utilization of each=20 server is not negatively impacted (i.e., utilization ratio of the arrival=20 rate over the mean service rate is less than 1.0). And finally,=20 the round-robin load balancing does not have a backward feedback mechanism=20 whereby the load-balanced server can inform the load balancer of its=20 current utilization (i.e., round-robin load balancing acts as an open-loop=20 controller). =20 The SIP load balancing working group is, therefore, chartered to=20 arrive at a load balancing scheme that distributes SIP requests to=20 a collection of servers to effectively utilize the resources at those=20 servers. These resources can include CPU, memory, network bandwidth,=20 input/output, DSP, DS0 or disk resources. The load balancing scheme must prevent excessive oscillation in the collection of servers. =20 In order to achieve such a load balancing scheme in practice, the following=20 considerations must be taken in account: =20 1) Should the load balancing scheme have a closed-loop model, i.e.,=20 should it report utilization to the load balancer to allow the=20 load balancer to distribute requests proportionally? =20 2) What should the diversity of the SIP hosts in a farm be? Is=20 it reasonable to assume that the same load balancing scheme should=20 be applicable to a pair of SIP servers, one of which can handle=20 an order of magnitude more requests per unit time that the other? =20 3) What information must be provisioned into the load balancer and=20 the servers? =20 4) As SIP request resource consumption in SIP signaling only server=20 varies drastically from SIP media servers, should the solution be=20 split such that load balancing of a pure signaling server is different=20 than that of a SIP server that handles signaling as well as media? =20 The last consideration above is especially important since a solution to load balancing a media farm will require a model where the SIP=20 load balancer is closely coupled with the downstream SIP servers. In such a model, the SIP load balancer knows the resources available at each of the downstream SIP servers and is able to inspect an incoming request to determine its media-related requirements and thus dispatch it to the downstream SIP server that has the highest probability of servicing that request. In some architectures, such a coupling reduces post-dial delay. =20 =20 Keeping the SIP load balancer and the downstream SIP servers=20 loosely coupled suffices for load balancing to a farm of SIP servers that only handle signaling. A loosely coupled model operates purely on the feedback received from the downstream SIP servers and does not require the SIP load balancer to inspect an incoming request. =20 Any solution needs to clearly specify its scope. A solution also=20 needs to clearly state any limitations, in performance or otherwise,=20 the specified load balancing mechanism may have. In particular,=20 the solution shall carefully define the deployment considerations for=20 the effective operation of the specified mechanisms and discuss,=20 for example, when a mechanism requires coordinated deployment and=20 operation (if all servers need to deploy the same mechanism, certain=20 configuration values need to be identical on all servers, etc.), when=20 a mechanism can become less effective or ineffective under some conditions,=20 or especially if there are cases when a mechanism these considerations=20 is to allow potential deployments to make the best use of these mechanism in=20 their particular networks. =20 SIPLB Working Group will thoroughly identify use cases, provide example=20 design & system architectures and deployment scenarios, and=20 define requirements. =20 The group will produce: =20 1) Use case and requirement document. 2) A document surveying SIP load balancing strategies in use today. 3) An architecture document showing sample SIP topologies. 4) Specification for SIP based overload scheme applicable to a=20 signaling-only SIP server. 5) Specification for SIP based overload scheme applicable to a media-based SIP server. =20 Goals and Milestones Mar 2012 Survey document for SIP load balancing strategies to IESG as an Informational document. Jun 2012 Use cases and requirement document to IESG as an Informational document. Aug 2012 Design & Architecture to IESG as Informational RFC Feb 2013 Submit signaling based SIP overload solution to IESG as=20 Proposed Standard RFC=20 Feb 2013 Submit signaling and media based SIP overload solution to=20 IESG as Proposed Standard RFC=20 ------_=_NextPart_001_01CC195A.B4BE5DF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Charter proposal for=20 SIP load balancing (SIPLB) is written in this mail to create a new = WG=20 related to SIP based load balancing.
 
There = are lot of=20 interest in SIP load balancing work during the time of IETF-80 and the = side=20 meeting leads to the creation of this charter. There are lot of draft = submitted=20 in Dispatch related to this work and the list is as = follows:
 
[1]http://tools.ietf.org/html/draft-bessis-dis= patch-adaptive-load-balancing-00
[2]http://tools.ietf.org/html/draft-j= ones-sip-overload-sce-00
[3]http://tools.ietf.org/html/draft-partha-di= spatch-sip-media-overload-control-00
 
To make the=20 progress in the work, the charter=20 currently focus on two types of SIP based load balancing = namely=20 signaling only SIP load balancing and Media-related SIP based load=20 balancing.
 
Please=20 provide your value inputs and comments in the=20 below charter.
 
Thanks
Vijay/Partha
 
SIP = Load balancing=20 (SIPLB) = Charter
----------------------------------
 
Session Load=20 balancing (SIPLB) working group is chartered to define a
SIP-based = protocol=20 for load balancing SIP sessions.
 
Load balancing across a = farm of=20 SIP servers can be done today, but without
generally agreed upon = principles=20 on how to best do accomplish this.
Confounding the problem is that a = SIP farm=20 may consist of hosts with
varying capabilities, example, a SIP = proxy, a=20 back-to-back user agent
(B2BUA), a public-switched telephone system = (PSTN)=20 gateway, SIP Media
servers etc. The capabilities and processing = capacity on=20 hosts in the farm
may be different, sometimes vastly, from each = other. =20 Furthermore, the
duration of time that a SIP host requires to = process a SIP=20 request
may vary. SIP proxies, operating at the transaction layer, = may be=20
more efficient at processing transactions than a B2BUA would be, =
which=20 may need to maintain a long-lived dialogue state in addition to
the=20 transaction state.  PSTN gateways may have other limitations such =
as=20 media resources that may be depleted even though the gateway may =
have enough=20 processing power (i.e., CPU) to handle incoming = requests.
 
In face=20 of such diversity, simple load balancing schemes based on =
round-robin=20 selection tend to work only when many assumptions are met.
First, the = relative capacity and processing resources of all SIP servers
in the = farm=20 should be nearly equal.  Furthermore, because a round-robin =
scheme=20 presents a load of (1/n)*N to each server, where n =3D number of =
servers and N=20 =3D arrival rate in requests per second, it assumes that
the service = time at=20 each server is such that the utilization of each
server is not = negatively=20 impacted (i.e., utilization ratio of the arrival
rate over the mean = service=20 rate is less than 1.0).  And finally,
the round-robin load = balancing=20 does not have a backward feedback mechanism
whereby the = load-balanced server=20 can inform the load balancer of its
current utilization (i.e., = round-robin=20 load balancing acts as an open-loop
controller).
 
The = SIP load=20 balancing working group is, therefore, chartered to
arrive at a load = balancing scheme that distributes SIP requests to
a collection of = servers to=20 effectively utilize the resources at those
servers. These resources = can=20 include CPU, memory, network bandwidth,
input/output, DSP, DS0 or = disk=20 resources.  The load balancing
scheme must prevent excessive = oscillation=20 in the collection of
servers.
 
In = order to achieve=20 such a load balancing scheme in practice, the following =
considerations must=20 be taken in account:
 
1) Should the load balancing scheme = have a=20 closed-loop model, i.e.,
should it report utilization to the load = balancer=20 to allow the
load balancer to distribute requests=20 proportionally?
 
2) What should the diversity of the SIP = hosts in a=20 farm be?  Is
it reasonable to assume that the same load = balancing=20 scheme should
be applicable to a pair of SIP servers, one of which = can=20 handle
an order of magnitude more requests per unit time that the=20 other?
 
3) What information must be provisioned into the = load=20 balancer and
the servers?
 
4) As SIP request resource=20 consumption in SIP signaling only server
varies drastically from SIP = media=20 servers, should the solution be
split such that load balancing of a = pure=20 signaling server is different
than that of a SIP server that handles = signaling as well as media?
 
The last consideration above is = especially important since a solution
to load balancing a media farm = will=20 require a model where the SIP
load balancer is closely coupled with = the=20 downstream SIP servers.
In such a model, the SIP load balancer knows = the=20 resources available
at each of the downstream SIP servers and is able = to=20 inspect an
incoming request to determine its media-related = requirements and=20 thus
dispatch it to the downstream SIP server that has the=20 highest
probability of servicing that request.  In some = architectures,=20 such
a coupling reduces post-dial delay. 
 
Keeping the SIP load=20 balancer and the downstream SIP servers
loosely coupled suffices for = load=20 balancing to a farm of SIP
servers that only handle signaling.  = A=20 loosely coupled model
operates purely on the feedback received from = the=20 downstream
SIP servers and does not require the SIP load balancer to=20 inspect
an incoming request.
 
Any = solution needs=20 to clearly specify its scope.  A solution also
needs to clearly = state=20 any limitations, in performance or otherwise,
the specified load = balancing=20 mechanism may have.  In particular,
the solution shall = carefully define=20 the deployment considerations for
the effective operation of the = specified=20 mechanisms and discuss,
for example, when a mechanism requires = coordinated=20 deployment and
operation (if all servers need to deploy the same = mechanism,=20 certain
configuration values need to be identical on all servers, = etc.),=20 when
a mechanism can become less effective or ineffective under some = conditions,
or especially if there are cases when a mechanism these=20 considerations
is to allow potential deployments to make the best = use of=20 these mechanism in
their particular networks.
 
SIPLB = Working=20 Group will thoroughly identify use cases, provide example
design = &=20 system architectures and deployment scenarios, and
define=20 requirements.
 
The group will produce:
 
1) Use = case and=20 requirement document.
2) A document surveying SIP load balancing = strategies=20 in use today.
3) An architecture document showing sample SIP=20 topologies.
4) Specification for SIP based overload scheme applicable = to a=20
   signaling-only SIP server.
5) Specification for SIP = based=20 overload scheme applicable to a
   media-based SIP=20 server.
 
Goals and Milestones
Mar 2012  Survey = document for=20 SIP load balancing strategies to=20 IESG
          as an=20 Informational document.
Jun 2012  Use cases and requirement = document to=20 IESG as an=20 Informational
         =20 document.
Aug 2012  Design & Architecture to IESG as = Informational=20 RFC
Feb 2013  Submit signaling based SIP overload solution to = IESG as=20
          Proposed = Standard RFC=20
Feb 2013  Submit signaling and media based SIP overload = solution to=20
          IESG as = Proposed=20 Standard RFC
------_=_NextPart_001_01CC195A.B4BE5DF8-- From fluffy@cisco.com Mon May 23 11:31:05 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41270E07C2 for ; Mon, 23 May 2011 11:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTTRL+SG8T5n for ; Mon, 23 May 2011 11:31:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 90570E06AB for ; Mon, 23 May 2011 11:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=17969; q=dns/txt; s=iport; t=1306175463; x=1307385063; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dTtev4qJ7EOM663wuYjjEEMIxIjfDEPFr/t0zM4/gHw=; b=aWXkxhmFoJOpHbdC6Uhy23oXWBmtAui60gJScFOTmaKO2xAeUESTSNww D86U/y7X6ueyuI/VpwHUkO/Dv6ucU78XiWy4gVSAj9gjZNjcxogqjg22H 2J1ci0rFDsoUVx6DbD6qJxNBkrFBgM4ypQEHaXEnAxlBzaeYuUFaucYXI c=; X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="362620391" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 23 May 2011 18:30:59 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4NIUwM4010422; Mon, 23 May 2011 18:30:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4DD666DD.5010701@cisco.com> Date: Mon, 23 May 2011 12:30:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9B04E3.2090301@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D01859CA8D4@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840D45A06@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941D0@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E941FA@HE111648.emea1.cds.t-internal.com><4DD51723.2040804@cisco.com><580BEA5E3B99744AB1F5BFF5E9A3C67D0840EF0C18@HE111648.emea1.cds.t-internal.com> <4DD66266.4080001@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA0A120D03@gaalpa1msgusr7e.ugd.att.com> <4DD666DD.5010701@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) Cc: DISPATCH list Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:31:05 -0000 It's pretty clear that we won't have interoperable systems unless the = draft clearly says what to do in these cases. And I would like to +1 = Martin's request for a real life example for any of this work. Please = could the authors of the draft give us a real life example of how this = all gets used in an itneroperable way.=20 On May 20, 2011, at 7:04 AM, Paul Kyzivat wrote: >=20 >=20 > On 5/20/2011 8:48 AM, DOLLY, MARTIN C (ATTSI) wrote: >> Paul, >>=20 >> I do not understand your concern. Please give a REAL life example, = not a what if. >=20 > To start with, I am having difficulty understanding a use case for = when you would *want* to send a sip reason code in a sip response. >=20 > The motivation for the Reason header in the first place was to explain = why a particular *request* was being sent. >=20 > The justification for Q.850 reasons in *responses* is because the sip = response codes don't carry all the nuances that the Q.850 codes do. >=20 > Suppose I get SIP 486 response with a sip 503 reason code, or a sip = 503 response code with a sip 486 reason code. What am I supposed to do = with that? What does it *mean*? >=20 > Thanks, > Paul >=20 >> Thank you, >>=20 >> Martin Dolly >> Lead Member Technical Staff >> Core& Government/Regulatory Standards >> AT&T Services, Inc. >> md3135@att.com >> +1-609-903-3360 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul Kyzivat >> Sent: Friday, May 20, 2011 8:45 AM >> To: R.Jesske@telekom.de >> Cc: dispatch-chairs@tools.ietf.org; dispatch@ietf.org >> Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in = Reason header fields >>=20 >>=20 >>=20 >> On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: >>> Hi Paul, >>> that was my understanding what Gonzalo proposed. >>> He wanted to have it described as general approach. Without any = restriction to ISUP Causes to be future proof. >>>=20 >>> I have this send around a couple weeks ago. Nobody answered and I = was in assumption that everybody agreed on this. >>> Therefore I asked again for the agreement on the change again and = what group name (DISPATCH? SIPCORE?) I should use for the next draft. >>>=20 >>> I really don't care what way we go as long as we progress the draft = properly and get the work done. >>>=20 >>> I have 5 for progress with option 1 and one with don't care and you. >>=20 >> The concern is that that sip reason codes in sip responses are like >> having multiple responses to the same request. How should one behave? >>=20 >> Fundamentally the problem isn't with the mechanics of delivering the >> reason - its with the semantics of what has been sent. This has the >> potential to lead to interoperation problems. >>=20 >> We can let the chairs/ADs decide what to do. >>=20 >> Thanks, >> Paul >>=20 >>> How to proceed now? >>>=20 >>> Best Regards >>>=20 >>> Roland >>>=20 >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>>> Gesendet: Donnerstag, 19. Mai 2011 15:12 >>>> An: dispatch@ietf.org >>>> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause >>>> values in Reason header fields >>>>=20 >>>> I am getting confused by all the options mentioned, to the >>>> point that I >>>> don't understand what is being proposed now. >>>>=20 >>>> It *sounds* like you are proposing to allow *any* reason >>>> (including sip >>>> reason codes) in any response. I am concerned that that will cause >>>> considerable confusion. >>>>=20 >>>> I apologize if that is not what you are proposing. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: >>>>> Dear all, >>>>> So assuming that there was no comment people are happy with >>>> the new rewording I would like to prepare a new draft. >>>>>=20 >>>>> This would be Option 1: General wording to allow the Reason >>>> header within responses without any restrictions (except 100 = Trying). >>>>> And nobody wanted to have Option 2: Wording as stated in >>>> the current draft >>>>> draft-jesske-dispatch-update3326-reason-responses-02 >>>>>=20 >>>>> Agreed? Comments? >>>>>=20 >>>>> Thank you and best Regards >>>>>=20 >>>>> Roland >>>>>=20 >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> Von: Jesske, Roland >>>>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 >>>>>> An: Jesske, Roland >>>>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >>>>>> values in Reason header fields >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On May 13, 2011, at 3:18 AM, = wrote: >>>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>> Since my answer it looks that people would be >>>>>> OK with the change. >>>>>> So if no body comments within the next few days >>>>>> I would prepare a new draft. >>>>>>=20 >>>>>> So due to Gonzalo's proposal I would rewrite >>>>>> the paragraphs as shown below. >>>>>> For comparison reasons I have added also the >>>>>> text proposal of the current draft >>>>>> (draft-jesske-dispatch-update3326-reason-responses-02). >>>>>> Please indicate which text you would like to >>>>>> see finally. New proposal or current proposal. >>>>>>=20 >>>>>>=20 >>>>>> 3. RFC3326 1. Introduction >>>>>>=20 >>>>>> Original Text: >>>>>>=20 >>>>>> Initially, the Reason header field defined >>>>>> here appears to be most >>>>>> useful for BYE and CANCEL requests, but it >>>>>> can appear in any request >>>>>> within a dialog, in any CANCEL request and in >>>>>> any response whose >>>>>> status code explicitly allows the presence of >>>>>> this header field. >>>>>>=20 >>>>>> Note that the Reason header field is usually >>>>>> not needed in responses >>>>>> because the status code and the reason phrase >>>>>> already provide >>>>>> sufficient information. >>>>>>=20 >>>>>> New Text(new proposal): >>>>>>=20 >>>>>> Initially, the Reason header field defined >>>>>> here appears to be most >>>>>> useful for BYE and CANCEL requests, but it >>>>>> can appear in any request >>>>>> within a dialog, in any CANCEL request >>>>>> independent of the protocol >>>>>> value used and in any response except 100 trying. >>>>>>=20 >>>>>> New Text (text stated in the current draft >>>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>>>=20 >>>>>> Initially, the Reason header field defined >>>>>> here appears to be most >>>>>> useful for BYE and CANCEL requests, but it >>>>>> can appear in any request >>>>>> within a dialog, in any CANCEL request >>>>>> independent of the protocol >>>>>> value used and in any response except 100 >>>>>> trying if it contains only >>>>>> a Q.850 Cause Code. >>>>>>=20 >>>>>> 4. RFC3326 2. The Reason Header Field >>>>>>=20 >>>>>> Original Text >>>>>>=20 >>>>>> The Reason header field MAY appear in any >>>>>> request within a dialog, in >>>>>> any CANCEL request and in any response whose >>>>>> status code explicitly >>>>>> allows the presence of this header field. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Jesske& Liess Expires October 2, >>>>>> 2011 [Page 3] >>>>>>=20 >>>>>> Internet-Draft Reason Header >>>>>> March 2011 >>>>>>=20 >>>>>>=20 >>>>>> New Text(new proposal): >>>>>>=20 >>>>>> The Reason header field MAY appear >>>>>> in any request within a dialog, in any CANCEL >>>>>> request . The >>>>>> appearance of the Reason header field is >>>>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>>>=20 >>>>>>=20 >>>>>> New Text(text stated in the current draft >>>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>>>=20 >>>>>> The Reason header field only containing a >>>>>> Q.850 Cause Code MAY appear >>>>>> in any request within a dialog, in any CANCEL >>>>>> request . The >>>>>> appearance of the Reason header field only >>>>>> containing a Q.850 Cause >>>>>> Code is applicable to final responses 3xx, >>>>>> 4xx, 5xx and 6xx and 18x >>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>>>=20 >>>>>> The Reason header field containing any other >>>>>> reason value MAY appear >>>>>> in any request within a dialog, in any CANCEL >>>>>> request and in any >>>>>> response whose status code explicitly allows >>>>>> the presence of this >>>>>> header field. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best Regards >>>>>>=20 >>>>>>=20 >>>>>> Roland >>>>>>=20 >>>>>>=20 >>>>>> Deutsche Telekom Netzproduktion GmbH >>>>>> Fixed Mobile Engineering Deutschland >>>>>> 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: mailto:r.jesske@telekom.de >>>>>> http://www.telekom.de >>>>>>=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 >>>>>>=20 >>>>>> Gro=DFe Ver=E4nderungen fangen klein an - >>>>>> Ressourcen schonen und nicht jede E-Mail drucken. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>=20 >>>>>>=20 >>>>>> Von: dispatch-bounces@ietf.org >>>>>>=20 >>>>>>=20 >>>>>> [mailto:dispatch-bounces@ietf.org] Im >>>>>> Auftrag von Jesske, Roland >>>>>>=20 >>>>>>=20 >>>>>> Gesendet: Mittwoch, 6. April 2011 11:24 >>>>>>=20 >>>>>>=20 >>>>>> An: Gonzalo.Camarillo@ericsson.com; >>>>>> dispatch@ietf.org >>>>>>=20 >>>>>>=20 >>>>>> Betreff: Re: [dispatch] SIP responses >>>>>> carrying Q.850 cause >>>>>>=20 >>>>>>=20 >>>>>> values in Reason header fields >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Gonzalo, >>>>>>=20 >>>>>>=20 >>>>>> I'm OK with your proposal so I could >>>>>> change it if people >>>>>>=20 >>>>>>=20 >>>>>> would like it. >>>>>>=20 >>>>>>=20 >>>>>> It makes it shorter. >>>>>>=20 >>>>>>=20 >>>>>> The only I would propose to have in is >>>>>> the explicit >>>>>>=20 >>>>>>=20 >>>>>> mentioning of the Response values due >>>>>> to the fact that a >>>>>>=20 >>>>>>=20 >>>>>> 100OK or 200OK should not include a >>>>>> Reason header with a >>>>>>=20 >>>>>>=20 >>>>>> Q.850 Cause Value. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best Regards >>>>>>=20 >>>>>>=20 >>>>>> Roland Jesske >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Urspr=FCngliche = Nachricht----- >>>>>>=20 >>>>>>=20 >>>>>> Von: dispatch-bounces@ietf.org >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo = Camarillo >>>>>>=20 >>>>>>=20 >>>>>> Gesendet: Dienstag, 5. >>>> April 2011 14:03 >>>>>>=20 >>>>>>=20 >>>>>> An: DISPATCH >>>>>>=20 >>>>>>=20 >>>>>> Betreff: [dispatch] SIP >>>>>> responses carrying Q.850 cause values >>>>>>=20 >>>>>>=20 >>>>>> in Reason header fields >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> last week in the DISPATCH >>>>>> session, there was consensus to allow SIP >>>>>>=20 >>>>>>=20 >>>>>> responses to carry Reason >>>>>> header fields with Q.850 cause >>>>>>=20 >>>>>>=20 >>>>>> values. As I >>>>>>=20 >>>>>>=20 >>>>>> said some time ago, I am >>>>>> willing to AD sponsor this draft >>>>>>=20 >>>>>>=20 >>>>>> if/when the >>>>>>=20 >>>>>>=20 >>>>>> DISPATCH chairs confirm such >>>>>> consensus on the list. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> In the mean time, I have some >>>>>> comments on how to document >>>>>>=20 >>>>>>=20 >>>>>> this decision. >>>>>>=20 >>>>>>=20 >>>>>> The following (fairly short) >>>>>> draft updates a couple of >>>>>>=20 >>>>>>=20 >>>>>> paragraphs in RFC >>>>>>=20 >>>>>>=20 >>>>>> 3326 in order to achieve the >>>>>> desired outcome: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >>>>>> -responses-02.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I think this is not a >>>>>> particularly elegant way to define >>>>>>=20 >>>>>>=20 >>>>>> what we want. >>>>>>=20 >>>>>>=20 >>>>>> For example, if we wanted to >>>>>> define a solution to HERFP in >>>>>>=20 >>>>>>=20 >>>>>> the future >>>>>>=20 >>>>>>=20 >>>>>> based on the Reason header, we >>>>>> would need to update those paragraphs >>>>>>=20 >>>>>>=20 >>>>>> again, making them longer every >>>>>> time we added a new use case. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Instead, I would prefer to >>>>>> explicitly define what we want >>>>>>=20 >>>>>>=20 >>>>>> to do and be >>>>>>=20 >>>>>>=20 >>>>>> done with it. Such a (also >>>>>> fairly short) draft would say >>>>>>=20 >>>>>>=20 >>>>>> something along >>>>>>=20 >>>>>>=20 >>>>>> the following lines: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> "RFC 3326 allows the presence >>>>>> of the Reason header field in >>>>>>=20 >>>>>>=20 >>>>>> any response >>>>>>=20 >>>>>>=20 >>>>>> whose status code explicitly >>>>>> allows its presence. This document >>>>>>=20 >>>>>>=20 >>>>>> explicitly allows any SIP >>>>>> response to carry a Reason header >>>>>>=20 >>>>>>=20 >>>>>> field with a >>>>>>=20 >>>>>>=20 >>>>>> Q.850 cause value. SIP >>>>>> responses with Reason header fields carrying >>>>>>=20 >>>>>>=20 >>>>>> values other than Q.850 cause >>>>>> values are outside of the >>>>>>=20 >>>>>>=20 >>>>>> scope of this >>>>>>=20 >>>>>>=20 >>>>>> document." >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I would like to know the >>>>>> opinion of the WG on this matter >>>>>>=20 >>>>>>=20 >>>>>> (i.e., how to >>>>>>=20 >>>>>>=20 >>>>>> document the WG's consensus). >>>>>> Note that reaching consensus was the >>>>>>=20 >>>>>>=20 >>>>>> difficult part. Agreeing on how >>>>>> to document it should be easy. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Gonzalo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>>=20 >>>>>>=20 >>>>>> dispatch mailing list >>>>>>=20 >>>>>>=20 >>>>>> dispatch@ietf.org >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> _______________________________________________ >>>>>>=20 >>>>>>=20 >>>>>> dispatch mailing list >>>>>>=20 >>>>>>=20 >>>>>> dispatch@ietf.org >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Mon May 23 13:18:11 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD05E069C for ; Mon, 23 May 2011 13:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afXHm1eXvXE4 for ; Mon, 23 May 2011 13:18:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 185B5E069A for ; Mon, 23 May 2011 13:18:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-55-4ddac0fea6dd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.CC.09774.EF0CADD4; Mon, 23 May 2011 22:18:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 23 May 2011 22:18:06 +0200 From: Christer Holmberg To: Cullen Jennings , Paul Kyzivat Date: Mon, 23 May 2011 22:18:06 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AQHMGYaG3hoSzQ+h9keKM42hHFTp7Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:18:11 -0000 Hi, 199 responses is a real-life example. A couple of days I suggested that we allow Reason headers with SIP response= codes in SIP responses only if explicitly allowed for the response code of= the SIP response. And, if we agree to such way forward we don't need to specify anything new,= because it's already allowed in RFC 3326: "The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field." Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Cu= llen Jennings [fluffy@cisco.com] Sent: Monday, May 23, 2011 9:30 PM To: Paul Kyzivat Cc: DISPATCH list Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in = Reason header fields It's pretty clear that we won't have interoperable systems unless the draft= clearly says what to do in these cases. And I would like to +1 Martin's re= quest for a real life example for any of this work. Please could the author= s of the draft give us a real life example of how this all gets used in an = itneroperable way. On May 20, 2011, at 7:04 AM, Paul Kyzivat wrote: > > > On 5/20/2011 8:48 AM, DOLLY, MARTIN C (ATTSI) wrote: >> Paul, >> >> I do not understand your concern. Please give a REAL life example, not a= what if. > > To start with, I am having difficulty understanding a use case for when y= ou would *want* to send a sip reason code in a sip response. > > The motivation for the Reason header in the first place was to explain wh= y a particular *request* was being sent. > > The justification for Q.850 reasons in *responses* is because the sip res= ponse codes don't carry all the nuances that the Q.850 codes do. > > Suppose I get SIP 486 response with a sip 503 reason code, or a sip 503 r= esponse code with a sip 486 reason code. What am I supposed to do with that= ? What does it *mean*? > > Thanks, > Paul > >> Thank you, >> >> Martin Dolly >> Lead Member Technical Staff >> Core& Government/Regulatory Standards >> AT&T Services, Inc. >> md3135@att.com >> +1-609-903-3360 >> >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Be= half Of Paul Kyzivat >> Sent: Friday, May 20, 2011 8:45 AM >> To: R.Jesske@telekom.de >> Cc: dispatch-chairs@tools.ietf.org; dispatch@ietf.org >> Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Rea= son header fields >> >> >> >> On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: >>> Hi Paul, >>> that was my understanding what Gonzalo proposed. >>> He wanted to have it described as general approach. Without any restric= tion to ISUP Causes to be future proof. >>> >>> I have this send around a couple weeks ago. Nobody answered and I was i= n assumption that everybody agreed on this. >>> Therefore I asked again for the agreement on the change again and what = group name (DISPATCH? SIPCORE?) I should use for the next draft. >>> >>> I really don't care what way we go as long as we progress the draft pro= perly and get the work done. >>> >>> I have 5 for progress with option 1 and one with don't care and you. >> >> The concern is that that sip reason codes in sip responses are like >> having multiple responses to the same request. How should one behave? >> >> Fundamentally the problem isn't with the mechanics of delivering the >> reason - its with the semantics of what has been sent. This has the >> potential to lead to interoperation problems. >> >> We can let the chairs/ADs decide what to do. >> >> Thanks, >> Paul >> >>> How to proceed now? >>> >>> Best Regards >>> >>> Roland >>> >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>>> Gesendet: Donnerstag, 19. Mai 2011 15:12 >>>> An: dispatch@ietf.org >>>> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause >>>> values in Reason header fields >>>> >>>> I am getting confused by all the options mentioned, to the >>>> point that I >>>> don't understand what is being proposed now. >>>> >>>> It *sounds* like you are proposing to allow *any* reason >>>> (including sip >>>> reason codes) in any response. I am concerned that that will cause >>>> considerable confusion. >>>> >>>> I apologize if that is not what you are proposing. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: >>>>> Dear all, >>>>> So assuming that there was no comment people are happy with >>>> the new rewording I would like to prepare a new draft. >>>>> >>>>> This would be Option 1: General wording to allow the Reason >>>> header within responses without any restrictions (except 100 Trying). >>>>> And nobody wanted to have Option 2: Wording as stated in >>>> the current draft >>>>> draft-jesske-dispatch-update3326-reason-responses-02 >>>>> >>>>> Agreed? Comments? >>>>> >>>>> Thank you and best Regards >>>>> >>>>> Roland >>>>> >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> Von: Jesske, Roland >>>>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 >>>>>> An: Jesske, Roland >>>>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >>>>>> values in Reason header fields >>>>>> >>>>>> >>>>>> >>>>>> On May 13, 2011, at 3:18 AM, wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> Since my answer it looks that people would be >>>>>> OK with the change. >>>>>> So if no body comments within the next few days >>>>>> I would prepare a new draft. >>>>>> >>>>>> So due to Gonzalo's proposal I would rewrite >>>>>> the paragraphs as shown below. >>>>>> For comparison reasons I have added also the >>>>>> text proposal of the current draft >>>>>> (draft-jesske-dispatch-update3326-reason-responses-02). >>>>>> Please indicate which text you would like to >>>>>> see finally. New proposal or current proposal. >>>>>> >>>>>> >>>>>> 3. RFC3326 1. Introduction >>>>>> >>>>>> Original Text: >>>>>> >>>>>> Initially, the Reason header field defined >>>>>> here appears to be most >>>>>> useful for BYE and CANCEL requests, but it >>>>>> can appear in any request >>>>>> within a dialog, in any CANCEL request and in >>>>>> any response whose >>>>>> status code explicitly allows the presence of >>>>>> this header field. >>>>>> >>>>>> Note that the Reason header field is usually >>>>>> not needed in responses >>>>>> because the status code and the reason phrase >>>>>> already provide >>>>>> sufficient information. >>>>>> >>>>>> New Text(new proposal): >>>>>> >>>>>> Initially, the Reason header field defined >>>>>> here appears to be most >>>>>> useful for BYE and CANCEL requests, but it >>>>>> can appear in any request >>>>>> within a dialog, in any CANCEL request >>>>>> independent of the protocol >>>>>> value used and in any response except 100 trying. >>>>>> >>>>>> New Text (text stated in the current draft >>>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>>> >>>>>> Initially, the Reason header field defined >>>>>> here appears to be most >>>>>> useful for BYE and CANCEL requests, but it >>>>>> can appear in any request >>>>>> within a dialog, in any CANCEL request >>>>>> independent of the protocol >>>>>> value used and in any response except 100 >>>>>> trying if it contains only >>>>>> a Q.850 Cause Code. >>>>>> >>>>>> 4. RFC3326 2. The Reason Header Field >>>>>> >>>>>> Original Text >>>>>> >>>>>> The Reason header field MAY appear in any >>>>>> request within a dialog, in >>>>>> any CANCEL request and in any response whose >>>>>> status code explicitly >>>>>> allows the presence of this header field. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Jesske& Liess Expires October 2, >>>>>> 2011 [Page 3] >>>>>> >>>>>> Internet-Draft Reason Header >>>>>> March 2011 >>>>>> >>>>>> >>>>>> New Text(new proposal): >>>>>> >>>>>> The Reason header field MAY appear >>>>>> in any request within a dialog, in any CANCEL >>>>>> request . The >>>>>> appearance of the Reason header field is >>>>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>>> >>>>>> >>>>>> New Text(text stated in the current draft >>>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>>> >>>>>> The Reason header field only containing a >>>>>> Q.850 Cause Code MAY appear >>>>>> in any request within a dialog, in any CANCEL >>>>>> request . The >>>>>> appearance of the Reason header field only >>>>>> containing a Q.850 Cause >>>>>> Code is applicable to final responses 3xx, >>>>>> 4xx, 5xx and 6xx and 18x >>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>>> >>>>>> The Reason header field containing any other >>>>>> reason value MAY appear >>>>>> in any request within a dialog, in any CANCEL >>>>>> request and in any >>>>>> response whose status code explicitly allows >>>>>> the presence of this >>>>>> header field. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>> Deutsche Telekom Netzproduktion GmbH >>>>>> Fixed Mobile Engineering Deutschland >>>>>> 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: mailto:r.jesske@telekom.de >>>>>> http://www.telekom.de >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> >>>>>> >>>>>> Von: dispatch-bounces@ietf.org >>>>>> >>>>>> >>>>>> [mailto:dispatch-bounces@ietf.org] Im >>>>>> Auftrag von Jesske, Roland >>>>>> >>>>>> >>>>>> Gesendet: Mittwoch, 6. April 2011 11:24 >>>>>> >>>>>> >>>>>> An: Gonzalo.Camarillo@ericsson.com; >>>>>> dispatch@ietf.org >>>>>> >>>>>> >>>>>> Betreff: Re: [dispatch] SIP responses >>>>>> carrying Q.850 cause >>>>>> >>>>>> >>>>>> values in Reason header fields >>>>>> >>>>>> >>>>>> >>>>>> Hi Gonzalo, >>>>>> >>>>>> >>>>>> I'm OK with your proposal so I could >>>>>> change it if people >>>>>> >>>>>> >>>>>> would like it. >>>>>> >>>>>> >>>>>> It makes it shorter. >>>>>> >>>>>> >>>>>> The only I would propose to have in is >>>>>> the explicit >>>>>> >>>>>> >>>>>> mentioning of the Response values due >>>>>> to the fact that a >>>>>> >>>>>> >>>>>> 100OK or 200OK should not include a >>>>>> Reason header with a >>>>>> >>>>>> >>>>>> Q.850 Cause Value. >>>>>> >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> >>>>>> Roland Jesske >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> >>>>>> >>>>>> Von: dispatch-bounces@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo >>>>>> >>>>>> >>>>>> Gesendet: Dienstag, 5. >>>> April 2011 14:03 >>>>>> >>>>>> >>>>>> An: DISPATCH >>>>>> >>>>>> >>>>>> Betreff: [dispatch] SIP >>>>>> responses carrying Q.850 cause values >>>>>> >>>>>> >>>>>> in Reason header fields >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> last week in the DISPATCH >>>>>> session, there was consensus to allow SIP >>>>>> >>>>>> >>>>>> responses to carry Reason >>>>>> header fields with Q.850 cause >>>>>> >>>>>> >>>>>> values. As I >>>>>> >>>>>> >>>>>> said some time ago, I am >>>>>> willing to AD sponsor this draft >>>>>> >>>>>> >>>>>> if/when the >>>>>> >>>>>> >>>>>> DISPATCH chairs confirm such >>>>>> consensus on the list. >>>>>> >>>>>> >>>>>> >>>>>> In the mean time, I have some >>>>>> comments on how to document >>>>>> >>>>>> >>>>>> this decision. >>>>>> >>>>>> >>>>>> The following (fairly short) >>>>>> draft updates a couple of >>>>>> >>>>>> >>>>>> paragraphs in RFC >>>>>> >>>>>> >>>>>> 3326 in order to achieve the >>>>>> desired outcome: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >>>>>> -responses-02.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I think this is not a >>>>>> particularly elegant way to define >>>>>> >>>>>> >>>>>> what we want. >>>>>> >>>>>> >>>>>> For example, if we wanted to >>>>>> define a solution to HERFP in >>>>>> >>>>>> >>>>>> the future >>>>>> >>>>>> >>>>>> based on the Reason header, we >>>>>> would need to update those paragraphs >>>>>> >>>>>> >>>>>> again, making them longer every >>>>>> time we added a new use case. >>>>>> >>>>>> >>>>>> >>>>>> Instead, I would prefer to >>>>>> explicitly define what we want >>>>>> >>>>>> >>>>>> to do and be >>>>>> >>>>>> >>>>>> done with it. Such a (also >>>>>> fairly short) draft would say >>>>>> >>>>>> >>>>>> something along >>>>>> >>>>>> >>>>>> the following lines: >>>>>> >>>>>> >>>>>> >>>>>> "RFC 3326 allows the presence >>>>>> of the Reason header field in >>>>>> >>>>>> >>>>>> any response >>>>>> >>>>>> >>>>>> whose status code explicitly >>>>>> allows its presence. This document >>>>>> >>>>>> >>>>>> explicitly allows any SIP >>>>>> response to carry a Reason header >>>>>> >>>>>> >>>>>> field with a >>>>>> >>>>>> >>>>>> Q.850 cause value. SIP >>>>>> responses with Reason header fields carrying >>>>>> >>>>>> >>>>>> values other than Q.850 cause >>>>>> values are outside of the >>>>>> >>>>>> >>>>>> scope of this >>>>>> >>>>>> >>>>>> document." >>>>>> >>>>>> >>>>>> >>>>>> I would like to know the >>>>>> opinion of the WG on this matter >>>>>> >>>>>> >>>>>> (i.e., how to >>>>>> >>>>>> >>>>>> document the WG's consensus). >>>>>> Note that reaching consensus was the >>>>>> >>>>>> >>>>>> difficult part. Agreeing on how >>>>>> to document it should be easy. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> dispatch mailing list >>>>>> >>>>>> >>>>>> dispatch@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>>>> >>>>>> dispatch mailing list >>>>>> >>>>>> >>>>>> dispatch@ietf.org >>>>>> >>>>>> >>>>>> >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 pkyzivat@cisco.com Mon May 23 14:10:39 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F92E0841 for ; Mon, 23 May 2011 14:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.651 X-Spam-Level: X-Spam-Status: No, score=-109.651 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeaGGhosN+LI for ; Mon, 23 May 2011 14:10:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 583D1E0843 for ; Mon, 23 May 2011 14:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=19321; q=dns/txt; s=iport; t=1306185036; x=1307394636; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZV4rTerV6qHUgEnN1g83Qfj73UJilQIj6+ZlzzwqxsI=; b=KKwTqSoQ6jxtikR2TqCns9efhmOzQZfnurljYtaKAcWQCcfQ9X6kV2wF PKWh7Bz+yo0Mo/G5SLCiy76aommUzblp6y+lmw96NkNAqqlXMCvjf1Woh 9enR9Rb1234FaJnNy8mr6Z/+0WeIvVHA/TQIpxe4+rNqVln0OtMQcixh6 s=; X-IronPort-AV: E=Sophos;i="4.65,258,1304294400"; d="scan'208";a="702047081" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 23 May 2011 21:10:36 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4NLAZUn006601; Mon, 23 May 2011 21:10:35 GMT Message-ID: <4DDACD4B.4050305@cisco.com> Date: Mon, 23 May 2011 17:10:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: DISPATCH list Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 21:10:39 -0000 Christer, Yes, we have been around that track a few times, and I'm ok with that case. Its independent of the other changes being proposed (unless they tread on the clause it depends upon.) My concern was with allowing sip reason codes in all responses. And I think maybe Cullen is asking about the semantics of Q.850 codes in responses. Thanks, Paul On 5/23/2011 4:18 PM, Christer Holmberg wrote: > > Hi, > > 199 responses is a real-life example. > > A couple of days I suggested that we allow Reason headers with SIP response codes in SIP responses only if explicitly allowed for the response code of the SIP response. > > And, if we agree to such way forward we don't need to specify anything new, because it's already allowed in RFC 3326: > > "The Reason header field MAY appear in any request within a dialog, in > any CANCEL request and in any response whose status code explicitly > allows the presence of this header field." > > Regards, > > Christer > > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings [fluffy@cisco.com] > Sent: Monday, May 23, 2011 9:30 PM > To: Paul Kyzivat > Cc: DISPATCH list > Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields > > It's pretty clear that we won't have interoperable systems unless the draft clearly says what to do in these cases. And I would like to +1 Martin's request for a real life example for any of this work. Please could the authors of the draft give us a real life example of how this all gets used in an itneroperable way. > > > On May 20, 2011, at 7:04 AM, Paul Kyzivat wrote: > >> >> >> On 5/20/2011 8:48 AM, DOLLY, MARTIN C (ATTSI) wrote: >>> Paul, >>> >>> I do not understand your concern. Please give a REAL life example, not a what if. >> >> To start with, I am having difficulty understanding a use case for when you would *want* to send a sip reason code in a sip response. >> >> The motivation for the Reason header in the first place was to explain why a particular *request* was being sent. >> >> The justification for Q.850 reasons in *responses* is because the sip response codes don't carry all the nuances that the Q.850 codes do. >> >> Suppose I get SIP 486 response with a sip 503 reason code, or a sip 503 response code with a sip 486 reason code. What am I supposed to do with that? What does it *mean*? >> >> Thanks, >> Paul >> >>> Thank you, >>> >>> Martin Dolly >>> Lead Member Technical Staff >>> Core& Government/Regulatory Standards >>> AT&T Services, Inc. >>> md3135@att.com >>> +1-609-903-3360 >>> >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Friday, May 20, 2011 8:45 AM >>> To: R.Jesske@telekom.de >>> Cc: dispatch-chairs@tools.ietf.org; dispatch@ietf.org >>> Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields >>> >>> >>> >>> On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: >>>> Hi Paul, >>>> that was my understanding what Gonzalo proposed. >>>> He wanted to have it described as general approach. Without any restriction to ISUP Causes to be future proof. >>>> >>>> I have this send around a couple weeks ago. Nobody answered and I was in assumption that everybody agreed on this. >>>> Therefore I asked again for the agreement on the change again and what group name (DISPATCH? SIPCORE?) I should use for the next draft. >>>> >>>> I really don't care what way we go as long as we progress the draft properly and get the work done. >>>> >>>> I have 5 for progress with option 1 and one with don't care and you. >>> >>> The concern is that that sip reason codes in sip responses are like >>> having multiple responses to the same request. How should one behave? >>> >>> Fundamentally the problem isn't with the mechanics of delivering the >>> reason - its with the semantics of what has been sent. This has the >>> potential to lead to interoperation problems. >>> >>> We can let the chairs/ADs decide what to do. >>> >>> Thanks, >>> Paul >>> >>>> How to proceed now? >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>>>> Gesendet: Donnerstag, 19. Mai 2011 15:12 >>>>> An: dispatch@ietf.org >>>>> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause >>>>> values in Reason header fields >>>>> >>>>> I am getting confused by all the options mentioned, to the >>>>> point that I >>>>> don't understand what is being proposed now. >>>>> >>>>> It *sounds* like you are proposing to allow *any* reason >>>>> (including sip >>>>> reason codes) in any response. I am concerned that that will cause >>>>> considerable confusion. >>>>> >>>>> I apologize if that is not what you are proposing. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: >>>>>> Dear all, >>>>>> So assuming that there was no comment people are happy with >>>>> the new rewording I would like to prepare a new draft. >>>>>> >>>>>> This would be Option 1: General wording to allow the Reason >>>>> header within responses without any restrictions (except 100 Trying). >>>>>> And nobody wanted to have Option 2: Wording as stated in >>>>> the current draft >>>>>> draft-jesske-dispatch-update3326-reason-responses-02 >>>>>> >>>>>> Agreed? Comments? >>>>>> >>>>>> Thank you and best Regards >>>>>> >>>>>> Roland >>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Jesske, Roland >>>>>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 >>>>>>> An: Jesske, Roland >>>>>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause >>>>>>> values in Reason header fields >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 13, 2011, at 3:18 AM, wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> Since my answer it looks that people would be >>>>>>> OK with the change. >>>>>>> So if no body comments within the next few days >>>>>>> I would prepare a new draft. >>>>>>> >>>>>>> So due to Gonzalo's proposal I would rewrite >>>>>>> the paragraphs as shown below. >>>>>>> For comparison reasons I have added also the >>>>>>> text proposal of the current draft >>>>>>> (draft-jesske-dispatch-update3326-reason-responses-02). >>>>>>> Please indicate which text you would like to >>>>>>> see finally. New proposal or current proposal. >>>>>>> >>>>>>> >>>>>>> 3. RFC3326 1. Introduction >>>>>>> >>>>>>> Original Text: >>>>>>> >>>>>>> Initially, the Reason header field defined >>>>>>> here appears to be most >>>>>>> useful for BYE and CANCEL requests, but it >>>>>>> can appear in any request >>>>>>> within a dialog, in any CANCEL request and in >>>>>>> any response whose >>>>>>> status code explicitly allows the presence of >>>>>>> this header field. >>>>>>> >>>>>>> Note that the Reason header field is usually >>>>>>> not needed in responses >>>>>>> because the status code and the reason phrase >>>>>>> already provide >>>>>>> sufficient information. >>>>>>> >>>>>>> New Text(new proposal): >>>>>>> >>>>>>> Initially, the Reason header field defined >>>>>>> here appears to be most >>>>>>> useful for BYE and CANCEL requests, but it >>>>>>> can appear in any request >>>>>>> within a dialog, in any CANCEL request >>>>>>> independent of the protocol >>>>>>> value used and in any response except 100 trying. >>>>>>> >>>>>>> New Text (text stated in the current draft >>>>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>>>> >>>>>>> Initially, the Reason header field defined >>>>>>> here appears to be most >>>>>>> useful for BYE and CANCEL requests, but it >>>>>>> can appear in any request >>>>>>> within a dialog, in any CANCEL request >>>>>>> independent of the protocol >>>>>>> value used and in any response except 100 >>>>>>> trying if it contains only >>>>>>> a Q.850 Cause Code. >>>>>>> >>>>>>> 4. RFC3326 2. The Reason Header Field >>>>>>> >>>>>>> Original Text >>>>>>> >>>>>>> The Reason header field MAY appear in any >>>>>>> request within a dialog, in >>>>>>> any CANCEL request and in any response whose >>>>>>> status code explicitly >>>>>>> allows the presence of this header field. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jesske& Liess Expires October 2, >>>>>>> 2011 [Page 3] >>>>>>> >>>>>>> Internet-Draft Reason Header >>>>>>> March 2011 >>>>>>> >>>>>>> >>>>>>> New Text(new proposal): >>>>>>> >>>>>>> The Reason header field MAY appear >>>>>>> in any request within a dialog, in any CANCEL >>>>>>> request . The >>>>>>> appearance of the Reason header field is >>>>>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x >>>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>>>> >>>>>>> >>>>>>> New Text(text stated in the current draft >>>>>>> draft-jesske-dispatch-update3326-reason-responses-02): >>>>>>> >>>>>>> The Reason header field only containing a >>>>>>> Q.850 Cause Code MAY appear >>>>>>> in any request within a dialog, in any CANCEL >>>>>>> request . The >>>>>>> appearance of the Reason header field only >>>>>>> containing a Q.850 Cause >>>>>>> Code is applicable to final responses 3xx, >>>>>>> 4xx, 5xx and 6xx and 18x >>>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. >>>>>>> >>>>>>> The Reason header field containing any other >>>>>>> reason value MAY appear >>>>>>> in any request within a dialog, in any CANCEL >>>>>>> request and in any >>>>>>> response whose status code explicitly allows >>>>>>> the presence of this >>>>>>> header field. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> >>>>>>> Roland >>>>>>> >>>>>>> >>>>>>> Deutsche Telekom Netzproduktion GmbH >>>>>>> Fixed Mobile Engineering Deutschland >>>>>>> Roland Jesske >>>>>>> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt >>>>>>> +49 6151 628-2766 (Tel.) >>>>>>> +49 521 9210-3753 (Fax) >>>>>>> +49 171 8618-445 (Mobil) >>>>>>> E-Mail: mailto:r.jesske@telekom.de >>>>>>> http://www.telekom.de >>>>>>> >>>>>>> Erleben, was verbindet. >>>>>>> >>>>>>> Deutsche Telekom Netzproduktion GmbH >>>>>>> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) >>>>>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn >>>>>>> (Vorsitzender), Albert Matheis, Klaus Peren >>>>>>> Handelsregister: Amtsgericht Bonn HRB 14190 >>>>>>> Sitz der Gesellschaft Bonn >>>>>>> USt-IdNr. DE 814645262 >>>>>>> >>>>>>> Große Veränderungen fangen klein an - >>>>>>> Ressourcen schonen und nicht jede E-Mail drucken. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> >>>>>>> >>>>>>> Von: dispatch-bounces@ietf.org >>>>>>> >>>>>>> >>>>>>> [mailto:dispatch-bounces@ietf.org] Im >>>>>>> Auftrag von Jesske, Roland >>>>>>> >>>>>>> >>>>>>> Gesendet: Mittwoch, 6. April 2011 11:24 >>>>>>> >>>>>>> >>>>>>> An: Gonzalo.Camarillo@ericsson.com; >>>>>>> dispatch@ietf.org >>>>>>> >>>>>>> >>>>>>> Betreff: Re: [dispatch] SIP responses >>>>>>> carrying Q.850 cause >>>>>>> >>>>>>> >>>>>>> values in Reason header fields >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Gonzalo, >>>>>>> >>>>>>> >>>>>>> I'm OK with your proposal so I could >>>>>>> change it if people >>>>>>> >>>>>>> >>>>>>> would like it. >>>>>>> >>>>>>> >>>>>>> It makes it shorter. >>>>>>> >>>>>>> >>>>>>> The only I would propose to have in is >>>>>>> the explicit >>>>>>> >>>>>>> >>>>>>> mentioning of the Response values due >>>>>>> to the fact that a >>>>>>> >>>>>>> >>>>>>> 100OK or 200OK should not include a >>>>>>> Reason header with a >>>>>>> >>>>>>> >>>>>>> Q.850 Cause Value. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> >>>>>>> Roland Jesske >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> >>>>>>> >>>>>>> Von: dispatch-bounces@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo Camarillo >>>>>>> >>>>>>> >>>>>>> Gesendet: Dienstag, 5. >>>>> April 2011 14:03 >>>>>>> >>>>>>> >>>>>>> An: DISPATCH >>>>>>> >>>>>>> >>>>>>> Betreff: [dispatch] SIP >>>>>>> responses carrying Q.850 cause values >>>>>>> >>>>>>> >>>>>>> in Reason header fields >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> last week in the DISPATCH >>>>>>> session, there was consensus to allow SIP >>>>>>> >>>>>>> >>>>>>> responses to carry Reason >>>>>>> header fields with Q.850 cause >>>>>>> >>>>>>> >>>>>>> values. As I >>>>>>> >>>>>>> >>>>>>> said some time ago, I am >>>>>>> willing to AD sponsor this draft >>>>>>> >>>>>>> >>>>>>> if/when the >>>>>>> >>>>>>> >>>>>>> DISPATCH chairs confirm such >>>>>>> consensus on the list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In the mean time, I have some >>>>>>> comments on how to document >>>>>>> >>>>>>> >>>>>>> this decision. >>>>>>> >>>>>>> >>>>>>> The following (fairly short) >>>>>>> draft updates a couple of >>>>>>> >>>>>>> >>>>>>> paragraphs in RFC >>>>>>> >>>>>>> >>>>>>> 3326 in order to achieve the >>>>>>> desired outcome: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason >>>>>>> -responses-02.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think this is not a >>>>>>> particularly elegant way to define >>>>>>> >>>>>>> >>>>>>> what we want. >>>>>>> >>>>>>> >>>>>>> For example, if we wanted to >>>>>>> define a solution to HERFP in >>>>>>> >>>>>>> >>>>>>> the future >>>>>>> >>>>>>> >>>>>>> based on the Reason header, we >>>>>>> would need to update those paragraphs >>>>>>> >>>>>>> >>>>>>> again, making them longer every >>>>>>> time we added a new use case. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Instead, I would prefer to >>>>>>> explicitly define what we want >>>>>>> >>>>>>> >>>>>>> to do and be >>>>>>> >>>>>>> >>>>>>> done with it. Such a (also >>>>>>> fairly short) draft would say >>>>>>> >>>>>>> >>>>>>> something along >>>>>>> >>>>>>> >>>>>>> the following lines: >>>>>>> >>>>>>> >>>>>>> >>>>>>> "RFC 3326 allows the presence >>>>>>> of the Reason header field in >>>>>>> >>>>>>> >>>>>>> any response >>>>>>> >>>>>>> >>>>>>> whose status code explicitly >>>>>>> allows its presence. This document >>>>>>> >>>>>>> >>>>>>> explicitly allows any SIP >>>>>>> response to carry a Reason header >>>>>>> >>>>>>> >>>>>>> field with a >>>>>>> >>>>>>> >>>>>>> Q.850 cause value. SIP >>>>>>> responses with Reason header fields carrying >>>>>>> >>>>>>> >>>>>>> values other than Q.850 cause >>>>>>> values are outside of the >>>>>>> >>>>>>> >>>>>>> scope of this >>>>>>> >>>>>>> >>>>>>> document." >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would like to know the >>>>>>> opinion of the WG on this matter >>>>>>> >>>>>>> >>>>>>> (i.e., how to >>>>>>> >>>>>>> >>>>>>> document the WG's consensus). >>>>>>> Note that reaching consensus was the >>>>>>> >>>>>>> >>>>>>> difficult part. Agreeing on how >>>>>>> to document it should be easy. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> >>>>>>> dispatch mailing list >>>>>>> >>>>>>> >>>>>>> dispatch@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>>>> >>>>>>> >>>>>>> dispatch mailing list >>>>>>> >>>>>>> >>>>>>> dispatch@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dispatch mailing list >>>>>>> dispatch@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 eckelcu@cisco.com Mon May 23 16:51:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091CBE07C2 for ; Mon, 23 May 2011 16:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.476 X-Spam-Level: X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTIXtXy91u0m for ; Mon, 23 May 2011 16:51:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 769A7E0869 for ; Mon, 23 May 2011 16:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1730; q=dns/txt; s=iport; t=1306194482; x=1307404082; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=eGbKs5nEuiNU/u3NmtdLqW794TvmSSgqq/Fqk9/pFUA=; b=OqWsqCUyMfwjXwL25+tf0PpXLykvuERuTHxdpWLsjuFw7MeNv2LhYCTt pftu6I29fjYk9aKPoJ/ZOTYh0Lx+5sh9BI3mVGyyEYmeq9+PTJSp+N43v dLgPKlprpU6Sfa0cOmG78H9MCAPqLJIZduwvrVBBYzi+4Wj2dL3p4vXwG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIIAFXx2k2rRDoI/2dsb2JhbACYII4Cd6gCgR2dcIYZBIZVjgKKYA X-IronPort-AV: E=Sophos;i="4.65,258,1304294400"; d="scan'208";a="702107769" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 23 May 2011 23:47:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4NNlmBc007124 for ; Mon, 23 May 2011 23:47:48 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 May 2011 16:47:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2011 16:47:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to provide update to draft-sandbakken-dispatch-bfcp-udp Thread-Index: AcwZo9HtZKSlpVBASvW5ec0INqTXPw== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 23 May 2011 23:47:48.0774 (UTC) FILETIME=[D26EC460:01CC19A3] Subject: [dispatch] Proposal to provide update to draft-sandbakken-dispatch-bfcp-udp X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 23:51:49 -0000 Problem Statement ----------------- "Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport", draft-sandbakken-dispatch-bfcp-udp, extends the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details a set of revisions to the protocol definition document and the specification of Session Description Protocol (SDP) format for BFCP streams. The latest update to this draft, draft-sandbakken-dispatch-bfcp-udp-01, has expired. It is currently available at http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-01. Charter Proposal ---------------- I am not prosing a new working group for this. Rather, I would like make an official proposal to update the draft to address the concerns raised previously on the mailing list as well as when the draft was presented at IETF 79. Provided this is done within the timeframe outlined for the DISPATCH working group, I would like to ask to present the updated draft within DISPATCH at IEFT 81. Next steps can be discussed at or following IETF 81. The motivation for using an unreliable transport for BFCP [RFC4582] messages is fuelled by network deployments where RTP proxies or media relays are present for NAT and firewall traversal. In these deployments, the previous draft claimed TCP may neither be applicable nor appropriate. This claim needs to be better explained and researched as part of the aforementioned update. Goals and Milestones -------------------- July 2011 Update to draft-sandbakken-dispatch-bfcp-udp addressing concerns=20 raised previously July 2011 Present update to draft-sandbakken-dispatch-bfcp-udp at IETF 81 Cheers, Charles From christer.holmberg@ericsson.com Mon May 23 23:42:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91C7E06B2 for ; Mon, 23 May 2011 23:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKW7RYfOHxQW for ; Mon, 23 May 2011 23:42:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6A543E0692 for ; Mon, 23 May 2011 23:42:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-55-4ddb5354d663 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F3.0B.20773.4535BDD4; Tue, 24 May 2011 08:42:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 24 May 2011 08:42:25 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 24 May 2011 08:42:25 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwZjd6OpqFJSaegQauJpUsH++dKqAAT8Y3A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E216788@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se> <4DDACD4B.4050305@cisco.com> In-Reply-To: <4DDACD4B.4050305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 06:42:31 -0000 Hi, >Yes, we have been around that track a few times, and I'm ok >with that case. Its independent of the other changes being >proposed (unless they tread on the clause it depends upon.) > >My concern was with allowing sip reason codes in all >responses. And I think maybe Cullen is asking about the >semantics of Q.850 codes in responses. Ok. I thought we were talking explicitly about sip reason codes. Sorry for the mess. Regards, Christer > On 5/23/2011 4:18 PM, Christer Holmberg wrote: > > > > Hi, > > > > 199 responses is a real-life example. > > > > A couple of days I suggested that we allow Reason headers > with SIP response codes in SIP responses only if explicitly > allowed for the response code of the SIP response. > > > > And, if we agree to such way forward we don't need to > specify anything new, because it's already allowed in RFC 3326: > > > > "The Reason header field MAY appear in any request > within a dialog, in > > any CANCEL request and in any response whose status > code explicitly > > allows the presence of this header field." > > > > Regards, > > > > Christer > > > > ________________________________________ > > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] > On Behalf > > Of Cullen Jennings [fluffy@cisco.com] > > Sent: Monday, May 23, 2011 9:30 PM > > To: Paul Kyzivat > > Cc: DISPATCH list > > Subject: Re: [dispatch] SIP responses carrying Q.850 cause > values in Reason header fields > > > > It's pretty clear that we won't have interoperable systems > unless the draft clearly says what to do in these cases. And > I would like to +1 Martin's request for a real life example > for any of this work. Please could the authors of the draft > give us a real life example of how this all gets used in an > itneroperable way. > > > > > > On May 20, 2011, at 7:04 AM, Paul Kyzivat wrote: > > > >> > >> > >> On 5/20/2011 8:48 AM, DOLLY, MARTIN C (ATTSI) wrote: > >>> Paul, > >>> > >>> I do not understand your concern. Please give a REAL life > example, not a what if. > >> > >> To start with, I am having difficulty understanding a use > case for when you would *want* to send a sip reason code in a > sip response. > >> > >> The motivation for the Reason header in the first place > was to explain why a particular *request* was being sent. > >> > >> The justification for Q.850 reasons in *responses* is > because the sip response codes don't carry all the nuances > that the Q.850 codes do. > >> > >> Suppose I get SIP 486 response with a sip 503 reason code, > or a sip 503 response code with a sip 486 reason code. What > am I supposed to do with that? What does it *mean*? > >> > >> Thanks, > >> Paul > >> > >>> Thank you, > >>> > >>> Martin Dolly > >>> Lead Member Technical Staff > >>> Core& Government/Regulatory Standards > >>> AT&T Services, Inc. > >>> md3135@att.com > >>> +1-609-903-3360 > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] > >>> On Behalf Of Paul Kyzivat > >>> Sent: Friday, May 20, 2011 8:45 AM > >>> To: R.Jesske@telekom.de > >>> Cc: dispatch-chairs@tools.ietf.org; dispatch@ietf.org > >>> Subject: Re: [dispatch] SIP responses carrying Q.850 > cause values in > >>> Reason header fields > >>> > >>> > >>> > >>> On 5/20/2011 3:51 AM, R.Jesske@telekom.de wrote: > >>>> Hi Paul, > >>>> that was my understanding what Gonzalo proposed. > >>>> He wanted to have it described as general approach. > Without any restriction to ISUP Causes to be future proof. > >>>> > >>>> I have this send around a couple weeks ago. Nobody > answered and I was in assumption that everybody agreed on this. > >>>> Therefore I asked again for the agreement on the change > again and what group name (DISPATCH? SIPCORE?) I should use > for the next draft. > >>>> > >>>> I really don't care what way we go as long as we > progress the draft properly and get the work done. > >>>> > >>>> I have 5 for progress with option 1 and one with don't > care and you. > >>> > >>> The concern is that that sip reason codes in sip > responses are like > >>> having multiple responses to the same request. How should > one behave? > >>> > >>> Fundamentally the problem isn't with the mechanics of > delivering the > >>> reason - its with the semantics of what has been sent. > This has the > >>> potential to lead to interoperation problems. > >>> > >>> We can let the chairs/ADs decide what to do. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> How to proceed now? > >>>> > >>>> Best Regards > >>>> > >>>> Roland > >>>> > >>>> > >>>>> -----Urspr=FCngliche Nachricht----- > >>>>> Von: dispatch-bounces@ietf.org > >>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat > >>>>> Gesendet: Donnerstag, 19. Mai 2011 15:12 > >>>>> An: dispatch@ietf.org > >>>>> Betreff: Re: [dispatch] SIP responses carrying Q.850 > cause values > >>>>> in Reason header fields > >>>>> > >>>>> I am getting confused by all the options mentioned, to > the point > >>>>> that I don't understand what is being proposed now. > >>>>> > >>>>> It *sounds* like you are proposing to allow *any* reason > >>>>> (including sip reason codes) in any response. I am > concerned that > >>>>> that will cause considerable confusion. > >>>>> > >>>>> I apologize if that is not what you are proposing. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> On 5/19/2011 3:58 AM, R.Jesske@telekom.de wrote: > >>>>>> Dear all, > >>>>>> So assuming that there was no comment people are happy with > >>>>> the new rewording I would like to prepare a new draft. > >>>>>> > >>>>>> This would be Option 1: General wording to allow the Reason > >>>>> header within responses without any restrictions > (except 100 Trying). > >>>>>> And nobody wanted to have Option 2: Wording as stated in > >>>>> the current draft > >>>>>> draft-jesske-dispatch-update3326-reason-responses-02 > >>>>>> > >>>>>> Agreed? Comments? > >>>>>> > >>>>>> Thank you and best Regards > >>>>>> > >>>>>> Roland > >>>>>> > >>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>> Von: Jesske, Roland > >>>>>>> Gesendet: Donnerstag, 19. Mai 2011 09:50 > >>>>>>> An: Jesske, Roland > >>>>>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause > >>>>>>> values in Reason header fields > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On May 13, 2011, at 3:18 > AM, wrote: > >>>>>>> > >>>>>>> > >>>>>>> Hi, > >>>>>>> Since my answer it looks that people would be OK with the > >>>>>>> change. > >>>>>>> So if no body comments within the next few days I > would prepare > >>>>>>> a new draft. > >>>>>>> > >>>>>>> So due to Gonzalo's proposal I would rewrite the > paragraphs as > >>>>>>> shown below. > >>>>>>> For comparison reasons I have added also the text proposal of > >>>>>>> the current draft > >>>>>>> (draft-jesske-dispatch-update3326-reason-responses-02). > >>>>>>> Please indicate which text you would like to see finally. New > >>>>>>> proposal or current proposal. > >>>>>>> > >>>>>>> > >>>>>>> 3. RFC3326 1. Introduction > >>>>>>> > >>>>>>> Original Text: > >>>>>>> > >>>>>>> Initially, the Reason header field defined here > appears to > >>>>>>> be most > >>>>>>> useful for BYE and CANCEL requests, but it can appear in > >>>>>>> any request > >>>>>>> within a dialog, in any CANCEL request and in > any response > >>>>>>> whose > >>>>>>> status code explicitly allows the presence of > this header > >>>>>>> field. > >>>>>>> > >>>>>>> Note that the Reason header field is usually not > needed in > >>>>>>> responses > >>>>>>> because the status code and the reason phrase already > >>>>>>> provide > >>>>>>> sufficient information. > >>>>>>> > >>>>>>> New Text(new proposal): > >>>>>>> > >>>>>>> Initially, the Reason header field defined here > appears to > >>>>>>> be most > >>>>>>> useful for BYE and CANCEL requests, but it can appear in > >>>>>>> any request > >>>>>>> within a dialog, in any CANCEL request > independent of the > >>>>>>> protocol > >>>>>>> value used and in any response except 100 trying. > >>>>>>> > >>>>>>> New Text (text stated in the current draft > >>>>>>> draft-jesske-dispatch-update3326-reason-responses-02): > >>>>>>> > >>>>>>> Initially, the Reason header field defined here > appears to > >>>>>>> be most > >>>>>>> useful for BYE and CANCEL requests, but it can appear in > >>>>>>> any request > >>>>>>> within a dialog, in any CANCEL request independent of the > >>>>>>> protocol > >>>>>>> value used and in any response except 100 trying if it > >>>>>>> contains only > >>>>>>> a Q.850 Cause Code. > >>>>>>> > >>>>>>> 4. RFC3326 2. The Reason Header Field > >>>>>>> > >>>>>>> Original Text > >>>>>>> > >>>>>>> The Reason header field MAY appear in any > request within a > >>>>>>> dialog, in > >>>>>>> any CANCEL request and in any response whose status code > >>>>>>> explicitly > >>>>>>> allows the presence of this header field. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Jesske& Liess Expires October 2, > >>>>>>> 2011 [Page 3] > >>>>>>> > >>>>>>> Internet-Draft Reason Header > >>>>>>> March 2011 > >>>>>>> > >>>>>>> > >>>>>>> New Text(new proposal): > >>>>>>> > >>>>>>> The Reason header field MAY appear > >>>>>>> in any request within a dialog, in any CANCEL request . > >>>>>>> The > >>>>>>> appearance of the Reason header field is applicable to > >>>>>>> final responses 3xx, 4xx, 5xx and 6xx and 18x > >>>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. > >>>>>>> > >>>>>>> > >>>>>>> New Text(text stated in the current draft > >>>>>>> draft-jesske-dispatch-update3326-reason-responses-02): > >>>>>>> > >>>>>>> The Reason header field only containing a Q.850 > Cause Code > >>>>>>> MAY appear > >>>>>>> in any request within a dialog, in any CANCEL request . > >>>>>>> The > >>>>>>> appearance of the Reason header field only containing a > >>>>>>> Q.850 Cause > >>>>>>> Code is applicable to final responses 3xx, 4xx, > 5xx and 6xx > >>>>>>> and 18x > >>>>>>> and 199 provisional responses [I-D.ietf-sipcore-199]. > >>>>>>> > >>>>>>> The Reason header field containing any other > reason value > >>>>>>> MAY appear > >>>>>>> in any request within a dialog, in any CANCEL > request and > >>>>>>> in any > >>>>>>> response whose status code explicitly allows the > presence > >>>>>>> of this > >>>>>>> header field. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Best Regards > >>>>>>> > >>>>>>> > >>>>>>> Roland > >>>>>>> > >>>>>>> > >>>>>>> Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering > >>>>>>> Deutschland 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: mailto:r.jesske@telekom.de http://www.telekom.de > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>> > >>>>>>> > >>>>>>> Von: dispatch-bounces@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> > [mailto:dispatch-bounces@ietf.org] Im > >>>>>>> Auftrag von Jesske, Roland > >>>>>>> > >>>>>>> > >>>>>>> Gesendet: Mittwoch, 6. April > 2011 11:24 > >>>>>>> > >>>>>>> > >>>>>>> An: Gonzalo.Camarillo@ericsson.com; > >>>>>>> dispatch@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> Betreff: Re: [dispatch] SIP > responses > >>>>>>> carrying Q.850 cause > >>>>>>> > >>>>>>> > >>>>>>> values in Reason header fields > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Hi Gonzalo, > >>>>>>> > >>>>>>> > >>>>>>> I'm OK with your proposal so I could > >>>>>>> change it if people > >>>>>>> > >>>>>>> > >>>>>>> would like it. > >>>>>>> > >>>>>>> > >>>>>>> It makes it shorter. > >>>>>>> > >>>>>>> > >>>>>>> The only I would propose to > have in is > >>>>>>> the explicit > >>>>>>> > >>>>>>> > >>>>>>> mentioning of the Response > values due > >>>>>>> to the fact that a > >>>>>>> > >>>>>>> > >>>>>>> 100OK or 200OK should not include a > >>>>>>> Reason header with a > >>>>>>> > >>>>>>> > >>>>>>> Q.850 Cause Value. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Best Regards > >>>>>>> > >>>>>>> > >>>>>>> Roland Jesske > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Urspr=FCngliche > >>>>>>> Nachricht----- > >>>>>>> > >>>>>>> > >>>>>>> Von: > dispatch-bounces@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> [mailto:dispatch-bounces@ietf.org] Im Auftrag von Gonzalo > >>>>>>> Camarillo > >>>>>>> > >>>>>>> > >>>>>>> Gesendet: Dienstag, 5. > >>>>> April 2011 14:03 > >>>>>>> > >>>>>>> > >>>>>>> An: DISPATCH > >>>>>>> > >>>>>>> > >>>>>>> Betreff: [dispatch] SIP > >>>>>>> responses carrying Q.850 cause values > >>>>>>> > >>>>>>> > >>>>>>> in Reason header fields > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> last week in the DISPATCH > >>>>>>> session, there was consensus to allow SIP > >>>>>>> > >>>>>>> > >>>>>>> responses to carry Reason > >>>>>>> header fields with Q.850 cause > >>>>>>> > >>>>>>> > >>>>>>> values. As I > >>>>>>> > >>>>>>> > >>>>>>> said some time ago, I am > >>>>>>> willing to AD sponsor this draft > >>>>>>> > >>>>>>> > >>>>>>> if/when the > >>>>>>> > >>>>>>> > >>>>>>> DISPATCH chairs confirm such > >>>>>>> consensus on the list. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In the mean time, I > have some > >>>>>>> comments on how to document > >>>>>>> > >>>>>>> > >>>>>>> this decision. > >>>>>>> > >>>>>>> > >>>>>>> The following (fairly short) > >>>>>>> draft updates a couple of > >>>>>>> > >>>>>>> > >>>>>>> paragraphs in RFC > >>>>>>> > >>>>>>> > >>>>>>> 3326 in order to achieve the > >>>>>>> desired outcome: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason > >>>>>>> -responses-02.txt > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I think this is not a > >>>>>>> particularly elegant way to define > >>>>>>> > >>>>>>> > >>>>>>> what we want. > >>>>>>> > >>>>>>> > >>>>>>> For example, if we wanted to > >>>>>>> define a solution to HERFP in > >>>>>>> > >>>>>>> > >>>>>>> the future > >>>>>>> > >>>>>>> > >>>>>>> based on the Reason > header, we > >>>>>>> would need to update those paragraphs > >>>>>>> > >>>>>>> > >>>>>>> again, making them > longer every > >>>>>>> time we added a new use case. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Instead, I would prefer to > >>>>>>> explicitly define what we want > >>>>>>> > >>>>>>> > >>>>>>> to do and be > >>>>>>> > >>>>>>> > >>>>>>> done with it. Such a (also > >>>>>>> fairly short) draft would say > >>>>>>> > >>>>>>> > >>>>>>> something along > >>>>>>> > >>>>>>> > >>>>>>> the following lines: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> "RFC 3326 allows the > presence > >>>>>>> of the Reason header field in > >>>>>>> > >>>>>>> > >>>>>>> any response > >>>>>>> > >>>>>>> > >>>>>>> whose status code explicitly > >>>>>>> allows its presence. This document > >>>>>>> > >>>>>>> > >>>>>>> explicitly allows any SIP > >>>>>>> response to carry a Reason header > >>>>>>> > >>>>>>> > >>>>>>> field with a > >>>>>>> > >>>>>>> > >>>>>>> Q.850 cause value. SIP > >>>>>>> responses with Reason header fields carrying > >>>>>>> > >>>>>>> > >>>>>>> values other than > Q.850 cause > >>>>>>> values are outside of the > >>>>>>> > >>>>>>> > >>>>>>> scope of this > >>>>>>> > >>>>>>> > >>>>>>> document." > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I would like to know the > >>>>>>> opinion of the WG on this matter > >>>>>>> > >>>>>>> > >>>>>>> (i.e., how to > >>>>>>> > >>>>>>> > >>>>>>> document the WG's consensus). > >>>>>>> Note that reaching consensus was the > >>>>>>> > >>>>>>> > >>>>>>> difficult part. > Agreeing on how > >>>>>>> to document it should be easy. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Gonzalo > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> > >>>>>>> > >>>>>>> dispatch mailing list > >>>>>>> > >>>>>>> > >>>>>>> dispatch@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> _______________________________________________ > >>>>>>> > >>>>>>> > >>>>>>> dispatch mailing list > >>>>>>> > >>>>>>> > >>>>>>> dispatch@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ > >>>>>>> dispatch mailing list > >>>>>>> dispatch@ietf.org > >>>>>>> > https://www.ietf.org/mailman/listinfo/dispatch > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 R.Jesske@telekom.de Tue May 24 06:31:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E89E074C for ; Tue, 24 May 2011 06:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wra8nSE+Pd6 for ; Tue, 24 May 2011 06:30:57 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 31B42E06BA for ; Tue, 24 May 2011 06:30:57 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 24 May 2011 15:30:48 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 24 May 2011 15:30:48 +0200 From: To: Date: Tue, 24 May 2011 15:30:47 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwZjd6OpqFJSaegQauJpUsH++dKqAAT8Y3AAA3ZU5A= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB47C5@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se> <4DDACD4B.4050305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E216788@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E216788@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:31:00 -0000 Dear all, after messing up the whole group with the discussion in how to finalise Dra= ft. I went back to some proposals within the past. I don't care if we generalise it or restrict it to Q.850. As long as we get= the work done. After the whole discussion within the last days I at least came to the resu= lt to restrict it to Q.850 causes. So I have two proposals. 1. As it is defined within http://www.ietf.org/id/draft-jesske-dispatch-upd= ate3326-reason-responses-02.txt 2. Instead of having an update of Section 1 and 2 in RFC3326 only stating. "RFC 3326 allows the presence of the Reason header field in any response whose status code explicitly allows its presence. This document explicitly allows any SIP response to carry a Reason header field with a Q.850 cause value. SIP responses with Reason header fields carrying values other than Q.850 cause values are outside of the scope of this document." Please comment and vote for one of the both. Thank you and Best Regards Roland From thomas.belling@nsn.com Tue May 24 06:43:16 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D0E06AF for ; Tue, 24 May 2011 06:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEStkDgV-MhP for ; Tue, 24 May 2011 06:43:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D7011E068D for ; Tue, 24 May 2011 06:43:15 -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 p4ODhElm003375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2011 15:43:14 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4ODhEF5015848; Tue, 24 May 2011 15:43:14 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 15:43: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: Tue, 24 May 2011 15:43:11 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F29E8BB@DEMUEXC014.nsn-intra.net> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB47C5@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwZjd6OpqFJSaegQauJpUsH++dKqAAT8Y3AAA3ZU5AAALpOgA== References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se><4DDACD4B.4050305@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585194E216788@ESESSCMS0356.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB47C5@HE111648.emea1.cds.t-internal.com> From: "Belling, Thomas (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 24 May 2011 13:43:13.0831 (UTC) FILETIME=[874B7B70:01CC1A18] Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:43:16 -0000 Hi Roland, I would slightly prefer your new proposal 2 but could also accept your new proposal 1. Differences are minor and a matter of taste. What really counts is that this draft is finalized. Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext R.Jesske@telekom.de Sent: Tuesday, May 24, 2011 3:31 PM To: dispatch@ietf.org Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Dear all, after messing up the whole group with the discussion in how to finalise Draft. I went back to some proposals within the past. I don't care if we generalise it or restrict it to Q.850. As long as we get the work done. After the whole discussion within the last days I at least came to the result to restrict it to Q.850 causes. So I have two proposals. 1. As it is defined within http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason-responses -02.txt 2. Instead of having an update of Section 1 and 2 in RFC3326 only stating. "RFC 3326 allows the presence of the Reason header field in any response whose status code explicitly allows its presence. This document explicitly allows any SIP response to carry a Reason header field with a Q.850 cause value. SIP responses with Reason header fields carrying values other than Q.850 cause values are outside of the scope of this document." Please comment and vote for one of the both. Thank you and Best Regards Roland _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Tue May 24 06:50:46 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B0E0752 for ; Tue, 24 May 2011 06:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7Bp56x9IvNu for ; Tue, 24 May 2011 06:50:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 00700E06AF for ; Tue, 24 May 2011 06:50:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f1-4ddbb7b31120 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E9.93.20773.3B7BBDD4; Tue, 24 May 2011 15:50:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 24 May 2011 15:50:40 +0200 From: Christer Holmberg To: "Belling, Thomas (NSN - DE/Munich)" , "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Tue, 24 May 2011 15:50:39 +0200 Thread-Topic: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields Thread-Index: AcwZjd6OpqFJSaegQauJpUsH++dKqAAT8Y3AAA3ZU5AAALpOgAAAW9NA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E216B73@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3C5@ESESSCMS0356.eemea.ericsson.se><4DDACD4B.4050305@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585194E216788@ESESSCMS0356.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB47C5@HE111648.emea1.cds.t-internal.com> <1A8A7D59006A8240B27FF63C794CA57F29E8BB@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F29E8BB@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:50:46 -0000 Hi, I also support proposal 2), but would not object to 1). I just want to get this done. Regards, Christer=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Belling,=20 > Thomas (NSN - DE/Munich) > Sent: 24. toukokuuta 2011 16:43 > To: R.Jesske@telekom.de; dispatch@ietf.org > Subject: Re: [dispatch] SIP responses carrying Q.850 cause=20 > values in Reason header fields >=20 > Hi Roland, >=20 > I would slightly prefer your new proposal 2 but could also=20 > accept your new proposal 1. >=20 > Differences are minor and a matter of taste. >=20 > What really counts is that this draft is finalized. >=20 > Thomas >=20 >=20 >=20 > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks=20 >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of ext=20 > R.Jesske@telekom.de > Sent: Tuesday, May 24, 2011 3:31 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] SIP responses carrying Q.850 cause=20 > values in Reason header fields >=20 > Dear all, > after messing up the whole group with the discussion in how=20 > to finalise Draft. > I went back to some proposals within the past. > I don't care if we generalise it or restrict it to Q.850. As=20 > long as we get the work done. > After the whole discussion within the last days I at least=20 > came to the result to restrict it to Q.850 causes. >=20 > So I have two proposals. >=20 > 1. As it is defined within > http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason -responses > -02.txt >=20 > 2. Instead of having an update of Section 1 and 2 in RFC3326=20 > only stating. >=20 > "RFC 3326 allows the presence of the Reason header field in=20 > any response whose status code explicitly allows its=20 > presence. This document explicitly allows any SIP response to=20 > carry a Reason header field with a Q.850 cause value. SIP=20 > responses with Reason header fields carrying values other=20 > than Q.850 cause values are outside of the scope of this document." >=20 > Please comment and vote for one of the both. >=20 >=20 > Thank you and Best Regards >=20 > Roland >=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 marianne.mohali@orange-ftgroup.com Tue May 24 10:22:42 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0609C13000C for ; Tue, 24 May 2011 10:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpdyRL4K7VJQ for ; Tue, 24 May 2011 10:22:41 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 597BB13001A for ; Tue, 24 May 2011 10:22:38 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0DDD873801A; Tue, 24 May 2011 19:23:53 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 023C66D8004; Tue, 24 May 2011 19:23:53 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 19:22:37 +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, 24 May 2011 19:22:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications Thread-Index: AcwaMdSnr4VEDUaRSiW1XMALaAd9RQAAJjvgAADu+rA= From: To: , , X-OriginalArrivalTime: 24 May 2011 17:22:37.0053 (UTC) FILETIME=[2D2FC2D0:01CC1A37] Subject: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:22:42 -0000 Hi, I am not proposing a new working group but trying to find the good place to solve the following problem. Problem Statment ---------------- Decisions made by one application about how to handle a session often depend on which other types of applications are involved in this session. Hence, in the context of SIP, when several remote applications are involved in the processing of one session, there is a need for a mechanism enabling one application to explicitly identify itself when issuing or re-targeting a request or response. This will enable applications receiving this information to take appropriate decisions on how to further process the session. 1. Need to convey the identity of the application having "acted" on the call, in order to allow a downstream application to avoid undesirable service interactions (e.g. by deciding whether to execute a particular feature depending on the call history). 2. Need to convey the identity of the application having caused a specific number translation and allow the transfer target to easily find out the original number that this application had received, even in case multiple successive number translations occured. 3. Need to convey the identity of the application having released the call towards an upstream application that can take specific decisions. The draft is available at http://tools.ietf.org/html/draft-mohali-dispatch-reason-for-applications -00 Charter proposal ---------------- The Reason header field [RFC3326] provides a mechanism to signal the reason why a SIP request or response was issued or why an initial request was retargeted. I-D draft-mohali-dispatch-reason-for-applications proposes to extend RFC3326 registering a new protocol value "Application" for the Reason Header field and a for registering application types (cause values). The extension process is similar to RFC4411 that also extend the Reason header. This protocol value can be used anywhere the presence of a Reason Header field is allowed. For each new registered value, it has to be defined the following: - Cause value: this is an identifier number corresponding to the cause value of the protocol-cause parameter in the Reason header field. - Reason text: this is a unique string identifying the application name. The reason text is intended to give a short textual description of the application. - Description: this is a description of the application and the conditions under which this reason-value is used.=20 =20 The work consist in extending RFC3326 (Reason header) for applications needs. Goals and Milestones -------------------- July 2011 Update to draft-mohali-dispatch-reason-for-applications addressing concerns raised in the mailing list July 2011 Present update to draft-mohali-dispatch-reason-for-applications at IETF 81 Nov 2011 Present update to draft-mohali-dispatch-reason-for-applications at IETF 82 Mar 2012 Submit draft-mohali-dispatch-reason-for-applications to IESG as Proposed Standard RFC =20 Best Regards, Marianne =20 From bruno.chatras@orange-ftgroup.com Tue May 24 10:29:55 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1A4E06AE for ; Tue, 24 May 2011 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVvr1fiM0vmD for ; Tue, 24 May 2011 10:29:54 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCB90E067F for ; Tue, 24 May 2011 10:29:53 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E252173801A; Tue, 24 May 2011 19:31:08 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id CEA2B6D8004; Tue, 24 May 2011 19:31:08 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 19:29:52 +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_01CC1A38.307DBCFD" Date: Tue, 24 May 2011 19:29:51 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal Thread-Index: AcwZVtBeNaZm1dRbQuqPlztWqYWALQAA7TCwADcJ4MA= References: From: To: , X-OriginalArrivalTime: 24 May 2011 17:29:52.0944 (UTC) FILETIME=[30FF7300:01CC1A38] Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:29:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1A38.307DBCFD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 1 comment and 1 question =20 Comment: In the list of considerations that must be taken into account I = would add =AB Whether the load balancer is SIP-aware or not. =20 Question: Is the Charter intended to cover architectures with an in-path = load balancer in front of a farm of SIP servers only or is it expected = to cover as well other architectures where the load balancer is off-path = or even architectures where load balancing just relies on frequent = updates of the DNS? =20 Bruno =20 =20 =20 =20 De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la = part de Parthasarathi R (partr) Envoy=E9 : lundi 23 mai 2011 17:04 =C0 : dispatch@ietf.org Objet : [dispatch] SIP Load balancing (SIPLB) Charter proposal =20 Hi all, =20 Charter proposal for SIP load balancing (SIPLB) is written in this mail = to create a new WG related to SIP based load balancing. =20 There are lot of interest in SIP load balancing work during the time of = IETF-80 and the side meeting leads to the creation of this charter. = There are lot of draft submitted in Dispatch related to this work and = the list is as follows: =20 [1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balanci= ng-00 [2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00 [3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co= ntrol-00 =20 To make the progress in the work, the charter currently focus on two = types of SIP based load balancing namely signaling only SIP load = balancing and Media-related SIP based load balancing.=20 =20 Please provide your value inputs and comments in the below charter. =20 Thanks Vijay/Partha =20 SIP Load balancing (SIPLB) Charter ---------------------------------- =20 Session Load balancing (SIPLB) working group is chartered to define a=20 SIP-based protocol for load balancing SIP sessions. =20 Load balancing across a farm of SIP servers can be done today, but = without=20 generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with=20 varying capabilities, example, a SIP proxy, a back-to-back user agent=20 (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media=20 servers etc. The capabilities and processing capacity on hosts in the = farm=20 may be different, sometimes vastly, from each other. Furthermore, the=20 duration of time that a SIP host requires to process a SIP request=20 may vary. SIP proxies, operating at the transaction layer, may be=20 more efficient at processing transactions than a B2BUA would be,=20 which may need to maintain a long-lived dialogue state in addition to=20 the transaction state. PSTN gateways may have other limitations such=20 as media resources that may be depleted even though the gateway may=20 have enough processing power (i.e., CPU) to handle incoming requests. =20 In face of such diversity, simple load balancing schemes based on=20 round-robin selection tend to work only when many assumptions are met. First, the relative capacity and processing resources of all SIP servers = in the farm should be nearly equal. Furthermore, because a round-robin=20 scheme presents a load of (1/n)*N to each server, where n =3D number of=20 servers and N =3D arrival rate in requests per second, it assumes that=20 the service time at each server is such that the utilization of each=20 server is not negatively impacted (i.e., utilization ratio of the = arrival=20 rate over the mean service rate is less than 1.0). And finally,=20 the round-robin load balancing does not have a backward feedback = mechanism=20 whereby the load-balanced server can inform the load balancer of its=20 current utilization (i.e., round-robin load balancing acts as an = open-loop=20 controller). =20 The SIP load balancing working group is, therefore, chartered to=20 arrive at a load balancing scheme that distributes SIP requests to=20 a collection of servers to effectively utilize the resources at those=20 servers. These resources can include CPU, memory, network bandwidth,=20 input/output, DSP, DS0 or disk resources. The load balancing scheme must prevent excessive oscillation in the collection of servers. =20 In order to achieve such a load balancing scheme in practice, the = following=20 considerations must be taken in account: =20 1) Should the load balancing scheme have a closed-loop model, i.e.,=20 should it report utilization to the load balancer to allow the=20 load balancer to distribute requests proportionally? =20 2) What should the diversity of the SIP hosts in a farm be? Is=20 it reasonable to assume that the same load balancing scheme should=20 be applicable to a pair of SIP servers, one of which can handle=20 an order of magnitude more requests per unit time that the other? =20 3) What information must be provisioned into the load balancer and=20 the servers? =20 4) As SIP request resource consumption in SIP signaling only server=20 varies drastically from SIP media servers, should the solution be=20 split such that load balancing of a pure signaling server is different=20 than that of a SIP server that handles signaling as well as media? =20 The last consideration above is especially important since a solution to load balancing a media farm will require a model where the SIP=20 load balancer is closely coupled with the downstream SIP servers. In such a model, the SIP load balancer knows the resources available at each of the downstream SIP servers and is able to inspect an incoming request to determine its media-related requirements and thus dispatch it to the downstream SIP server that has the highest probability of servicing that request. In some architectures, such a coupling reduces post-dial delay. =20 =20 Keeping the SIP load balancer and the downstream SIP servers=20 loosely coupled suffices for load balancing to a farm of SIP servers that only handle signaling. A loosely coupled model operates purely on the feedback received from the downstream SIP servers and does not require the SIP load balancer to inspect an incoming request. =20 Any solution needs to clearly specify its scope. A solution also=20 needs to clearly state any limitations, in performance or otherwise,=20 the specified load balancing mechanism may have. In particular,=20 the solution shall carefully define the deployment considerations for=20 the effective operation of the specified mechanisms and discuss,=20 for example, when a mechanism requires coordinated deployment and=20 operation (if all servers need to deploy the same mechanism, certain=20 configuration values need to be identical on all servers, etc.), when=20 a mechanism can become less effective or ineffective under some = conditions,=20 or especially if there are cases when a mechanism these considerations=20 is to allow potential deployments to make the best use of these = mechanism in=20 their particular networks. =20 SIPLB Working Group will thoroughly identify use cases, provide example=20 design & system architectures and deployment scenarios, and=20 define requirements. =20 The group will produce: =20 1) Use case and requirement document. 2) A document surveying SIP load balancing strategies in use today. 3) An architecture document showing sample SIP topologies. 4) Specification for SIP based overload scheme applicable to a=20 signaling-only SIP server. 5) Specification for SIP based overload scheme applicable to a media-based SIP server. =20 Goals and Milestones Mar 2012 Survey document for SIP load balancing strategies to IESG as an Informational document. Jun 2012 Use cases and requirement document to IESG as an Informational document. Aug 2012 Design & Architecture to IESG as Informational RFC Feb 2013 Submit signaling based SIP overload solution to IESG as=20 Proposed Standard RFC=20 Feb 2013 Submit signaling and media based SIP overload solution to=20 IESG as Proposed Standard RFC=20 ------_=_NextPart_001_01CC1A38.307DBCFD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

1 comment and 1 question

 

Comment: In the list of considerations that must be taken = into account I would add =AB Whether the load balancer is SIP-aware or = not.

 

Question: Is the Charter intended to cover architectures = with an in-path load balancer in front of a farm of SIP servers only or is it = expected to cover as well other architectures where the load balancer is off-path = or even architectures where load balancing just relies on frequent updates = of the DNS?

 

Bruno

 

 

 

 

De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la = part de Parthasarathi R (partr)
Envoy=E9 : lundi 23 mai 2011 17:04
=C0 : dispatch@ietf.org
Objet : [dispatch] SIP Load balancing (SIPLB) Charter = proposal

 

Hi all,

 

Charter proposal for SIP load balancing (SIPLB) is written in this mail to = create a new WG related to SIP based load balancing.

 

There are lot of interest in SIP load balancing work during the time of = IETF-80 and the side meeting leads to the creation of this charter. There are lot of = draft submitted in Dispatch related to this work and the list is as = follows:

 

[1]http://too= ls.ietf.org/html/draft-bessis-dispatch-adaptive-load-balancing-00
[2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00
[3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co= ntrol-00

 

To make the progress in the work, the charter currently focus on two = types of SIP based load balancing namely signaling only SIP load balancing and = Media-related SIP based load balancing.

 

Please provide your value inputs and comments in the = below charter.

 

Thanks=

Vijay/Partha<= /span>

 

SIP Load balancing (SIPLB) Charter
----------------------------------
 
Session Load balancing (SIPLB) working group is chartered to define a =
SIP-based protocol for load balancing SIP sessions.
 
Load balancing across a farm of SIP servers can be done today, but = without
generally agreed upon principles on how to best do accomplish this.
Confounding the problem is that a SIP farm may consist of hosts with =
varying capabilities, example, a SIP proxy, a back-to-back user agent =
(B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media =
servers etc. The capabilities and processing capacity on hosts in the = farm
may be different, sometimes vastly, from each other.  Furthermore, = the
duration of time that a SIP host requires to process a SIP request
may vary. SIP proxies, operating at the transaction layer, may be
more efficient at processing transactions than a B2BUA would be,
which may need to maintain a long-lived dialogue state in addition to =
the transaction state.  PSTN gateways may have other limitations = such
as media resources that may be depleted even though the gateway may
have enough processing power (i.e., CPU) to handle incoming = requests.
 
In face of such diversity, simple load balancing schemes based on
round-robin selection tend to work only when many assumptions are = met.
First, the relative capacity and processing resources of all SIP servers =
in the farm should be nearly equal.  Furthermore, because a = round-robin
scheme presents a load of (1/n)*N to each server, where n =3D number of =
servers and N =3D arrival rate in requests per second, it assumes that =
the service time at each server is such that the utilization of each =
server is not negatively impacted (i.e., utilization ratio of the = arrival
rate over the mean service rate is less than 1.0).  And finally, =
the round-robin load balancing does not have a backward feedback = mechanism
whereby the load-balanced server can inform the load balancer of its =
current utilization (i.e., round-robin load balancing acts as an = open-loop
controller).
 
The SIP load balancing working group is, therefore, chartered to
arrive at a load balancing scheme that distributes SIP requests to
a collection of servers to effectively utilize the resources at those =
servers. These resources can include CPU, memory, network bandwidth, =
input/output, DSP, DS0 or disk resources.  The load balancing
scheme must prevent excessive oscillation in the collection of
servers.

 

In order to achieve such a load balancing scheme in practice, the following =
considerations must be taken in account:
 
1) Should the load balancing scheme have a closed-loop model, i.e.,
should it report utilization to the load balancer to allow the
load balancer to distribute requests proportionally?
 
2) What should the diversity of the SIP hosts in a farm be?  Is =
it reasonable to assume that the same load balancing scheme should
be applicable to a pair of SIP servers, one of which can handle
an order of magnitude more requests per unit time that the other?
 
3) What information must be provisioned into the load balancer and
the servers?
 
4) As SIP request resource consumption in SIP signaling only server
varies drastically from SIP media servers, should the solution be
split such that load balancing of a pure signaling server is different =
than that of a SIP server that handles signaling as well as media?
 
The last consideration above is especially important since a = solution
to load balancing a media farm will require a model where the SIP
load balancer is closely coupled with the downstream SIP servers.
In such a model, the SIP load balancer knows the resources available
at each of the downstream SIP servers and is able to inspect an
incoming request to determine its media-related requirements and = thus
dispatch it to the downstream SIP server that has the highest
probability of servicing that request.  In some architectures, = such
a coupling reduces post-dial delay. 

 

Keeping the SIP load balancer and the downstream SIP servers
loosely coupled suffices for load balancing to a farm of SIP
servers that only handle signaling.  A loosely coupled model
operates purely on the feedback received from the downstream
SIP servers and does not require the SIP load balancer to inspect
an incoming request.

 

Any solution needs to clearly specify its scope.  A solution also
needs to clearly state any limitations, in performance or otherwise, =
the specified load balancing mechanism may have.  In particular, =
the solution 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 these considerations =
is to allow potential deployments to make the best use of these = mechanism in
their particular networks.
 
SIPLB Working Group will thoroughly identify use cases, provide example =
design & system architectures and deployment scenarios, and
define requirements.
 
The group will produce:
 
1) Use case and requirement document.
2) A document surveying SIP load balancing strategies in use today.
3) An architecture document showing sample SIP topologies.
4) Specification for SIP based overload scheme applicable to a
   signaling-only SIP server.
5) Specification for SIP based overload scheme applicable to a
   media-based SIP server.
 
Goals and Milestones
Mar 2012  Survey document for SIP load balancing strategies to = IESG
          as an = Informational document.
Jun 2012  Use cases and requirement document to IESG as an = Informational
          document.
Aug 2012  Design & Architecture to IESG as Informational = RFC
Feb 2013  Submit signaling based SIP overload solution to IESG as =
          Proposed Standard = RFC
Feb 2013  Submit signaling and media based SIP overload solution to =
          IESG as Proposed Standard RFC

------_=_NextPart_001_01CC1A38.307DBCFD-- From partr@cisco.com Tue May 24 21:23:53 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE24FE0751 for ; Tue, 24 May 2011 21:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGui+Ss9xyhA for ; Tue, 24 May 2011 21:23:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C1269E078C for ; Tue, 24 May 2011 21:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=32798; q=dns/txt; s=iport; t=1306297430; x=1307507030; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=/1RAqpbMlkAi0ax3dpM3arB2wCgGUJB2cJ7ZoWDhrBE=; b=MxLhSn2z45OdxVJZXcfHVOjr0Cf7jTL+Ief6i+YM8eAudDkNtWuW8Yrh q1xI6GugStctCfPvU+gsgaIhtuL+v0L0sZWvKwV5D1DPp3HtMSADoKm9n SFKXzqHrBaVWKggn6USB6k0muMeOLegbx3os3er4ARX5XIR2P60lxRLsz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIBAEyD3E1Io8URgWdsb2JhbACCZpR/jkQUAQEWJiWpIJ1sgxcTgnIEhleODYpP X-IronPort-AV: E=Sophos;i="4.65,265,1304294400"; d="scan'208,217";a="32128563" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 25 May 2011 04:23:48 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4P4NlkP031788; Wed, 25 May 2011 04:23:47 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 09:53:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1A93.8A79B4A4" Date: Wed, 25 May 2011 09:53:46 +0530 Message-ID: In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal Thread-Index: AcwZVtBeNaZm1dRbQuqPlztWqYWALQAA7TCwADcJ4MAAFrdSIA== References: <9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr> From: "Parthasarathi R (partr)" To: , X-OriginalArrivalTime: 25 May 2011 04:23:47.0523 (UTC) FILETIME=[8AA11930:01CC1A93] Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 04:23:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1A93.8A79B4A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, =20 Thanks for your interest in the charter. Please read inline. =20 Thanks Partha ________________________________ From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Tuesday, May 24, 2011 11:00 PM To: Parthasarathi R (partr); dispatch@ietf.org Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal Hi all, =20 1 comment and 1 question =20 Comment: In the list of considerations that must be taken into account I = would add =AB Whether the load balancer is SIP-aware or not. =20 Till now, we are discussing about SIP-aware load balancer = only. In case the load balancer is SIP-unaware, is it something like = load-balance by open-loop model wherein there is no feedback required = from downstream servers or load balance in the transport layer instead = of SIP layer ?. Could you please explain your consideration in detail. = =20 Question: Is the Charter intended to cover architectures with an in-path = load balancer in front of a farm of SIP servers only or is it expected = to cover as well other architectures where the load balancer is off-path = or even architectures where load balancing just relies on frequent = updates of the DNS?=20 The charter's first consideration explains open-loop model. = So, it might be possible to get the solution through open-loop model = (off-path). ISTM, DNS update for load balancer also falls under = open-loop model until otherwise DNS weight and priority varies so often = based on system load but it is next to impossible to change DNS so = frequently in the real-time. =20 I guess that 1st consideration will=20 =20 Bruno =20 =20 =20 =20 De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la = part de Parthasarathi R (partr) Envoy=E9 : lundi 23 mai 2011 17:04 =C0 : dispatch@ietf.org Objet : [dispatch] SIP Load balancing (SIPLB) Charter proposal =20 Hi all, =20 Charter proposal for SIP load balancing (SIPLB) is written in this mail = to create a new WG related to SIP based load balancing. =20 There are lot of interest in SIP load balancing work during the time of = IETF-80 and the side meeting leads to the creation of this charter. = There are lot of draft submitted in Dispatch related to this work and = the list is as follows: =20 [1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-balanci= ng-00 [2]http://tools.ietf.org/html/draft-jones-sip-overload-sce-00 [3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-overload-co= ntrol-00 =20 To make the progress in the work, the charter currently focus on two = types of SIP based load balancing namely signaling only SIP load = balancing and Media-related SIP based load balancing.=20 =20 Please provide your value inputs and comments in the below charter. =20 Thanks Vijay/Partha =20 SIP Load balancing (SIPLB) Charter ---------------------------------- =20 Session Load balancing (SIPLB) working group is chartered to define a=20 SIP-based protocol for load balancing SIP sessions. =20 Load balancing across a farm of SIP servers can be done today, but = without=20 generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with=20 varying capabilities, example, a SIP proxy, a back-to-back user agent=20 (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media=20 servers etc. The capabilities and processing capacity on hosts in the = farm=20 may be different, sometimes vastly, from each other. Furthermore, the=20 duration of time that a SIP host requires to process a SIP request=20 may vary. SIP proxies, operating at the transaction layer, may be=20 more efficient at processing transactions than a B2BUA would be,=20 which may need to maintain a long-lived dialogue state in addition to=20 the transaction state. PSTN gateways may have other limitations such=20 as media resources that may be depleted even though the gateway may=20 have enough processing power (i.e., CPU) to handle incoming requests. =20 In face of such diversity, simple load balancing schemes based on=20 round-robin selection tend to work only when many assumptions are met. First, the relative capacity and processing resources of all SIP servers = in the farm should be nearly equal. Furthermore, because a round-robin=20 scheme presents a load of (1/n)*N to each server, where n =3D number of=20 servers and N =3D arrival rate in requests per second, it assumes that=20 the service time at each server is such that the utilization of each=20 server is not negatively impacted (i.e., utilization ratio of the = arrival=20 rate over the mean service rate is less than 1.0). And finally,=20 the round-robin load balancing does not have a backward feedback = mechanism=20 whereby the load-balanced server can inform the load balancer of its=20 current utilization (i.e., round-robin load balancing acts as an = open-loop=20 controller). =20 The SIP load balancing working group is, therefore, chartered to=20 arrive at a load balancing scheme that distributes SIP requests to=20 a collection of servers to effectively utilize the resources at those=20 servers. These resources can include CPU, memory, network bandwidth,=20 input/output, DSP, DS0 or disk resources. The load balancing scheme must prevent excessive oscillation in the collection of servers. =20 In order to achieve such a load balancing scheme in practice, the = following=20 considerations must be taken in account: =20 1) Should the load balancing scheme have a closed-loop model, i.e.,=20 should it report utilization to the load balancer to allow the=20 load balancer to distribute requests proportionally? =20 2) What should the diversity of the SIP hosts in a farm be? Is=20 it reasonable to assume that the same load balancing scheme should=20 be applicable to a pair of SIP servers, one of which can handle=20 an order of magnitude more requests per unit time that the other? =20 3) What information must be provisioned into the load balancer and=20 the servers? =20 4) As SIP request resource consumption in SIP signaling only server=20 varies drastically from SIP media servers, should the solution be=20 split such that load balancing of a pure signaling server is different=20 than that of a SIP server that handles signaling as well as media? =20 The last consideration above is especially important since a solution to load balancing a media farm will require a model where the SIP=20 load balancer is closely coupled with the downstream SIP servers. In such a model, the SIP load balancer knows the resources available at each of the downstream SIP servers and is able to inspect an incoming request to determine its media-related requirements and thus dispatch it to the downstream SIP server that has the highest probability of servicing that request. In some architectures, such a coupling reduces post-dial delay. =20 =20 Keeping the SIP load balancer and the downstream SIP servers=20 loosely coupled suffices for load balancing to a farm of SIP servers that only handle signaling. A loosely coupled model operates purely on the feedback received from the downstream SIP servers and does not require the SIP load balancer to inspect an incoming request. =20 Any solution needs to clearly specify its scope. A solution also=20 needs to clearly state any limitations, in performance or otherwise,=20 the specified load balancing mechanism may have. In particular,=20 the solution shall carefully define the deployment considerations for=20 the effective operation of the specified mechanisms and discuss,=20 for example, when a mechanism requires coordinated deployment and=20 operation (if all servers need to deploy the same mechanism, certain=20 configuration values need to be identical on all servers, etc.), when=20 a mechanism can become less effective or ineffective under some = conditions,=20 or especially if there are cases when a mechanism these considerations=20 is to allow potential deployments to make the best use of these = mechanism in=20 their particular networks. =20 SIPLB Working Group will thoroughly identify use cases, provide example=20 design & system architectures and deployment scenarios, and=20 define requirements. =20 The group will produce: =20 1) Use case and requirement document. 2) A document surveying SIP load balancing strategies in use today. 3) An architecture document showing sample SIP topologies. 4) Specification for SIP based overload scheme applicable to a=20 signaling-only SIP server. 5) Specification for SIP based overload scheme applicable to a media-based SIP server. =20 Goals and Milestones Mar 2012 Survey document for SIP load balancing strategies to IESG as an Informational document. Jun 2012 Use cases and requirement document to IESG as an Informational document. Aug 2012 Design & Architecture to IESG as Informational RFC Feb 2013 Submit signaling based SIP overload solution to IESG as=20 Proposed Standard RFC=20 Feb 2013 Submit signaling and media based SIP overload solution to=20 IESG as Proposed Standard RFC=20 ------_=_NextPart_001_01CC1A93.8A79B4A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bruno,
 
Thanks for your interest in the charter. = Please read=20 inline.
 
Thanks
Partha

From: = bruno.chatras@orange-ftgroup.com=20 [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Tuesday, May = 24, 2011=20 11:00 PM
To: Parthasarathi R (partr);=20 dispatch@ietf.org
Subject: RE: [dispatch] SIP Load balancing = (SIPLB)=20 Charter proposal

Hi all,

 

1 comment and 1 question

 

Comment: In the list of considerations that must be taken = into=20 account I would add =AB Whether the load balancer is SIP-aware or=20 not.

 

<Partha>  Till now, we are discussing about = SIP-aware load=20 balancer only. In case the load balancer is SIP-unaware, is it = something like load-balance by open-loop model wherein there is no = feedback=20 required from downstream servers or load balance in the transport = layer=20 instead of SIP layer ?. Could you please explain your consideration in detail.=20 </Partha>

 

Question: Is the Charter intended to cover architectures = with an=20 in-path load balancer in front of a farm of SIP servers only or is it = expected=20 to cover as well other architectures where the load balancer is off-path = or even=20 architectures where load balancing just relies on frequent updates of = the=20 DNS? 

<Partha>  The charter's first=20 consideration explains open-loop model. So, it might be = possible to=20 get the solution through open-loop model (off-path). ISTM, DNS = update=20 for load balancer also falls under open-loop model until otherwise DNS = weight=20 and priority varies so often based on system load but it is next to = impossible=20 to change DNS so frequently in the real-time.=20 </Partha>

 

I guess that 1st consideration will=20

 

Bruno

 

 

 

 

De :=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la = part=20 de Parthasarathi R (partr)
Envoy=E9 : lundi 23 mai = 2011=20 17:04
=C0 : dispatch@ietf.org
Objet : = [dispatch] SIP=20 Load balancing (SIPLB) Charter = proposal

 

Hi=20 all,

 

Charter = proposal for=20 SIP load balancing (SIPLB) is written in this mail to create a new = WG=20 related to SIP based load balancing.

 

There are = lot of=20 interest in SIP load balancing work during the time of IETF-80 and the = side=20 meeting leads to the creation of this charter. There are lot of draft = submitted=20 in Dispatch related to this work and the list is as=20 follows:

 

[1]http://tools.ietf.org/html/draft-bessis-dispatch-adaptive-load-b= alancing-00
[2]http://tools.ietf.org/html/draft-jones-sip-overload-sce= -00
[3]http://tools.ietf.org/html/draft-partha-dispatch-sip-media-over= load-control-00

 

To make the = progress=20 in the work, the charter currently focus on two types of SIP based = load=20 balancing namely signaling only SIP load balancing and Media-related=20 SIP based load balancing.

 

Please = provide your=20 value inputs and comments in the=20 below charter.

 

Thanks

Vijay/Partha

 

SIP Load = balancing=20 (SIPLB) = Charter
----------------------------------
 
Session Load=20 balancing (SIPLB) working group is chartered to define a
SIP-based = protocol=20 for load balancing SIP sessions.
 
Load balancing across a = farm of=20 SIP servers can be done today, but without
generally agreed upon = principles=20 on how to best do accomplish this.
Confounding the problem is that a = SIP farm=20 may consist of hosts with
varying capabilities, example, a SIP = proxy, a=20 back-to-back user agent
(B2BUA), a public-switched telephone system = (PSTN)=20 gateway, SIP Media
servers etc. The capabilities and processing = capacity on=20 hosts in the farm
may be different, sometimes vastly, from each = other. =20 Furthermore, the
duration of time that a SIP host requires to = process a SIP=20 request
may vary. SIP proxies, operating at the transaction layer, = may be=20
more efficient at processing transactions than a B2BUA would be, =
which=20 may need to maintain a long-lived dialogue state in addition to
the=20 transaction state.  PSTN gateways may have other limitations such =
as=20 media resources that may be depleted even though the gateway may =
have enough=20 processing power (i.e., CPU) to handle incoming = requests.
 
In face=20 of such diversity, simple load balancing schemes based on =
round-robin=20 selection tend to work only when many assumptions are met.
First, the = relative capacity and processing resources of all SIP servers
in the = farm=20 should be nearly equal.  Furthermore, because a round-robin =
scheme=20 presents a load of (1/n)*N to each server, where n =3D number of =
servers and N=20 =3D arrival rate in requests per second, it assumes that
the service = time at=20 each server is such that the utilization of each
server is not = negatively=20 impacted (i.e., utilization ratio of the arrival
rate over the mean = service=20 rate is less than 1.0).  And finally,
the round-robin load = balancing=20 does not have a backward feedback mechanism
whereby the = load-balanced server=20 can inform the load balancer of its
current utilization (i.e., = round-robin=20 load balancing acts as an open-loop
controller).
 
The = SIP load=20 balancing working group is, therefore, chartered to
arrive at a load = balancing scheme that distributes SIP requests to
a collection of = servers to=20 effectively utilize the resources at those
servers. These resources = can=20 include CPU, memory, network bandwidth,
input/output, DSP, DS0 or = disk=20 resources.  The load balancing
scheme must prevent excessive = oscillation=20 in the collection of
servers.

 

In order to = achieve=20 such a load balancing scheme in practice, the following =
considerations must=20 be taken in account:
 
1) Should the load balancing scheme = have a=20 closed-loop model, i.e.,
should it report utilization to the load = balancer=20 to allow the
load balancer to distribute requests=20 proportionally?
 
2) What should the diversity of the SIP = hosts in a=20 farm be?  Is
it reasonable to assume that the same load = balancing=20 scheme should
be applicable to a pair of SIP servers, one of which = can=20 handle
an order of magnitude more requests per unit time that the=20 other?
 
3) What information must be provisioned into the = load=20 balancer and
the servers?
 
4) As SIP request resource=20 consumption in SIP signaling only server
varies drastically from SIP = media=20 servers, should the solution be
split such that load balancing of a = pure=20 signaling server is different
than that of a SIP server that handles = signaling as well as media?
 
The last consideration above is = especially important since a solution
to load balancing a media farm = will=20 require a model where the SIP
load balancer is closely coupled with = the=20 downstream SIP servers.
In such a model, the SIP load balancer knows = the=20 resources available
at each of the downstream SIP servers and is able = to=20 inspect an
incoming request to determine its media-related = requirements and=20 thus
dispatch it to the downstream SIP server that has the=20 highest
probability of servicing that request.  In some = architectures,=20 such
a coupling reduces post-dial delay.  =

 

Keeping the = SIP load=20 balancer and the downstream SIP servers
loosely coupled suffices for = load=20 balancing to a farm of SIP
servers that only handle signaling.  = A=20 loosely coupled model
operates purely on the feedback received from = the=20 downstream
SIP servers and does not require the SIP load balancer to=20 inspect
an incoming request.

 

Any = solution needs to=20 clearly specify its scope.  A solution also
needs to clearly = state any=20 limitations, in performance or otherwise,
the specified load = balancing=20 mechanism may have.  In particular,
the solution shall = carefully define=20 the deployment considerations for
the effective operation of the = specified=20 mechanisms and discuss,
for example, when a mechanism requires = coordinated=20 deployment and
operation (if all servers need to deploy the same = mechanism,=20 certain
configuration values need to be identical on all servers, = etc.),=20 when
a mechanism can become less effective or ineffective under some = conditions,
or especially if there are cases when a mechanism these=20 considerations
is to allow potential deployments to make the best = use of=20 these mechanism in
their particular networks.
 
SIPLB = Working=20 Group will thoroughly identify use cases, provide example
design = &=20 system architectures and deployment scenarios, and
define=20 requirements.
 
The group will produce:
 
1) Use = case and=20 requirement document.
2) A document surveying SIP load balancing = strategies=20 in use today.
3) An architecture document showing sample SIP=20 topologies.
4) Specification for SIP based overload scheme applicable = to a=20
   signaling-only SIP server.
5) Specification for SIP = based=20 overload scheme applicable to a
   media-based SIP=20 server.
 
Goals and Milestones
Mar 2012  Survey = document for=20 SIP load balancing strategies to=20 IESG
          as an=20 Informational document.
Jun 2012  Use cases and requirement = document to=20 IESG as an=20 Informational
         =20 document.
Aug 2012  Design & Architecture to IESG as = Informational=20 RFC
Feb 2013  Submit signaling based SIP overload solution to = IESG as=20
          Proposed = Standard RFC=20
Feb 2013  Submit signaling and media based SIP overload = solution to=20
          IESG as = Proposed=20 Standard RFC

------_=_NextPart_001_01CC1A93.8A79B4A4-- From salvatore.loreto@ericsson.com Thu May 26 01:35:05 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81139E067B for ; Thu, 26 May 2011 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro3qKijGaghY for ; Thu, 26 May 2011 01:35:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A6253E06B7 for ; Thu, 26 May 2011 01:35:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-95-4dde10b604b5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CC.49.09774.6B01EDD4; Thu, 26 May 2011 10:35:02 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 26 May 2011 10:35:02 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6679C244F; Thu, 26 May 2011 11:35:00 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 17F4E503AE; Thu, 26 May 2011 11:34:57 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B137B4F775; Thu, 26 May 2011 11:34:56 +0300 (EEST) Message-ID: <4DDE10B0.3010609@ericsson.com> Date: Thu, 26 May 2011 11:34:56 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Cullen Jennings References: <4DD12CA7.3080409@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060907070109040607050104" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] goals of draft-loreto-dispatch-3892bis-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:35:05 -0000 --------------060907070109040607050104 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Cullen, thanks for your comments see my answers in line cheers /Sal -- Salvatore Loreto www.sloreto.com On 5/19/11 5:08 PM, Cullen Jennings wrote: > > On May 16, 2011, at 7:54 AM, Salvatore Loreto wrote: >> >> below there is also a first tentative of charter proposal for a wg >> to work on updating the Referred-by header. >> http://tools.ietf.org/html/draft-loreto-dispatch-3892bis-02 > It's been a long time since I looked the message exploder stuff. So A sends a message to the exploder, called E, that explodes it to B. If A had a PAI with with a sip and tel URI it sent to E. Now the message from E to B is going to have some stuff in it but the goal is that if B supports sip URIs, a return message would go to E, but if B only support tel URI then the return message would go to A. Did I get this about right? (and by return message I mean a new out of dialog request). no, this is not what is meant. B *always* has the choice to respond back to all using the URI in the PAI, or to respond back only to A using the URI in the Referred-By. Having both a TEL URI and SIP URI in the Referred-By just allows B to have the same information he would have about A as when he received a SIP request directly from A. > I can get my head around the requirement for E to massacred as A, or for E to show up as E, but I have a hard time seeing how B is going to have a good user experience if E tries to do both at the same time. I'm sure you have considered the option of the E sends the same PAI as it received from A. I seem to recall that is what the message exploder RFC says to do in the case the PAI is trusted. the I-D explains the cases where another value needs to go into the PAI - for example: if a URI has been defined for a pre-defined group, then the PAI is set to the pre-defined group URI. > Don't take this wrong way - I'm not saying there is no problem here - I'm just not understanding the use case that leads to it and what the type of behavior on the B would be needed to make it all work. think of a client that has a contact list of phone numbers and names associated with them - when the SIP request arrives, it helps if the URI it uses to search through the contact list is a TEL URI > I'm also not clear if fixing this is need to update things like RFC5365 or just be a new RFC - I was sort of surprised your draft did not reference the 5363 group of stuff as it seem it is proposing an extension to theses - it would be good to get some feedback on that for sorting out the charter. > > I think it would also be worth thinking about requirements around backwards compatibility with existing UA. If B in the example above receives an SIP message that is not consistent with the 3261 ABNF, it very well may discard the whole message. A SIP firewall may do the same. to be clear, there are use cases where you could have two Referred-By headers each with a different value as it is already possible for P-Asserted-Identity so we wanted to focus on the exact RFC that needs to be updated. It is the RFC 3892 that limits Referred-By to one URI, not the 3261 ABNF. So we want to update RF3892. > Cullen, in my individual contributor role > > --------------060907070109040607050104 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Cullen,

thanks for your comments see my answers in line

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com


On 5/19/11 5:08 PM, Cullen Jennings wrote: 

On May 16, 2011, at 7:54 AM, Salvatore Loreto wrote:


below there is also a first tentative of charter proposal for a wg
to work on updating the  Referred-by header.
http://tools.ietf.org/html/draft-loreto-dispatch-3892bis-02

It's been a long time since I looked the message exploder stuff. So A sends a message to the exploder, called E, that explodes it to B.  If A had a PAI with with a sip and tel URI it sent to E. Now the message from E to B is going to have some stuff in it but the goal is that if B supports sip URIs, a return message would go to E, but if B only support tel URI then the return message would go to A. Did I get this about right? (and by return message I mean a new out of dialog request).

no, this is not what is meant.
B *always* has the choice to respond back to all using the URI in the PAI,
or to respond back only to A using the URI in the Referred-By.
Having both a TEL URI and SIP URI in the Referred-By
just allows B to have the same information he would have about A as when he received a SIP request directly from A.


I can get my head around the requirement for E to massacred as A, or for E to show up as E, but I have a hard time seeing how B is going to have a good user experience if E tries to do both at the same time. I'm sure you have considered the option of the E sends the same PAI as it received from A. I seem to recall that is what the message exploder RFC says to do in the case the PAI is trusted.


the I-D explains the cases where another value needs to go into the PAI -
for example: if a URI has been defined for a pre-defined group, then the PAI is set to the pre-defined group URI. 

Don't take this wrong way - I'm not saying there is no problem here - I'm just not understanding the use case that leads to it and what the type of behavior on the B would be needed to make it all work.

think of a client that has a contact list of phone numbers and names associated with them -
when the SIP request arrives, it helps if the URI it uses to search through the contact list is a TEL URI


I'm also not clear if fixing this is need to update things like RFC5365 or just be a new RFC -  I was sort of surprised your draft did not reference the 5363 group of stuff as it seem it is proposing an extension to theses - it would be good to get some feedback on that for sorting out the charter. 

I think it would also be worth thinking about requirements around backwards compatibility with existing UA. If B in the example above receives an SIP message that is not consistent with the 3261 ABNF, it very well may discard the whole message. A SIP firewall may do the same.

to be clear,
there are use cases where you could have two Referred-By headers each with a different value as it is already possible for P-Asserted-Identity

so we wanted to focus on the exact RFC that needs to be updated.

It is the RFC 3892 that limits Referred-By to one URI, not the 3261 ABNF.
So we want to update RF3892.


Cullen, in my individual contributor role
--------------060907070109040607050104-- From arnoud.vanwijk@realtimetext.org Thu May 26 03:59:06 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1BE0671 for ; Thu, 26 May 2011 03:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G9exBlh1Mrt for ; Thu, 26 May 2011 03:59:05 -0700 (PDT) Received: from mx-in01.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEA5E0664 for ; Thu, 26 May 2011 03:59:05 -0700 (PDT) Received: from internal02.nouzelle.com (internal02.nouzelle.local [172.29.32.13]) by mx-in01.nouzelle.com (Postfix) with ESMTP id 4AFCE125990 for ; Thu, 26 May 2011 12:58:42 +0200 (CEST) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 56DE510219ACB for ; Thu, 26 May 2011 12:59:02 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id 7V648X+lUf5S for ; Thu, 26 May 2011 12:58:49 +0200 (CEST) Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id 710BC10219AC9 for ; Thu, 26 May 2011 12:58:49 +0200 (CEST) Message-ID: <4DDE3268.2030307@realtimetext.org> Date: Thu, 26 May 2011 12:58:48 +0200 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Presentation of Text Conversation in real-time and en-bloc form X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:59:06 -0000 Hi all, This draft is about Real-Time Text (RTT) presented in real-time and as well in en-bloc mode. This is an ideal combination of both methods. You will see the text as it is being typed on a character by character mode, but after hitting send or enter, the text will then appear en-bloc. So the users can immediately follow the RTT part while the sender is typing it or wait till it is show as en-bloc or use as a combination depending on the intensity of the conversation. We are also describing how multiple users simultaneously talking via RTT can be presented to the users. That part is relevant for the draft http://www.ietf.org/id/draft-hellstrom-text-conference-04.txt We feel that this document is quite valuable, since we are getting a lot of questions by people on this area. We would like to work with DISPATCH on how to proceed with this draft and the text-conference draft. I am looking forward to your advice and comments. And also which working group is the best "home" for both drafts. Sincerely Arnoud > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Presentation of Text Conversation in real-time and en-bloc form > Author(s) : Gunnar Hellstrom > Arnoud van Wijk > Gregg C. Vanderheiden > Norman Williams > Filename : draft-hellstrom-textpreview-08.txt > Pages : 18 > Date : 2011-05-25 > > This specification defines methods for presentation of a text > conversation with focus on the real-time features. The aim is to > give the participants in a conversation a good opportunity to > perceive the real-time flow of the conversation and also provide a > display of the history of the conversation that makes it easy to > read. Both two-party and multi-party situations are defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-hellstrom-textpreview-08.txt From gonzalo.camarillo@ericsson.com Thu May 26 22:52:18 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A305E06F2 for ; Thu, 26 May 2011 22:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mddYE3GOGVen for ; Thu, 26 May 2011 22:52:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 710F8E06DB for ; Thu, 26 May 2011 22:52:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-0c-4ddf3c0fe608 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EC.C5.09774.F0C3FDD4; Fri, 27 May 2011 07:52:16 +0200 (CEST) Received: from [131.160.126.154] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 27 May 2011 07:52:15 +0200 Message-ID: <4DDF3C0E.6030106@ericsson.com> Date: Fri, 27 May 2011 08:52:14 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Q.850 values in Reason header fields X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 05:52:18 -0000 Folks, as you know, this topic was dispatched in the last IETF meeting in Prague. Process wise, I will AD sponsor the document. Therefore, since DISPATCH has already done its job, further discussions on the draft should happen on the RAI list (i.e., not on the DISPATCH list any longer). With respect to the scope of this effort (there have been a few emails about that), it is limited to inserting Q.850 values in (non-100) SIP responses. That is, we are not dealing with any other protocol values. In particular, carrying a SIP response code in a Reason header within a SIP response is out of scope. Regarding how to document this, I sent my views to this list a while ago. In short, my preference would be to explicitly and clearly define what we want to define instead of publishing an RFC with diffs to be applied to a few paragraphs of the original RFC (i.e., RFC 3326). I will work with the editor on how to document the consensus we got in Prague so that we can progress this piece of work as quickly as possible. Cheers, Gonzalo From aallen@rim.com Fri May 27 20:08:54 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9FE06D0 for ; Fri, 27 May 2011 20:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_PRBLMS=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4mEeQB1fAdG for ; Fri, 27 May 2011 20:08:53 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E916EE0618 for ; Fri, 27 May 2011 20:08:52 -0700 (PDT) X-AuditID: 0a412830-b7b83ae0000048f1-a2-4de067422f7a Received: from XCH139CNC.rim.net (xch139cnc.rim.net [10.65.10.235]) by mhs061cnc.rim.net (SBG) with SMTP id 6B.F3.18673.24760ED4; Sat, 28 May 2011 03:08:51 +0000 (GMT) Received: from XCH04ADS.rim.net ([10.67.10.91]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 May 2011 23:08:50 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 May 2011 22:07:05 -0500 Message-ID: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid thread-index: AcwVhuvPH26ax55KQJaQknTmET22NwHG6UwQ References: From: "Andrew Allen" To: "Cullen Jennings" , "DISPATCH list" X-OriginalArrivalTime: 28 May 2011 03:08:50.0985 (UTC) FILETIME=[91B91990:01CC1CE4] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsXC5cj1Wtc5/YGvwZxfbBZLJy1gteiYzObA 5DHl90ZWjyVLfjIFMEU1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWWJSZXKrhkFifnJGbm phYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJTtdJJDwjzvj7syZzAUTiyteblrJ1sB4MKaLkZNDQsBEYvfm/WwQtpjEhXvrgWwu DiGBlYwSLfPvMUE4fYwS09d/ZAGpYhbQkjhyqYkRxOYVEJQ4OfMJUJwDKK4n0baREaJEW2LZ wtfMEEP1JJYtngLWKiyQKvHzUReYzSKgKvHg23s2iDGuElPefWYGGcMpYCtxrZkLolVQYtHs Pcwwt/3b9RCsXEQgTWLZv32sELaRxLKJELaQgI3EstuH2UFsNqDxb45vYISo8ZfYdnMPE0SN tMSOk2sYIWYGS7yaOY1pAqPYLCSPzULy2CyEx2YheWwBI8sqRsHcjGIDM8PkvGS9osxcvbzU kk2M4AShYbCDccJerUOMAhyMSjy8D6Ie+AqxJpYVV+YeYpTgYFYS4b0UBxTiTUmsrEotyo8v Ks1JLT7EaAEMk4nMUtzJ+cDklVcSb2xggMJREucVXTDHV0ggHZiMslNTC1KLYFqZODilGhhn TzD8H8mbVOP02/1YxZvnou2Hy4xzClym2a/1qP/2vbT5+/Sy071WidNs/5rlBN0z4q22/Sqy 0+eKOf/lyTZ1fXlHW6vPSjVf0l2x89Ca7S8u5i9iTPkV9z96k+aq1B+zWFesCkl+vPTd3kPu VTfkbJeu7Jj1dsaEt4UfuN9a90gu1ZQqnW+oxFKckWioxVxUnAgA8SWujSkDAAA= Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 03:08:54 -0000 Cullen Responses to your technical points below: regards Andrew > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Wednesday, May 18, 2011 1:11 PM > To: DISPATCH list > Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- > dispatch-imei-urn-as-instanceid > > > I have said in the past, I have several concerns around the combined > proposal in these two drafts. In this email, I've tried to focus on the > high level problems and ignore small problems in the drafts that can be > fixed by change a bit of text in the drat. > > The biggest issues is that this is going to reduce interoperability with > systems that don't use this type of instance id yet this does not provide > features that could not be done in away that did not reduce > interoperability. Can you please elaborate on what your interoperability concerns are? I don't see any issue with end to end interoperability since with public GRUU the gr parameter is opaque. Devices that contain an IMEI are only those devices specified by 3GPP. Only 3GPP mandates that the IMEI is included in the instance ID, non 3GPP devices or devices not operating in an IMS network do not need to use an IMEI (indeed a non 3PP device would not even have an IMEI to use). RFC 5626 allows the possibility for URNs other than UUID to be used as an instance ID and RFC 5627 does not mandate an algorithm for the generation of GRUUs based on the instance ID. If the 3GPP determines that its devices that already contain an IMEI for their device ID need to use that as an Instance ID and defines a GRUU generation algorithm that satisfies its requirements when receiving an Instance ID that contains the IMEI URN then that seems fine to me. Is your concern regarding a 3GPP IMS terminal registering in a non IMS domain? I think that in reality a device acting as an IMS terminal registering in a non IMS compliant network isn't a practical scenario. There are so many 3GPP and IMS compliant things that would need to happen in the network for the device (acting as an IMS terminal) to register and obtain service that basically the network would need to be an IMS compliant network. Of course there is nothing preventing a device that is IMS capable being configured to either act as an IMS compliant device or a basic SIP compliant device (quite a few devices have such dual mode capabilities). The use of the IMEI as the instance ID should not in itself prevent the successful registration of the device in a non IMS network (since as Dale points out the registrar is likely to treat the instance ID opaquely if it doesn't understand it). >To be concrete, let me offer an alternative solution > that would be interoperable, would not have any IPR that I am aware of, > and would provide the same functionality as the goals of these drafts - or > at least the goals that have been stated at the IETF. > > To indicate the version of the software, I would suggest using the SIP > User Agent header. If a more structured form is required to specifically > line up with existing mobile systems, I would suggest defining an well > structured format to use inside the User Agent header field. The advantage > is that this is what most sip systems do today and many management systems > already can look at this header and use it. A more structured form would > be useful by systems outside the GSMA space and would also be backwards > compatible with existing systems that treat it as an unstructured string. I am not against the proposal of including the software version in the User Agent header but don't see it as an alternative to the representation of the IMEI-SV as part of the IMEI URN. One of the main objectives of the use of the IMEI and IMEI-SV in SIP signaling is to maintain compatibility with the IMEI and IMEI-SV use in Circuit Switched signaling. In some case in circuit switched signaling the device will return the IMEI and in other cases the device will return the IMEI-SV. It needs to be possible that devices registered in circuit switched domain and in the IMS domain can use whichever is returned IMEI or IMEI-SV in the same identifier. > > For the issue of identifying stolen handsets and correlating devices > between SIP and non SIP calls, I would propose that you use a UUID as the > URN but that the UUID be created using IMEI or a hash of the IMEI instead > of the MAC. This would involve an extension to RFC 4122 but would result > in a system that meets the needs. Even if a hash is used, the server side > can do the same hash to match. I don't fully understand the details of your proposal but a clear requirement is that the IMEI in the instance ID be recoverable and understandable by the registrar as the IMEI value of the terminal. Does this proposal allow the IMEI value to be obtained and understood by the registrar? If an extension to RFC 4122 is required isn't this more overhead and has more impact than simply defining and using a URN that represents the namespace that you wish to include? UUID itself is also heavier in computational resources and less efficient in size than the IMEI URN. > > If the WG is interest in such an idea, I am glad to write up an ID for > each of these and submit it to the group so that it can be properly > considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid. > > As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am not > in favor of publishing it as is because I believe it will result in > interoperability failures with the many SIP devices that don't support it, This needs justification. 3GPP specifications also support handling devices that use UUID and not IMEI as many IMS compatible devices do not actually have an IMEI (only GSM mobile devices have an IMEI). > and it has IPR that we can easily avoid and provide the same > functionality. I also have issues with some of the technical details in it > but theses could all be fairly easily resolved with a few back and forth > of suggested text. RIM is offering awful licensing terms for something > that I believe you would have to implement to be workable in the bulk > mobile SIP deployments. Give this is easily avoidable, I think we should > avoid it. It's not really a topic for this WG but if this draft proceeded, > it was very late IPR disclosure. When it came to IETF LC, I would also > want to point out that the only teeth IETF has to enforce very late IPR > disclosures is to say no. I'm not particularly interested in talking about > this here as I don't think it will help solve the proble > m but I have brought this up in the past in context of this draft and I > don't want anyone to be surprised if I brought it up in an IETF LC. > > There are also significant privacy concerns around this proposal. A key > design of GRUU is being able to meet people goals of privacy while not > revealing private information. Privacy in GRUU is achieved through temporary GRUUs. Properties of temporary GRUUs are unaffected by using the IMEI as an instance ID. >The IMEI is sometimes used as a security > identifier between a user and SP as a shared secret. This proposal would > break theses systems. The IMEI is easily readable from the UI of mobile phones and is quite often printed on the case under the battery. Mobile phone stores sometimes keep lists (sometimes on paper) of IMEIs and the customers who have been allocated them (warranty reasons etc). It is hardly a super secret security identifier. I am not aware of the security usage you describe and if it does exist it seems pretty flawed. >The privacy and security aspects of this would need to be addressed. 3GPP has addressed aspects of revealing the IMEI when generating GRUUs in their specifications. > It's conceivable that in many cases IMEI is Personal > Identifiable Information. IMEI is not really anymore personal information than IP address which IETF specifications reveal all the time. Furthermore it is not the intention that the IMEI is exchanged end to end. > The idea that every call would have to have PII > information in it or my call would be blocked as coming form a stolen > phone seems like a pretty serious flaw in this proposal. In general the IMEI is not placed in an IMS call. The blocking would be achieved via the registration. Blocked mobiles simply would be unable to register in IMS (which in IMS means they are unable to make calls). If an IMEI check is needed during a call the mobile can be requested by the network to re-register. The only use in 3GPP of the IMEI during an IMS call is for emergency calls. > I'll note I brought up the privacy issues in 2007 and have yet to get a reply on it. I don't recall your previous comment (but it was 4 years ago). If we have failed to respond adequately to a previous comment then please restate it if the above responses do not cover it. > > On the topic of draft-montemurro-gsma-imei-urn, I of course think it is > fine for the GSMA to be able to allocate a namespace where they need it. > However, there are bunch of changes that would be needed to make this > draft fit all the URN rules. They are all small actionable things like > defining how comparison of things such as svn is defined and how > allocation of new things works. Of course all technical issues and concerns can be fixed. Please supply details on those so they can be addressed. > As I have also brought up many times in > the past, what the relationship between GSMA and 3GPP on this is very > weird and I would want clarity on that before proceeding. In the time we > have been discussing this draft, people constantly tell me that GSMA is > the group that will handle the namespace allocation for the 3GPP > deployments yet at the same time we have approved RFC 5279 which oddly > looks like a better namespace for this than the GSMA one. I would want to > have a clear understanding of how these different spaces interact. The > more we splinter this namespace, the less interoperability we have. My understanding is that in order to be allocated a URN namespace the registrant of the namespace has to guarantee uniqueness of the namespace. GSMA provides for the allocation of IMEIs and ensures adherence to the guidelines for IMEI allocation "GSMA Association, "IMEI Allocation and Approval Guidelines", PRD DG.06". Thus for the IMEI the GSMA is the appropriate registrant for that namespace. 3GPP has no responsibility for allocation of IMEIs so should not be the responsible registrant. 3GPP namespace would seem appropriate for items which are completely specified (including all their values) in 3GPP specifications. It should be noted that 3GPP is not a legal entity and might not exist for the entire period of time that IMEIs are being allocated and used. > > On the topic of including the software version as part of the device > identifier, given the software is upgraded, I think this is a mistake and > it is better to consider the software version as a separate thing from the > unique device identifier. It does not seem consistent with the goals and > requirements of a device id URN. As stated above the software version is included for backward compatibility with the IMEI-SV usage in circuit switched signaling. The SVN is a parameter and so the original IMEI which does not change can be easily obtained. Registrars and other devices that understand the IMEI URN with the SVN parameter can ignore the parameter when generating GRUUs for instance. If a book has a 2nd edition with different content doesn't that warrant being assigned a new value within the ISBN URN namespace? Similarly if the software is upgraded the nature and capabilities of the device may change so doesn't this warrant a new value? Note that RFC 5626 and RFC 5627 do not require that the instance IDs or GRUUs be forever persistent (RFC 5626 only requires that it MUST be persistent through a power cycle). I doubt very much that most embedded SIP endpoints will after a complete software upgrade (such as involving completely rewriting flash memory) still use the same UUID as previously used either. > > I will also note that as far as process is concerned, I would prefer the > problem, not the solution was brought to dispatch and we could figure out > how to solve it. I do think the problem here is well worth solving, I just > think there are solutions that will work better that this when considering > the whole eco systems of SIP endpoints and not just the GSM ones. When this was first proposed in 2006 all that was being done was registering a namespace. I don't think that 3GPP needs to bring requirements to the dispatch WG, propose a charter etc for every problem that can be solved by registering a namespace or a parameter. In fact the SIP change process has moved away from that with only specification required and expert review needed for defining "proprietary" SIP header fields. As stated above the IMEI only applies to the GSM family of technology mobiles not all SIP endpoints and I fail to see the impact of the use of the IMEI URN by the GSM family of technology mobiles when registering with IMS on any other SIP endpoints. This proposal does not mandate the use of the IMEI URN as an Instance ID by non 3GPP terminals and is not being proposed to become part of an IETF standard. This is just trying to follow the process whereby external users of IETF protocols register their identifiers with IANA and provide informational documentation to the internet community about such usage. It seems to me that some of the issues of principle being raised are those considerations that more appropriately apply to standards track submissions and not to these informational submissions. If the same level of consideration and debate about different solutions takes place for informational submissions as would take place for standards track submissions then I fear this will become a big deterrent to outside users of IETF protocol submitting their proprietary usages as informational RFCs for the benefit of the internet community and in ensuring that are no conflicts with the IANA registry. > > Cullen in my individual contributor role > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From aallen@rim.com Fri May 27 20:09:55 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2BE06E9 for ; Fri, 27 May 2011 20:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ2VgZC0jsac for ; Fri, 27 May 2011 20:09:53 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id B32FDE06F0 for ; Fri, 27 May 2011 20:09:52 -0700 (PDT) X-AuditID: 0a412830-b7b83ae0000048f1-bb-4de067802c6a Received: from XCH138CNC.rim.net (xch138cnc.rim.net [10.65.20.127]) by mhs061cnc.rim.net (SBG) with SMTP id CF.F3.18673.08760ED4; Sat, 28 May 2011 03:09:52 +0000 (GMT) Received: from XCH04ADS.rim.net ([10.67.10.91]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 May 2011 23:09:52 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 May 2011 22:09:32 -0500 Message-ID: <56DC300C52125F46BA19D2D5CCEC4D70089086@XCH04ADS.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid thread-index: AcwVhvRWfU4diZ7qQ1WU2IcHhQHLZwAqxtBNAaymes4= From: "Andrew Allen" To: , , X-OriginalArrivalTime: 28 May 2011 03:09:52.0331 (UTC) FILETIME=[B649C1B0:01CC1CE4] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsXC5ShSr9uQ/sDX4M1CfoulkxawWrTtmsNs 0TGZzYHZ4+DKOeweU35vZPVYsuQnUwBzVAOjTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZlli cqWCS2Zxck5iZm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvO T8nMS7dV8gz217WwMLXUNVSy00UCCf+4Mz7+lyk4IlaxaUFNA+MioS5GTg4JAROJS8tnMkPY YhIX7q1nA7GFBFYySty9rA5h9zFKdH5IALGZBbQkjlxqYgSxeQUEJU7OfMICETeQuH+ogxXC 1pZYtvA11Ew9iWWLp4DVCAukSkyYMo0JxGYRUJXY1fQUao6rxKS2F2B7OQXCJP7OvssG0Sso sWj2Hrjb/u16CBYXEUiTWPZvH9AudiDbSmIGJ0iUDWjim+MbGCEqXCR6751nhLheWmLHyTVA NgfQlGCJ36erJjCKzkLyyywkv8xC8sssJL8sYGRZxSiYm1FsYGaYnJesV5SZq5eXWrKJEZwU NAx2ME7Yq3WIUYCDUYmH90HUA18h1sSy4srcQ4wSHMxKIryX4oBCvCmJlVWpRfnxRaU5qcWH GC2AwTCRWYo7OR+YsPJK4o0NDFA4SuK8ogvm+AoJpAOTTXZqakFqEUwrEwenVAMjS+P7Ffdd zbznzXT58sUmYsPpzzNcGFRk/862fNZ/uzu5++bvOafeX6meuLiyZqa/sZu3XYChoP2ltfu/ RrlaJ83hsHgwoWSGb5vZQSV3Bh25MOmy28JZPuuKl5SWd8k9W9ky5db93JmJMsuv7Jaaf/xk 5jrdoqX8KmYLxD0j1uhbPZPQP2ylxFKckWioxVxUnAgA5bk0fCMDAAA= Subject: Re: [dispatch] draft-montemurro-gsma-imei-urnand draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 03:09:55 -0000 Dale I have sent a separate response to Cullen"s email which I think addresses mo= st of your points but I would like to address here one of the points you mak= e. >> To indicate the version of the software, I would suggest using the SIP >> User Agent header. >That sounds like a good idea, unless the "Software Version" is not just an attribute of the device but >somehow a qualifier of the meaning of the IMEI. >I'm more worried that the "Software Version" is a declaration of the >capabilities of the handset, in which case it should really be encoded >in the Supported header in some way. >Is there a list of specified Software Versions? The software version of the IMEI-SV basically indicates a revision of the ba= se software of the device (pretty much the firmware version). It is unlikly= to indicate different SIP capabilities. It is more likely to indicate wheth= er certain bugs in earlier versions have been fixed (for example any securit= y holes etc) and in most cases doesn't have any impact on SIP behaviour at a= ll. I certainly don't think this should go in the Supported header field. Andrew ----- Original Message ----- From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] Sent: Thursday, May 19, 2011 09:45 AM To: Cullen Jennings ; DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urnand draft-allen-dispat= ch-imei-urn-as-instanceid > From: Cullen Jennings [fluffy@cisco.com] > > The biggest issues is that this is going to reduce interoperability > with systems that don't use this type of instance id [...] Could you explain this? The system I'm familiar treats the instance-id largely as an opaque string. Certainly, any SIP system must be prepared to see instance-id values from namespaces that it does not understand. How could a device using a new instance-id namespace break any existing registrar, unless the registrar was only able to deal with a limited set of namespaces? > To indicate the version of the software, I would suggest using the SIP > User Agent header. That sounds like a good idea, unless the "Software Version" is not just an attribute of the device but somehow a qualifier of the meaning of the IMEI. I'm more worried that the "Software Version" is a declaration of the capabilities of the handset, in which case it should really be encoded in the Supported header in some way. Is there a list of specified Software Versions? > There are also significant privacy concerns around this proposal. That's true, but it seems to me that that's the whole point of it -- to make the endpoint rigidly identifiable to the user and mobile account. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jyk@cs.columbia.edu Mon May 30 05:54:08 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61894E07BE for ; Mon, 30 May 2011 05:54:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoZDVoI7d+3x for ; Mon, 30 May 2011 05:54:06 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE5BE07CE for ; Mon, 30 May 2011 05:54:06 -0700 (PDT) Received: from [192.168.1.109] (user-12lc543.cable.mindspring.com [69.86.20.131]) (user=jk2520 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p4UCs3t8001735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 30 May 2011 08:54:05 -0400 (EDT) From: Jong Yul Kim Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 May 2011 08:54:03 -0400 Message-Id: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> To: dispatch@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 X-Mailman-Approved-At: Mon, 30 May 2011 09:00:26 -0700 Subject: [dispatch] Emergency Text Messaging using SIP MESSAGE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 12:54:43 -0000 Hi everyone,=20 This draft presents mechanisms to allow page-mode text messaging in = emergency situations.=20 An example of page-mode messaging is when a person sends SMS to an = emergency number to get help. In this case, there needs to be a way for = the SMS message to reach the same call taker until the "conversation" = ends.=20 As emergency call centers are transitioning to a SIP-based solution, the = draft outlines a mechanism based on SIP MESSAGE method to deliver = page-mode messages consistently to a call taker.=20 http://tools.ietf.org/html/draft-kim-dispatch-text-01 Comments on the draft or which WG it should go to are much appreciated.=20= Please let us know your thoughts.=20 Best regards,=20 Jong Yul=20= From jmpolk@cisco.com Mon May 30 16:34:46 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3218FE0700 for ; Mon, 30 May 2011 16:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWSFu2N+Wa8Y for ; Mon, 30 May 2011 16:34:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0A177E0676 for ; Mon, 30 May 2011 16:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1103; q=dns/txt; s=iport; t=1306798484; x=1308008084; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=Ph/8BRnPJ138CnQNfrePCDR+YdnGOi163RL2/Oj4TXg=; b=FSQQn+iOAfL9+G123wJrliF1VyUD4KSD2z7TqqTLWnUnwwVw4qi6Tfgk s/DsGbO69cklII1JQcmphfggKJG2Tw3ofnFaedjTJpUaJSeJdz3lLNAeK 4veKzLRHGEVJZXN9Mt40KYY6YM6Xh5jdaQjkau7ybFSWnZlKcO8r2WCJf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFko5E2rRDoH/2dsb2JhbABVEKYad6YHnU2GHgSGZJhQUw X-IronPort-AV: E=Sophos;i="4.65,294,1304294400"; d="scan'208";a="456664173" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 30 May 2011 23:34:42 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4UNYgSj010236; Mon, 30 May 2011 23:34:42 GMT Message-Id: <201105302334.p4UNYgSj010236@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 May 2011 18:34:41 -0500 To: Jong Yul Kim , dispatch@ietf.org From: "James M. Polk" In-Reply-To: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dispatch] Emergency Text Messaging using SIP MESSAGE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 23:34:46 -0000 At 07:54 AM 5/30/2011, Jong Yul Kim wrote: >Hi everyone, > >This draft presents mechanisms to allow page-mode text messaging in >emergency situations. Doesn't this whole idea of including text that talks about emergency services need to get run by the ECRIT WG before the topic can be included anywhere? James >An example of page-mode messaging is when a person sends SMS to an >emergency number to get help. In this case, there needs to be a way >for the SMS message to reach the same call taker until the >"conversation" ends. > >As emergency call centers are transitioning to a SIP-based solution, >the draft outlines a mechanism based on SIP MESSAGE method to >deliver page-mode messages consistently to a call taker. > >http://tools.ietf.org/html/draft-kim-dispatch-text-01 > >Comments on the draft or which WG it should go to are much appreciated. >Please let us know your thoughts. > >Best regards, > >Jong Yul >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Tue May 31 08:51:47 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FB9E0701 for ; Tue, 31 May 2011 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.008 X-Spam-Level: X-Spam-Status: No, score=-103.008 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+BU-Vj8uLf5 for ; Tue, 31 May 2011 08:51:47 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 03361E0677 for ; Tue, 31 May 2011 08:51:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABcO5U2HCzI1/2dsb2JhbABTEKYNd4hxogsCmxyGHgSVKooKUQ X-IronPort-AV: E=Sophos;i="4.65,297,1304308800"; d="scan'208";a="191040167" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 May 2011 11:51:45 -0400 X-IronPort-AV: E=Sophos;i="4.65,297,1304308800"; d="scan'208";a="658010891" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 May 2011 11:51:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 31 May 2011 11:51:44 -0400 From: "Worley, Dale R (Dale)" To: Jong Yul Kim , "dispatch@ietf.org" Date: Tue, 31 May 2011 11:51:44 -0400 Thread-Topic: [dispatch] Emergency Text Messaging using SIP MESSAGE Thread-Index: Acwe4rmcqNxPpmzBRLKvfPkGtpO2gwAxLQHI Message-ID: References: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> In-Reply-To: <30E0133A-9869-41B1-BCB2-B32E369D7ABB@cs.columbia.edu> 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] Emergency Text Messaging using SIP MESSAGE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:51:47 -0000 > From: Jong Yul Kim [jyk@cs.columbia.edu] >=20 > This draft presents mechanisms to allow page-mode text messaging in > emergency situations. >=20 > An example of page-mode messaging is when a person sends SMS to an > emergency number to get help. In this case, there needs to be a way > for the SMS message to reach the same call taker until the > "conversation" ends. >=20 > As emergency call centers are transitioning to a SIP-based solution, > the draft outlines a mechanism based on SIP MESSAGE method to deliver > page-mode messages consistently to a call taker. There are technical reasons why MESSAGE is not a good solution for ongoing conversations, which is why MESSAGE was originally specified not to be used in this manner (RFC 3428, section 2): There may be a temptation to simulate a session of IMs by initiating a dialog, then sending MESSAGE requests in the context of that dialog. This is not an adequate solution for IM sessions, in that this approach forces the MESSAGE requests to follow the same network path as any other SIP requests, even though the MESSAGE requests arguably carry media rather than signaling. IM applications are typically high volume, and we expect the IM volume in sessions to be even higher. This will likely cause congestion problems if sent over a transport without congestion control, and there is no clear mechanism in SIP to prevent some hop from forwarding a MESSAGE request over UDP. [...] The authors recognize that there may be valid reasons to send MESSAGE requests in the context of a dialog. For example, one participant in a voice session may wish to send an IM to another participant, and associate that IM with the session. But implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE requests with one another. In practice, the deaf community is pressuring the 112/911 authorities very heavily to *require* RFC 4103 (IM conversations using SIP signaling and T.140 media). Assuming that this effort succeeds (and there is every reason to believe it will), all commercial devices and PSAPs will implement RFC 4103, making other conversation-mode SIP IM techniques largely obsolete in the market (as RFC 4103 provides a superior feature set to all other approaches). Technically, I think the proposal is unnecessarily complicated. Despite that RFC 3428 forbids it, a UA that uses MESSAGE in a dialog-oriented mode will find that it succeeds even with *generic* proxies: 1. UA-1 sends an out-of-dialog MESSAGE (that is, with no to-tag) to a destination (a PSAP in this case). 2. The various proxies forward the MESSAGE request to the PSAP, and per ordinary SIP, adding any Record-Route headers necessary for a future request to traverse the same path. 3. The MESSAGE arrives at the PSAP UA, and gives a 200 response with a to-tag, and (per ordinary SIP) with a Contact header and whatever Record-Route headers were received in the request. 4. UA-1 receives the 200 response and records the properties of the dialog that has been established, including the to-tag and the route set. 5. UA-1 sends a further MESSAGE request within the dialog, that is, using the to-tag and route set. 6. The various proxies forward the MESSAGE request along the same route as the original MESSAGE to the same PSAP UA. This approach is aligned with normal SIP usage, in that it uses only already-defined mechanisms, and puts the burden on the UAs rather than the proxies. Of course, if the MESSAGE is gatewayed from another protocol, it requires the gateway be a full UA, it must remember the dialog information, but that is more desirable than requiring all the SIP proxies in the universe to remember the routing information. The MESSAGE-in-dialog approach is also much more likely to work reliably in the field, as it will not be defeated if the request happens to be routed by a proxy that only implements RFC 3261. Dale From dworley@avaya.com Tue May 31 12:06:48 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF8E08A9 for ; Tue, 31 May 2011 12:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.484 X-Spam-Level: X-Spam-Status: No, score=-103.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzABIwlxorY0 for ; Tue, 31 May 2011 12:06:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1573EE0866 for ; Tue, 31 May 2011 12:06:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJE75U2HCzI1/2dsb2JhbABTpiF3qyUCmxmGHgSVKopb X-IronPort-AV: E=Sophos;i="4.65,299,1304308800"; d="scan'208";a="282511902" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 May 2011 15:06:47 -0400 X-IronPort-AV: E=Sophos;i="4.65,299,1304308800"; d="scan'208";a="658085990" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 May 2011 15:06:47 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 31 May 2011 15:06:46 -0400 From: "Worley, Dale R (Dale)" To: Andrew Allen , "fluffy@cisco.com" , "dispatch@ietf.org" Date: Tue, 31 May 2011 15:02:46 -0400 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urnand draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AcwVhvRWfU4diZ7qQ1WU2IcHhQHLZwAqxtBNAaymes4AuCqf6A== Message-ID: References: , <56DC300C52125F46BA19D2D5CCEC4D70089086@XCH04ADS.rim.net> In-Reply-To: <56DC300C52125F46BA19D2D5CCEC4D70089086@XCH04ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urnand draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 19:06:48 -0000 ________________________________________ From: Andrew Allen [aallen@rim.com] The software version of the IMEI-SV basically indicates a revision of the b= ase software of the device (pretty much the firmware version). It is unlikl= y to indicate different SIP capabilities. It is more likely to indicate whe= ther certain bugs in earlier versions have been fixed (for example any secu= rity holes etc) and in most cases doesn't have any impact on SIP behaviour = at all. _______________________________________________ Hmmm... It seems like the "software version" shouldn't be in the URN at a= ll. Dale From dworley@avaya.com Tue May 31 12:14:27 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24EE07D7 for ; Tue, 31 May 2011 12:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRS-tMREwWKV for ; Tue, 31 May 2011 12:14:23 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B710FE0725 for ; Tue, 31 May 2011 12:14:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO085U2HCzI1/2dsb2JhbABGDaYhd6scApsXgxiDBgSVKopb X-IronPort-AV: E=Sophos;i="4.65,299,1304308800"; d="scan'208";a="191080668" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 May 2011 15:14:22 -0400 X-IronPort-AV: E=Sophos;i="4.65,299,1304308800"; d="scan'208";a="658088264" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 May 2011 15:14:22 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 31 May 2011 15:14:22 -0400 From: "Worley, Dale R (Dale)" To: Andrew Allen , Cullen Jennings , DISPATCH list Date: Tue, 31 May 2011 15:12:30 -0400 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AcwVhuvPH26ax55KQJaQknTmET22NwHG6UwQAMkHstg= Message-ID: References: , <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> In-Reply-To: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 19:14:27 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of An= drew Allen [aallen@rim.com] I am not against the proposal of including the software version in the User Agent header but don't see it as an alternative to the representation of the IMEI-SV as part of the IMEI URN. One of the main objectives of the use of the IMEI and IMEI-SV in SIP signaling is to maintain compatibility with the IMEI and IMEI-SV use in Circuit Switched signaling. In some case in circuit switched signaling the device will return the IMEI and in other cases the device will return the IMEI-SV. It needs to be possible that devices registered in circuit switched domain and in the IMS domain can use whichever is returned IMEI or IMEI-SV in the same identifier. _______________________________________________ Could you spell this out more? From where I sit, there seems to be no reas= on for the SV to appear in the URN (as it is not really part of the device identity, inde= ed, is expected to change). I don't grasp the data-flows for the actions you are describin= g above. Dale