From salvatore.loreto@ericsson.com Thu Apr 1 00:35:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8003A677D for ; Thu, 1 Apr 2010 00:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGNr9Xv3zJEF for ; Thu, 1 Apr 2010 00:35:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7C7A73A69A4 for ; Thu, 1 Apr 2010 00:35:41 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-58-4bb44cec0c34 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id EF.B1.23740.CEC44BB4; Thu, 1 Apr 2010 09:36:12 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:36:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:36:11 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 83BCB24C0 for ; Thu, 1 Apr 2010 10:36:11 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 479134F424 for ; Thu, 1 Apr 2010 10:36:11 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9D07F4F412 for ; Thu, 1 Apr 2010 10:36:08 +0300 (EEST) Message-ID: <4BB44CE6.2070402@ericsson.com> Date: Thu, 01 Apr 2010 09:36:06 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <4BB24B81.1050006@nostrum.com> In-Reply-To: <4BB24B81.1050006@nostrum.com> Content-Type: multipart/alternative; boundary="------------090109050401030203060309" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 01 Apr 2010 07:36:11.0505 (UTC) FILETIME=[004BB610:01CAD16E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 07:35:45 -0000 This is a multi-part message in MIME format. --------------090109050401030203060309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, A good mechanism to discovery UA capabilities is essential to provide meaningful service: So I am in favor of pursuing the work, in particular the possibility to use a single OPTIONS request to retrieve the capabilities from ALL UAS(s) behind a forking proxy. I agree with Christer, that as discussed in the ml and during the f2f meeting, the 3xx solution already provide this feature even if with the limitations Paul has highlighted (e.g. honoring R-D is optional by the proxy). I do think, it would be opportune document it in a BCP to document/clarify the ambiguous stuff, and I can help to co-edit it if we decide to write one. Explore the possibility to use other mechanisms (e.g. presence, something similar to XEP-0115) and define it would be also interesting, but IMO it would require a major effort and more cycles and I am not so sure there are enough people willing to accomplish such effort. cheers Sal On 3/30/10 9:05 PM, Adam Roach wrote: > [as chair] > > One of the topics of discussion at the recent face-to-face meeting in > Anaheim was the SIP OPTIONS method. We have had significant discussion > of some specific technical topics on the SIPCORE mailing list, such > that all participants should have a reasonable overview of the scope > that any related work may entail. Participants may also benefit from > reading through the minutes of the corresponding conversation in Anaheim: > > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method > > Rather than continue discussion of the specific technical topics > related to OPTIONS, the chairs would encourage the working group to > engage in a discussion around whether we should, as a group, work on > addressing some of the issues that have been identified. > > In particular, we would direct the group to consider the nature of > such work: > > * Are we proposing to introduce new features, or fix existing bugs? > * If we are adding new features: is OPTIONS the best way to > introduce these features, or would other mechanisms (presence, > callee-caps) produce superior results? > * If we are fixing bugs: are the bugs theoretical, or can we cite > actual interoperability issues in the field? > * If there are identified interoperability issues: is the level of > effort involved in fixing them commensurate with the impact of > the problems? > > Finally, keep in mind that work does not happen unless participants > are willing to invest time. If you speak out in favor of pursuing this > work, please indicate the level of time commitment that you will > personally invest in bringing such work to a successful conclusion > (e.g., will author drafts; will perform dedicated reviews; etc). > > Thanks. > > /a --------------090109050401030203060309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

A good mechanism to discovery UA capabilities is essential to provide meaningful service:
So I am in favor of pursuing the work,
in particular the possibility to use a single OPTIONS request to retrieve the capabilities from ALL UAS(s) behind a forking proxy.

I agree with Christer, that as discussed in the ml and during the f2f meeting, the 3xx solution already provide this feature
even if with the limitations Paul has highlighted (e.g. honoring R-D is optional by the proxy).

I do think, it would be opportune document it in a BCP to document/clarify the ambiguous stuff, and I can help to co-edit it if we decide to write one.

Explore the possibility to use other mechanisms (e.g. presence, something similar to XEP-0115) and define it would be also interesting,
but IMO it would require a major effort and more cycles and I am not so sure there are enough people willing to accomplish such effort.

cheers
Sal



On 3/30/10 9:05 PM, Adam Roach wrote:
[as chair]

One of the topics of discussion at the recent face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had significant discussion of some specific technical topics on the SIPCORE mailing list, such that all participants should have a reasonable overview of the scope that any related work may entail. Participants may also benefit from reading through the minutes of the corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method

Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discussion around whether we should, as a group, work on addressing some of the issues that have been identified.

In particular, we would direct the group to consider the nature of such work:
  • Are we proposing to introduce new features, or fix existing bugs?
  • If we are adding new features: is OPTIONS the best way to introduce these features, or would other mechanisms (presence, callee-caps) produce superior results?
  • If we are fixing bugs: are the bugs theoretical, or can we cite actual interoperability issues in the field?
  • If there are identified interoperability issues: is the level of effort involved in fixing them commensurate with the impact of the problems?
Finally, keep in mind that work does not happen unless participants are willing to invest time. If you speak out in favor of pursuing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., will author drafts; will perform dedicated reviews; etc).

Thanks.

/a
--------------090109050401030203060309-- From adam@nostrum.com Thu Apr 1 06:11:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC143A68B6 for ; Thu, 1 Apr 2010 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ttZgmZJq3Mh for ; Thu, 1 Apr 2010 06:11:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E13FE3A689B for ; Thu, 1 Apr 2010 06:11:08 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o31DBWMH089818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 08:11:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB49B85.6090408@nostrum.com> Date: Thu, 01 Apr 2010 08:11:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Salvatore Loreto References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: <4BB44CE6.2070402@ericsson.com> Content-Type: multipart/alternative; boundary="------------050502030001010302060402" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:11:11 -0000 This is a multi-part message in MIME format. --------------050502030001010302060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/1/10 02:36, Apr 1, Salvatore Loreto wrote: > Hi, > > A good mechanism to discovery UA capabilities is essential to provide > meaningful service: [as an individual] If this is true -- if it really is *essential* -- then we need something better than the "maybe it works, maybe it doesn't" level of functionality that we get from R-D. If discovery of UA capabilities is *essential*, then we need something that survives forking in all circumstances, like SUBSCRIBE/NOTIFY or something else that sends a request in both directions. I suspect it's more in the "nice to have" category. /a --------------050502030001010302060402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/1/10 02:36, Apr 1, Salvatore Loreto wrote:
Hi,

A good mechanism to discovery UA capabilities is essential to provide meaningful service:

[as an individual]

If this is true -- if it really is *essential* -- then we need something better than the "maybe it works, maybe it doesn't" level of functionality that we get from R-D. If discovery of UA capabilities is *essential*, then we need something that survives forking in all circumstances, like SUBSCRIBE/NOTIFY or something else that sends a request in both directions.

I suspect it's more in the "nice to have" category.

/a
--------------050502030001010302060402-- From keith.drage@alcatel-lucent.com Thu Apr 1 06:24:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA323A69E5 for ; Thu, 1 Apr 2010 06:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.088 X-Spam-Level: X-Spam-Status: No, score=-4.088 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa2cLvYyCQ8D for ; Thu, 1 Apr 2010 06:24:20 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9DD793A6912 for ; Thu, 1 Apr 2010 06:24:18 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o31DOZAi027627 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Apr 2010 15:24:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 1 Apr 2010 15:24:29 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Adam Roach Date: Thu, 1 Apr 2010 15:24:27 +0200 Thread-Topic: [sipcore] Consensus Call: SIP Table 2 Thread-Index: AcrRGpOCPmIVaxcjTKqhCZjnjsto0wAR/9mwAA3SQVA= Message-ID: References: <4BB24828.80805@nostrum.com> <4BB3C0F1.8050900@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: SIPCORE Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:24:22 -0000 There are essentially two potential parts of the work here: - Decide on the future documentation structure - work out how to deal with interactions with legacy specifications. SIPCORE is being asked only to decide on the first of these at the moment. As Adam says, most of the existing header field usage is fully defined. The= problem exists with certain header fields where it appears a somewhat arbi= trary analysis was given to the entries, and therefore the entries appear i= nconsistent.=20 An example of this is in the RFC 3329 header fields, where I personally wou= ld expect the semantics of these headers to be dealt with before one looks = at the method. That means they should appear in all methods, but you will s= ee from RFC 3329 that the headers are not valid in PRACK. With a set of documentation rules to follow, there are no legacy issues if = a new header field is defined. It follows one of the proforma rules, or cre= ates a new one. There is a legacy issue if a new method is created, but it is a long while = since we created a new method. Yes we hit the documentation issues with the= update to INFO and event packages, but for existing headers we can just ca= rry on with table 2 and 3 if we really need to. Or at that point we can cho= ose to create a new specification that updates those RFCs that do define he= ader fields. I would note however that that may well result in some technic= al change, due to perceived inconsistencies in the current definitions, as = in the example indicated above. At the moment I do not favour the existing table method of documentation. I do favour a set of proforma rules that specifiers can choose from. A couple of examples of these proforma rules would be something like: "The use of the header field is optional in all requests that are expected = to be exchanged end-to-end between UAs. Implementations of this extension M= UST support reception of this header field in such requests." "The use of the header field is optional in all requests that initiate a di= alog, or are used outside of a dialog being created. Implementations of thi= s extension MUST support reception of this header field in such requests." I suspect we could deal with most of the current header field usage with ab= out 10 or so such proforma rules, and I do not expect new header fields to = create a substantial set of new ones. These need to specify both use (mandatory/optional) and if it is not otherw= ise clear, support (mandatory/optional). The latter is missing from the exi= sting tables. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, April 01, 2010 7:45 AM > To: Adam Roach > Cc: SIPCORE > Subject: Re: [sipcore] Consensus Call: SIP Table 2 >=20 >=20 > Hi,=20 >=20 > >Just to clarify: both alternatives will leave whatever is=20 > currently unclear as it is.... > > =09 > > > >[as individual] > >=09 > >In truth, I don't think anything is particularly unclear --=20 > it's just=20 > >not documented the same way. The documents that didn't=20 > expand table 2 while adding new header fields all have prose=20 > that describes when the header field can appear. (Yes, I know=20 > this, because I looked at every one of them when I did the=20 > table 2 expansion that appears in the slides). > > > >So, you are saying that by reading the specs we would be=20 > able to complete the table you had put toghether? > >=09 > > [as chair] > >=09 > >But, yes, the consensus call only deals with actions as they=20 > apply to=20 > >future documents -- such as RFC3265bis -- and does not=20 > address actions that would affect RFCs or any other documents=20 > that have already cleared IETF review. > >=09 > >And, couldn't alternative 1 result in lots of "defined semantics" -=20 > >especially if we define a new method and may have to take a=20 > large number of header fields into consideration? Maybe=20 > you'll even end up with something that looks like Table 2... > > > > > >[as individual again] > >=09 > >I don't think so. As Keith has pointed out, statements like "both=20 > >header fields defined in this document can appear only in=20 > methods that=20 > >create new dialogs" fill out entire swaths of the table all=20 > at once. They also have the pleasantly future-proof quality=20 > that we don't need to say anything specifically about the=20 > header fields when someone creates a new method. A simple=20 > evaluation of the new method's properties against the header=20 > fields' normative text makes the answer brilliantly clear. >=20 > Sure. That is fine when you define new headers, and when you=20 > define new methods and need to cover those new headers. >=20 > But, when you define a new method, you still also need to=20 > consider all "old" existing header fields - for which we=20 > unfortunately do not have statements as those suggested by Keith. >=20 > Take 3265bis as an example, and assume you remove table 2.=20 > The text will of course describe the usage of header fields=20 > directly associated with SUB/NOT, eg. Allow-Events. But, how=20 > will you deal with all the other header fields that we have=20 > defined over the years? I am sure there are header fields=20 > that we do NOT need to cover, because they are associated=20 > with specific mechanisms (e.g. RSeq and RAck). But, there is=20 > a huge number of more "generic" header fields that somehow=20 > need to be covered. >=20 > Anyway, there is only one way to figure out: by doing the work :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 30. maaliskuuta 2010 21:51 > To: SIPCORE > Subject: [sipcore] Consensus Call: SIP Table 2 > =09 > =09 > [as chair] > =09 > Last week, at the face-to-face meeting in=20 > Anaheim, the SIPCORE participants in attendance had a=20 > discussion regarding the future of Tables 2 and 3 in RFC=20 > 3261. A summary of the conversation, along with links to the=20 > presentations and an audio recording of the conversation, can=20 > be found in the minutes: > =09 > =09 > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP > %20Table%202%20/%203 > =09 > During that conversation, the chairs polled=20 > those present for support between two options: > =09 >=20 > 1. Produce an artifact stating that=20 > documents defining new header fields and methods define=20 > semantics in prose, and will no longer extend Table 2; or > =09 > =09 > 2. Produce an RFC that defines new=20 > procedures for adding elements to Table 2 as new header=20 > fields and methods are defined=20 >=20 > Among those present, there was strong support=20 > for option 1. If you wish to raise an objection to this=20 > direction, please do so on the SIPCORE mailing list before April 15th. > =09 > Thank you. > =09 > /a > =09 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From HKaplan@acmepacket.com Thu Apr 1 15:26:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEF53A689D for ; Thu, 1 Apr 2010 15:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcW4gmKRICoK for ; Thu, 1 Apr 2010 15:26:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8924B3A6A66 for ; Thu, 1 Apr 2010 15:24:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 1 Apr 2010 18:25:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Apr 2010 18:25:12 -0400 From: Hadriel Kaplan To: Christer Holmberg , 'Adam Roach' , SIPCORE Date: Thu, 1 Apr 2010 18:25:11 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAB1i2VEAimGSFKUG42bG2CATAAPowaAAFszqxA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79E9303Fmail_" MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:26:22 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79E9303Fmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, Inline... ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, March 31, 2010 1:56 AM To: 'Adam Roach'; SIPCORE Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? Hi, Adam, thanks for sending out the the e-mail! First, a clarification regarding "new features": When we say "new features", I assume (based on Hadriel's comment in the mee= ting) it means the possibility to, with a single OPTIONS request, retrieve = the capabilities from ALL UAS(s) behind a forking proxy - instead of only o= ne UAS (whoever sends the 200 OK to the forking proxy first). Yeah what I meant was that in my opinion your slides had really two separat= e classes of topics: the first were "bugs", either in incorrectly or under-= specific RFC cases/text. Effectively things we would put into bugzilla, an= d possibly incorporate into any errata/bis someday. The second was the "I = want this request to go to all contacts for the AoR and get all their respo= nses", which is not a bug of the current specs. The message I got from the meeting, and also previous e-mail discussions, w= as that the "OPTIONS 3xx" solution already provideds this feature, and that= it can be used (without defining new protocol elements etc). Does it actually solve it? Sorry I wasn'f following the discussion of it o= n the mailing list, but...What if there is more than one proxy in the path = - which one is supposed to return 3xx? What if the first proxy has two routes for the AoR, and one of those points= to another proxy that also has two (different) routes for the AoR? Do you only want 3xx for Registered contact URI's? What if the proxy doesn= 't know whether they're Registered contact URI's vs. static routes? So, in my opinion the "adding" word is a little missleading. Instead I thin= k the question is whether we want to DOCUMENT that existing feature. Second, regarding bugs and interoperability issues in the field. Personally= I am not sure of any major ones at the moment, but that is probably becaus= e OPTIONS haven't been very much deployed in the first place (it has been u= sed for some keep-alive/ping purposes, but in those cases it really doesn't= matter what comes in the response etc). Funny enough that's the only area I've ever actually seen OPTIONS interop p= roblems - the response code. We seem to need to map the response code to s= omething different a lot. Not sure why though. Now, however, at least I am starting to get questions regarding the usage o= f OPTIONS, so I guess we need to ask ourselves whether we think the bugs WI= LL create interoperability issues. And, the issue you raised regarding using the re-INVITE to re-create dialog= s ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also affects OPTIO= NS, eventhough you want to keep them separate (which is ok). Obviously I am in favor of pursuing the work, and will be willing to author= drafts :) Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 30. maaliskuuta 2010 22:06 To: SIPCORE Subject: [sipcore] SIP OPTIONS: Shall we work on this? [as chair] One of the topics of discussion at the recent face-to-face meeting in Anahe= im was the SIP OPTIONS method. We have had significant discussion of some s= pecific technical topics on the SIPCORE mailing list, such that all partici= pants should have a reasonable overview of the scope that any related work = may entail. Participants may also benefit from reading through the minutes = of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTI= ONS%20Method Rather than continue discussion of the specific technical topics related to= OPTIONS, the chairs would encourage the working group to engage in a discu= ssion around whether we should, as a group, work on addressing some of the = issues that have been identified. In particular, we would direct the group to consider the nature of such wor= k: * Are we proposing to introduce new features, or fix existing bugs? * If we are adding new features: is OPTIONS the best way to introduce th= ese features, or would other mechanisms (presence, callee-caps) produce sup= erior results? * If we are fixing bugs: are the bugs theoretical, or can we cite actual= interoperability issues in the field? * If there are identified interoperability issues: is the level of effor= t involved in fixing them commensurate with the impact of the problems? Finally, keep in mind that work does not happen unless participants are wil= ling to invest time. If you speak out in favor of pursuing this work, pleas= e indicate the level of time commitment that you will personally invest in = bringing such work to a successful conclusion (e.g., will author drafts; wi= ll perform dedicated reviews; etc). Thanks. /a --_000_430FC6BDED356B4C8498F634416644A91A79E9303Fmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,<= /p>

Inline…=

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Christer Holmberg
Sent: Wednesday, March 31, 2= 010 1:56 AM
To: 'Adam Roach'; SIPCORE
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

=  

Hi,

=  

Adam, thanks for sending out the the e-mail!

=  

First, a clarification regarding "new features":

=  

When we say "new features", I assume (based on Hadriel's comment in the meeting) it means the possibility to, with a single OPTIONS request,&n= bsp;retrieve the capabilities from ALL UAS(s) behind a forking proxy - instead of o= nly one UAS (whoever sends the 200 OK to the forking proxy first).<= /font>

<= span style=3D'font-size:12.0pt;color:navy'> 

Yeah what I meant was that in my opini= on your slides had really two separate classes of topics: the first were “bug= s”, either in incorrectly or under-specific RFC cases/text.  Effectively things we would put into bugzilla, and possibly incorporate into any errata= /bis someday.  The second was the “I want this request to go to all contacts for the AoR and get all their responses”, which is not a bug= of the current specs. 

 

=  

The message I got from the meeting, an= d also previous e-mail discussions, was that the "OPTIONS 3xx" solu= tion already provideds this feature, and that it can be used (without defining n= ew protocol elements etc).

=  

Does it actually solve it?  Sorry= I wasn’f following the discussion of it on the mailing list, but…= What if there is more than one proxy in the path – which one is supposed t= o return 3xx? 

What if the first proxy has two routes= for the AoR, and one of those points to another proxy that also has two (differ= ent) routes for the AoR?  

Do you only want 3xx for Registered contact URI’s?  What if the proxy doesn’t know whether the= y’re Registered contact URI’s vs. static routes?  <= /font>

 

So, in my opinion the "adding&quo= t; word is a little missleading. Instead I think the question is whether we wa= nt to DOCUMENT that existing feature.

=   

Second, regarding bugs and interoperability issues in the field. Personally I am not sure of any major ones at the moment, but that is probably because OPTIONS haven't been very = much deployed in the first place (it has been used for some keep-alive/ping purposes, but in those cases it really doesn't matter what comes in the response etc). <= /font>

 

Funny enough that’s the only are= a I’ve ever actually seen OPTIONS interop problems – the response code. = ; We seem to need to map the response code to something different a lot.  N= ot sure why though.

 

Now, however, at least I am starting t= o get questions regarding the usage of OPTIONS, so I guess we need to ask ourselves whether we think the bugs WILL create interoperability issues.

=  

And, the issue you raised regarding using the re-INVITE to re-create dialogs ("[sipcore] Me= a Culpa: Dialog Necromancy in RFC 3261") also affects OPTIONS, eventhoug= h you want to keep them separate (which is ok).

=  

Obviously I am in favor of pursuing th= e work, and will be willing to author drafts :)

=  

Regards,

=  

Christer

=  

=  

=  

=  

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 30. maaliskuuta 2010 2= 2:06
To: SIPCORE
Subject: [sipcore] SIP OPTIO= NS: Shall we work on this?

= [as chair]

One of the topics of discussion at the recent face-to-face meeting in Anaheim was the S= IP OPTIONS method. We have had significant discussion of some specific technic= al topics on the SIPCORE mailing = list, such that all participants should have a reasonable overview of the scope t= hat any related work may entail. Participants may also benefit from reading thr= ough the minutes of the corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcore= .html#The%20SIP%20OPTIONS%20Method

Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discus= sion around whether we should, as a group, work on addressing some of the issues that have been identified.

In particular, we would direct the group to consider the nature of such wor= k:

  • Are we proposing to introduce new features,= or fix existing bugs?
  • If we are adding new features: is OPTIONS t= he best way to introduce these features, or would other mechanisms (prese= nce, callee-caps) produce superior results?
  • If we are fixing bugs: are the bugs theoret= ical, or can we cite actual interoperability issues in the field?
  • If there are identified interoperability is= sues: is the level of effort involved in fixing them commensurate with the impact of the problems?

= Finally, keep in mind that work does not happen = unless participants are willing to invest time. If you speak out in favor of pursu= ing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., w= ill author drafts; will perform dedicated reviews; etc).

Thanks.

/a

--_000_430FC6BDED356B4C8498F634416644A91A79E9303Fmail_-- From HKaplan@acmepacket.com Thu Apr 1 15:32:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF743A68E5 for ; Thu, 1 Apr 2010 15:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id De-TrnMuwuRc for ; Thu, 1 Apr 2010 15:32:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A33AE3A6869 for ; Thu, 1 Apr 2010 15:32:47 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 1 Apr 2010 18:33:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Apr 2010 18:33:19 -0400 From: Hadriel Kaplan To: Salvatore Loreto , "sipcore@ietf.org" Date: Thu, 1 Apr 2010 18:33:19 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbiscsLyjPDmeQNepI4WI9i7HfwAfCR7w Message-ID: <430FC6BDED356B4C8498F634416644A91A79E93040@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: <4BB44CE6.2070402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79E93040mail_" MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:32:56 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79E93040mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Salvatore, When you say "is essential to providing meaningful service" in what way do = you mean that? Do you mean literally that you need any UAC anywhere to be able to discover= the capabilities of any arbitrary UAS it might want to communicate with in= the World using OPTIONS? Or do you mean within a provider's domain, having an App Server figure out = what each registered UA endpoint supports and putting that in some database= is very useful? (which I could see 3GPP doing) Because if it's the latter, then creating an options-tag for rfc3841 and pu= tting it in Proxy-Require isn't that bad an idea - proxy-require only has d= eployment issues when you want to use it across proxies outside of your adm= inistrative control. -hadriel ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Salvatore Loreto Sent: Thursday, April 01, 2010 3:36 AM To: sipcore@ietf.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? Hi, A good mechanism to discovery UA capabilities is essential to provide meani= ngful service: So I am in favor of pursuing the work, in particular the possibility to use a single OPTIONS request to retrieve t= he capabilities from ALL UAS(s) behind a forking proxy. I agree with Christer, that as discussed in the ml and during the f2f meeti= ng, the 3xx solution already provide this feature even if with the limitations Paul has highlighted (e.g. honoring R-D is opt= ional by the proxy). I do think, it would be opportune document it in a BCP to document/clarify = the ambiguous stuff, and I can help to co-edit it if we decide to write one= . Explore the possibility to use other mechanisms (e.g. presence, something s= imilar to XEP-0115) and define it would be also interesting, but IMO it would require a major effort and more cycles and I am not so sur= e there are enough people willing to accomplish such effort. cheers Sal On 3/30/10 9:05 PM, Adam Roach wrote: [as chair] One of the topics of discussion at the recent face-to-face meeting in Anahe= im was the SIP OPTIONS method. We have had significant discussion of some s= pecific technical topics on the SIPCORE mailing list, such that all partici= pants should have a reasonable overview of the scope that any related work = may entail. Participants may also benefit from reading through the minutes = of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTI= ONS%20Method Rather than continue discussion of the specific technical topics related to= OPTIONS, the chairs would encourage the working group to engage in a discu= ssion around whether we should, as a group, work on addressing some of the = issues that have been identified. In particular, we would direct the group to consider the nature of such wor= k: * Are we proposing to introduce new features, or fix existing bugs? * If we are adding new features: is OPTIONS the best way to introduce th= ese features, or would other mechanisms (presence, callee-caps) produce sup= erior results? * If we are fixing bugs: are the bugs theoretical, or can we cite actual= interoperability issues in the field? * If there are identified interoperability issues: is the level of effor= t involved in fixing them commensurate with the impact of the problems? Finally, keep in mind that work does not happen unless participants are wil= ling to invest time. If you speak out in favor of pursuing this work, pleas= e indicate the level of time commitment that you will personally invest in = bringing such work to a successful conclusion (e.g., will author drafts; wi= ll perform dedicated reviews; etc). Thanks. /a --_000_430FC6BDED356B4C8498F634416644A91A79E93040mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Salvatore,=

When you say “is essential to pr= oviding meaningful service” in what way do you mean that?

Do you mean literally that you need an= y UAC anywhere to be able to discover the capabilities of any arbitrary UAS it mi= ght want to communicate with in the World using OPTIONS?

Or do you mean within a provider’= ;s domain, having an App Server figure out what each registered UA endpoint supports and putting that in some database is very useful? (which I could s= ee 3GPP doing)

Because if it’s the latter, then creating an options-tag for rfc3841 and putting it in Proxy-Require isnR= 17;t that bad an idea – proxy-require only has deployment issues when you = want to use it across proxies outside of your administrative control.=

 

-hadriel

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Salvatore Loreto
Sent: Thursday, April 01, 20= 10 3:36 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

=  

= Hi,

A good mechanism to discovery UA capabilities is essential to provide meaningful service:
So I am in favor of pursuing the work,
in particular the possibility to use a single OPTIONS request to retrieve t= he capabilities from ALL UAS(s) behind a forking proxy.

I agree with Christer, that as discussed in the ml and during the f2f meeti= ng, the 3xx solution already provide this feature
even if with the limitations Paul has highlighted (e.g. honoring R-D is optional by the proxy).

I do think, it would be opportune document it in a BCP to document/clarify = the ambiguous stuff, and I can help to co-edit it if we decide to write one.
Explore the possibility to use other mechanisms (e.g. presence, something similar to XEP-0115) and define it would be also interesting,
but IMO it would require a major effort and more cycles and I am not so sur= e there are enough people willing to accomplish such effort.

cheers
Sal



On 3/30/10 9:05 PM, Adam Roach wrote:

= [as chair]

One of the topics of discussion at the recent face-to-face meeting in Anaheim was the S= IP OPTIONS method. We have had significant discussion of some specific technic= al topics on the SIPCORE mailing = list, such that all participants should have a reasonable overview of the scope t= hat any related work may entail. Participants may also benefit from reading thr= ough the minutes of the corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcor= e.html#The%20SIP%20OPTIONS%20Method

Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discus= sion around whether we should, as a group, work on addressing some of the issues that have been identified.

In particular, we would direct the group to consider the nature of such wor= k:

  • Are we proposing to introduce new features,= or fix existing bugs?
  • If we are adding new features: is OPTIONS t= he best way to introduce these features, or would other mechanisms (prese= nce, callee-caps) produce superior results?
  • If we are fixing bugs: are the bugs theoret= ical, or can we cite actual interoperability issues in the field?=
  • If there are identified interoperability is= sues: is the level of effort involved in fixing them commensurate with the impact of the problems?

= Finally, keep in mind that work does not happen = unless participants are willing to invest time. If you speak out in favor of pursu= ing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., w= ill author drafts; will perform dedicated reviews; etc).

Thanks.

/a

--_000_430FC6BDED356B4C8498F634416644A91A79E93040mail_-- From pkyzivat@cisco.com Thu Apr 1 16:24:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0261F3A6894 for ; Thu, 1 Apr 2010 16:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.633 X-Spam-Level: X-Spam-Status: No, score=-8.633 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhuim0HrZ0Wg for ; Thu, 1 Apr 2010 16:24:36 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 349773A6877 for ; Thu, 1 Apr 2010 16:24:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPHtEutJV2a/2dsb2JhbACbSnGdAZkNglmCKAQ X-IronPort-AV: E=Sophos;i="4.51,351,1267401600"; d="scan'208";a="98144724" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 01 Apr 2010 23:25:08 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o31NP74M022198; Thu, 1 Apr 2010 23:25:07 GMT Message-ID: <4BB52B53.7000102@cisco.com> Date: Thu, 01 Apr 2010 19:25:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: SIPCORE Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 23:24:38 -0000 Comments inline. I trimmed out the irrelevant. I guessed which was Hadriel - apparently the only distinction was color, at least for me. Hadriel Kaplan wrote: > Hi Christer, > > Inline… > > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Christer Holmberg > *Sent:* Wednesday, March 31, 2010 1:56 AM > *To:* 'Adam Roach'; SIPCORE > *Subject:* Re: [sipcore] SIP OPTIONS: Shall we work on this? ... > The message I got from the meeting, and also previous e-mail > discussions, was that the "OPTIONS 3xx" solution already provideds this > feature, and that it can be used (without defining new protocol elements > etc). > > Does it actually solve it? Sorry I wasn’f following the discussion of > it on the mailing list, but…What if there is more than one proxy in the > path – which one is supposed to return 3xx? > > What if the first proxy has two routes for the AoR, and one of those > points to another proxy that also has two (different) routes for the AoR? That should all be handled by recursion on 3xx response processing. The first proxy would return 3xx with its choices. One of those would lead to the 2nd proxy, that then would return its own 3xx. > Do you only want 3xx for Registered contact URI’s? What if the proxy > doesn’t know whether they’re Registered contact URI’s vs. static routes? IMO this is one of the big problems with the IMS approach to services. They aren't registered, and aren't anything that the S-CSCF could (or would) return as 3xx alternatives. So the caller will be limited in what options are visible to it. Thanks, Paul From peter.musgrave@magorcorp.com Fri Apr 2 03:05:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2571D3A67A4 for ; Fri, 2 Apr 2010 03:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.567 X-Spam-Level: * X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5tmLI31FDjX for ; Fri, 2 Apr 2010 03:05:29 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id CFED53A67A7 for ; Fri, 2 Apr 2010 03:04:36 -0700 (PDT) Received: by gwj15 with SMTP id 15so1308659gwj.31 for ; Fri, 02 Apr 2010 03:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.54.16 with HTTP; Fri, 2 Apr 2010 03:05:04 -0700 (PDT) In-Reply-To: <4BB52B53.7000102@cisco.com> References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> Date: Fri, 2 Apr 2010 06:05:04 -0400 Received: by 10.150.244.8 with SMTP id r8mr2807549ybh.206.1270202704219; Fri, 02 Apr 2010 03:05:04 -0700 (PDT) Message-ID: From: Peter Musgrave To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 10:05:30 -0000 Hi all, I agree with the assertion (Hadrials?) that there are two things here: bugs in OPTIONS and a need to query multiple UAs. I have not seen wide use of OPTIONS and have not encountered these bugs, In general I favour fixing them but I am not sure if this is more important that other work which could be done. As for assessing multiple UA capabilities - I agree this is useful. Is OPTIONS the only way forward here? Could I not use e.g. gruu-reg-event and then send specifically targeted OPTIONS to each gruu? Is requiring gruu support in UAs viewed as 'setting the bar too high?' This fails to pick up forking due to dial plan entries - is that a requirement? Peter Musgrave From brett@broadsoft.com Fri Apr 2 04:59:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593903A6900 for ; Fri, 2 Apr 2010 04:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQgy2B4r4kYS for ; Fri, 2 Apr 2010 04:59:32 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 97DD53A68F8 for ; Fri, 2 Apr 2010 04:59:32 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 2 Apr 2010 05:00:06 -0700 From: Brett Tate To: Adam Roach , "sipcore@ietf.org" Date: Fri, 2 Apr 2010 04:59:13 -0700 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRnOPsq1ZuSJVTRGOInUS2xKxYrwAt2u5w Message-ID: <747A6506A991724FB09B129B79D5FEB61480B2D522@EXMBXCLUS01.citservers.local> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <4BB49B85.6090408@nostrum.com> In-Reply-To: <4BB49B85.6090408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AAiJ Dka1 DySL EM4b EkKG ErpD FL08 HM/l IYYw I0yS MAck MO6a MZon Mllj RD/S SyGQ; 2; YQBkAGEAbQBAAG4AbwBzAHQAcgB1AG0ALgBjAG8AbQA7AHMAaQBwAGMAbwByAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {75FB3152-0F5B-44B6-ADDD-A3BE695D0835}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Fri, 02 Apr 2010 11:59:13 GMT; UgBFADoAIABbAHMAaQBwAGMAbwByAGUAXQAgAFMASQBQACAATwBQAFQASQBPAE4AUwA6ACAAUwBoAGEAbABsACAAdwBlACAAdwBvAHIAawAgAG8AbgAgAHQAaABpAHMAPwA= x-cr-puzzleid: {75FB3152-0F5B-44B6-ADDD-A3BE695D0835} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:59:33 -0000 > If discovery of UA capabilities is *essential*, then we need=20 > something that survives forking in all circumstances, like=20 > SUBSCRIBE/NOTIFY or something else that sends a request in=20 > both directions. Concerning forking, I agree that SUBSCRIBE/NOTIFY usage is better than OPTI= ONS. However is there a routing issue concerning SUBSCRIBE? More specific= ally since INVITE and OPTIONS supposedly result in the same response status= code, OPTIONS supposedly gets routed like INVITE. Is there currently a re= quirement upon middle boxes to route SUBSCRIBE the same as INVITE? From paulej@packetizer.com Fri Apr 2 14:01:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C0D3A6C17 for ; Fri, 2 Apr 2010 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv-MZWUsqXzj for ; Fri, 2 Apr 2010 14:01:07 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 350F93A6B79 for ; Fri, 2 Apr 2010 13:46:58 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o32KlPRb018410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Apr 2010 16:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270241250; bh=Rx1u9YHXNL0FcyQ8MSDpClvB1lJ0upUczxeov7O9XBE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=ncDR78T7SJOZmXXuPK96JfWJepDXkGJfDak+A6+XAYTmG2u3H9mE8F8zGOtU3Kbbb hLAI88wpvVY1Ol7pKHGdl0JjK+EwdCEqCI+I/Wp+iMHgaERU2ngW7UK8RREHvO4zj5 1fTyaHlL9yC/EvW814IWZwzLl+VFd2cknlXPlcCw= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o32KlOWT006769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 16:47:24 -0400 From: "Paul E. Jones" To: Date: Fri, 2 Apr 2010 16:47:16 -0400 Message-ID: <01a201cad2a5$ae1096c0$0a31c440$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01A3_01CAD284.26FEF6C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqA Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , 'Gonzalo Salgueiro' Subject: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:01:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A3_01CAD284.26FEF6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I wanted to bring your attention to an Internet Draft we submitted today related to one use of the SIP OPTIONS message. This draft describes the use of OPTIONS as an application-level "ping" mechanism. It is important to point out two things: 1) We are not defining any new extensions to SIP, but merely attempt to define the use of OPTIONS as a "ping" mechanism in a way that will be interoperable. We've found a lot of equipment that does this and it is done inconsistently from one vendor or product to the next. We believe we need to ensure that devices implement an OPTIONS "ping" mechanism with some level of consistency and suggest either a standards track document or a BCP-type document. 2) These procedures are not intended to be used in lieu of a proper load balancing or capacity reporting mechanism: the scope is deliberately narrowly focused to allowing a SIP entity to determine the status of another entity, usually a next-hop neighbor. We would welcome any comments on the draft. 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, April 02, 2010 11:00 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-jones-sip-options-ping-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Using OPTIONS to Query for Operational Status > in the Session Initiation Protocol (SIP) > Author(s) : V. Bhargava, et al. > Filename : draft-jones-sip-options-ping-00.txt > Pages : 7 > Date : 2010-04-02 > > This document describes a procedure for using the OPTIONS method > defined for the Session Initiation Protocol (SIP) in order to allow one > SIP entity to query the status of another SIP entity. Through > discovery of the status of a SIP entity, it is possible to expedite > session establishment or provide diagnostic information to network > administrators. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-sip-options-ping-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_01A3_01CAD284.26FEF6C0 Content-Type: Message/External-body; name="draft-jones-sip-options-ping-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-jones-sip-options-ping-00.txt" Content-Type: text/plain Content-ID: <2010-04-02075639.I-D@ietf.org> ------=_NextPart_000_01A3_01CAD284.26FEF6C0 Content-Type: text/plain; name="ATT00305.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00305.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 ------=_NextPart_000_01A3_01CAD284.26FEF6C0-- From kpfleming@digium.com Fri Apr 2 14:37:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A61C3A6B2D for ; Fri, 2 Apr 2010 14:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.32 X-Spam-Level: X-Spam-Status: No, score=-104.32 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UIUHCJ3PC1H for ; Fri, 2 Apr 2010 14:37:27 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 7B9E33A6B7E for ; Fri, 2 Apr 2010 14:22:33 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NxoKZ-0007Pa-9z; Fri, 02 Apr 2010 16:23:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 4CD0F1A2009; Fri, 2 Apr 2010 16:23:07 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M+srOPxhnjQ; Fri, 2 Apr 2010 16:23:07 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id E04581A2006; Fri, 2 Apr 2010 16:23:06 -0500 (CDT) Message-ID: <4BB66039.9030105@digium.com> Date: Fri, 02 Apr 2010 16:23:05 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> In-Reply-To: <01a201cad2a5$ae1096c0$0a31c440$@com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:37:28 -0000 Paul E. Jones wrote: > We would welcome any comments on the draft. This text: > When a receiving SIP entity is experiencing heavy load, but still > willing to accept new dialogs, it SHOULD return a 486 response code. > In receipt of a 486, the querying SIP entity SHOULD make an effort > to avoid establishing new dialogs with the heavily loaded server > until it subsequently receives a 200 from that server. > could conceivably be interpreted by a reader in such a way that they'd expect to receive the 200 response without having to have sent an additional OPTIONS; anyone who understands SIP at all should not reach that conclusion, but a change to '... until it receives a 200 response code to a subsequent OPTIONS message sent to that server' would eliminate any possible confusion. This may be more than you intend to include in your draft, but in Asterisk we use the response time to OPTIONS pings to adjust the T1 timer for future requests to that server as well, in order to reduce delays when attempting to route calls. Since part of the purpose of this draft is to document a method to reduce session delivery delays, is it worth considering documenting this behavior as well? -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From paulej@packetizer.com Fri Apr 2 16:31:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CAD3A69B8 for ; Fri, 2 Apr 2010 16:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtgJpV2+z+H5 for ; Fri, 2 Apr 2010 16:31:45 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 8EBB23A693B for ; Fri, 2 Apr 2010 16:31:45 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o32NWB7C024007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Apr 2010 19:32:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270251136; bh=rhte5WY7GucVw3WH/nJUnMhd+AdGEz/GfKTLtnTxjwQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bOZz8xi8qSv0K7JcqBiBQrm7Hiq8EeZkViqmB7X3hO9FsjEOCcdrgcdloO257uoaL aU9KmRRgQ1sVJS2ntKBpKnijsmMOpaWKs/oIkFQbBFdEveTBtkOT5AyGf0DYr/BMmR 0ukzn1AhcGKxuuxFv98Ht90k83HVNK8NxhNizBkM= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o32NWAHA007160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 19:32:10 -0400 From: "Paul E. Jones" To: "'Kevin P. Fleming'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <4BB66039.9030105@digium.com> In-Reply-To: <4BB66039.9030105@digium.com> Date: Fri, 2 Apr 2010 19:32:01 -0400 Message-ID: <01d001cad2bc$b259bab0$170d3010$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSqrQFJhccETn3TEOm/N5Bu9b0DAAEP/SQ Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 23:31:46 -0000 Kevin, > could conceivably be interpreted by a reader in such a way that they'd > expect to receive the 200 response without having to have sent an > additional OPTIONS; anyone who understands SIP at all should not reach > that conclusion, but a change to '... until it receives a 200 response > code to a subsequent OPTIONS message sent to that server' would > eliminate any possible confusion. Great suggestion. I've made the change in my local draft to what you propose. > This may be more than you intend to include in your draft, but in > Asterisk we use the response time to OPTIONS pings to adjust the T1 > timer for future requests to that server as well, in order to reduce > delays when attempting to route calls. Since part of the purpose of > this > draft is to document a method to reduce session delivery delays, is it > worth considering documenting this behavior as well? I'm certainly open to what makes sense. The objective, of course, is to try to reach some form of consensus on how this ought to be done and to provide guidance, as I'm seeing so much variation in something that should be so simple. My first target was really the response codes. You'll note I didn't propose changing the rules (at least as I understand them), but it amazes me as to how many different response codes I've seen related to use of OPTIONS as a ping mechanism. I'm most certainly open to adding other recommendations to the draft. I don't mind playing editor and taking input from all interested parties. Paul From christer.holmberg@ericsson.com Sat Apr 3 03:51:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F8C3A69E1 for ; Sat, 3 Apr 2010 03:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTZRgaUKr+SG for ; Sat, 3 Apr 2010 03:51:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4506F3A67AB for ; Sat, 3 Apr 2010 03:51:10 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-f5-4bb71d9d8be3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B6.88.23740.D9D17BB4; Sat, 3 Apr 2010 12:51:09 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 3 Apr 2010 12:51:08 +0200 From: Christer Holmberg To: 'Adam Roach' , Salvatore Loreto Date: Sat, 3 Apr 2010 12:51:07 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRnOTDg+FVnUu9SumQUksqK7d6ZQBa0asA Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <4BB49B85.6090408@nostrum.com> In-Reply-To: <4BB49B85.6090408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 10:51:12 -0000 Hi, >> Hi, >>=09 >> A good mechanism to discovery UA capabilities is essential to provide me= aningful service: >>=09 >> >> >[as an individual] > >If this is true -- if it really is *essential* -- then we need something b= etter than the "maybe it works, maybe it doesn't" level of functionality th= at we get from R-D. If discovery of UA capabilities is=20 >*essential*, then we need something that survives forking in all circumsta= nces, like SUBSCRIBE/NOTIFY or something else that sends a request in both = directions. SUB/NOT is only going to work if the involved entities support the associat= ed event package. So, it's still a "maybe it works, maybe it doesn't". It is true that we on a protocol level cannot ensure that proxies will supp= ort this, but in reality people will implement extensions based on the serv= ices and capabilities that they want to provide.=20 Also, the more usefulness of extensions (in this case 3841) we can show, th= e more likely it is that people will implement/demand them. >I suspect it's more in the "nice to have" category. I don't agree. As Sal said, it is essential in some cases. Regards, Christer From christer.holmberg@ericsson.com Sat Apr 3 04:00:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FC83A67AB for ; Sat, 3 Apr 2010 04:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.012 X-Spam-Level: X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1thFDdeuyCZt for ; Sat, 3 Apr 2010 04:00:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 986B03A672F for ; Sat, 3 Apr 2010 04:00:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-e1-4bb71fcf2f31 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D9.CA.23532.FCF17BB4; Sat, 3 Apr 2010 13:00:32 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 3 Apr 2010 13:00:31 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , 'Adam Roach' , SIPCORE Date: Sat, 3 Apr 2010 13:00:30 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAB1i2VEAimGSFKUG42bG2CATAAPowaAAFszqxAATRFkUA== Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A915ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:00:44 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A915ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Adam, thanks for sending out the the e-mail! First, a clarification regarding "new features": When we say "new features", I assume (based on Hadriel's comment in the mee= ting) it means the possibility to, with a single OPTIONS request, retrieve = the capabilities from ALL UAS(s) behind a forking proxy - instead of only o= ne UAS (whoever sends the 200 OK to the forking proxy first). Yeah what I meant was that in my opinion your slides had really two separat= e classes of topics: the first were "bugs", either in incorrectly or under-= specific RFC cases/text. Effectively things we would put into bugzilla, an= d possibly incorporate into any errata/bis someday. The second was the "I = want this request to go to all contacts for the AoR and get all their respo= nses", which is not a bug of the current specs. I agree. I tried to make that separation in my presentation, by = talking about "unclear specifications"/bugs and "forking". I never intended= to say that the forking case was a bug, simply that the way it is normally= used very much limits it's usability in forking cases. The message I got from the meeting, and also previous e-mail discussions, w= as that the "OPTIONS 3xx" solution already provideds this feature, and that= it can be used (without defining new protocol elements etc). Does it actually solve it? Sorry I wasn'f following the discussion of it o= n the mailing list, but...What if there is more than one proxy in the path = - which one is supposed to return 3xx? What if the first proxy has two routes for the AoR, and one of those points= to another proxy that also has two (different) routes for the AoR? Do you only want 3xx for Registered contact URI's? What if the proxy doesn= 't know whether they're Registered contact URI's vs. static routes? I have mostly been thinking about the registrar returning the 3x= x, but there could be cases where another forking proxy also sends 3xx, and= maybe the UAC can already make some decissions based on that. Now, in theo= ry this could of course lead to a series of 3xx response, but in real life = I don't think that is going to happen. When forking occurs in the first pla= ce, I think the majority of cases will contain one point of forking. In som= e cases there may be two points of forking, but more than that I think is g= oing to be extremely rare... But, if someone thinks I'm wrong I would reall= y much like to hear about it :) Regards, Christer So, in my opinion the "adding" word is a little missleading. Instead I thin= k the question is whether we want to DOCUMENT that existing feature. Second, regarding bugs and interoperability issues in the field. Personally= I am not sure of any major ones at the moment, but that is probably becaus= e OPTIONS haven't been very much deployed in the first place (it has been u= sed for some keep-alive/ping purposes, but in those cases it really doesn't= matter what comes in the response etc). Funny enough that's the only area I've ever actually seen OPTIONS interop p= roblems - the response code. We seem to need to map the response code to s= omething different a lot. Not sure why though. Now, however, at least I am starting to get questions regarding the usage o= f OPTIONS, so I guess we need to ask ourselves whether we think the bugs WI= LL create interoperability issues. And, the issue you raised regarding using the re-INVITE to re-create dialog= s ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also affects OPTIO= NS, eventhough you want to keep them separate (which is ok). Obviously I am in favor of pursuing the work, and will be willing to author= drafts :) Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 30. maaliskuuta 2010 22:06 To: SIPCORE Subject: [sipcore] SIP OPTIONS: Shall we work on this? [as chair] One of the topics of discussion at the recent face-to-face meeting in Anahe= im was the SIP OPTIONS method. We have had significant discussion of some s= pecific technical topics on the SIPCORE mailing list, such that all partici= pants should have a reasonable overview of the scope that any related work = may entail. Participants may also benefit from reading through the minutes = of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTI= ONS%20Method Rather than continue discussion of the specific technical topics related to= OPTIONS, the chairs would encourage the working group to engage in a discu= ssion around whether we should, as a group, work on addressing some of the = issues that have been identified. In particular, we would direct the group to consider the nature of such wor= k: * Are we proposing to introduce new features, or fix existing bugs? * If we are adding new features: is OPTIONS the best way to introduce th= ese features, or would other mechanisms (presence, callee-caps) produce sup= erior results? * If we are fixing bugs: are the bugs theoretical, or can we cite actual= interoperability issues in the field? * If there are identified interoperability issues: is the level of effor= t involved in fixing them commensurate with the impact of the problems? Finally, keep in mind that work does not happen unless participants are wil= ling to invest time. If you speak out in favor of pursuing this work, pleas= e indicate the level of time commitment that you will personally invest in = bringing such work to a successful conclusion (e.g., will author drafts; wi= ll perform dedicated reviews; etc). Thanks. /a --_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A915ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

=  A= dam,=20 thanks for sending out the the e-mail!

=  

First, a=20 clarification regarding "new features":

=  

When we=20 say "new features", I assume (based on Hadriel's comment in the=20 meeting) it means the possibility to, with a single OPTIONS=20 request, retrieve the capabilities from ALL UAS(s) behind a forking pr= oxy=20 - instead of only one UAS (whoever sends the 200 OK to the forkin= g=20 proxy first).

<= SPAN=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"> 

Yeah what I mean= t was=20 that in my opinion your slides had really two separate classes of topics: t= he=20 first were “bugs”, either in incorrectly or under-specific RFC = cases/text.=20  Effectively things we would put into bugzilla, and possibly incorpora= te=20 into any errata/bis someday.  The second was the “I want this re= quest to go=20 to all contacts for the AoR and get all their responses”, which is no= t a bug of=20 the current specs. 

 

<Christer> I agree. = I tried=20 to make that separation in my presentation, by talking about "unclear=20 specifications"/bugs and "forking". I never intended to say that the forkin= g=20 case was a bug, simply that the way it is normally used very much limi= ts=20 it's usability in forking cases.

=  

The message I go= t from=20 the meeting, and also previous e-mail discussions, was that the "OPTIONS 3x= x"=20 solution already provideds this feature, and that it can be used (without=20 defining new protocol elements etc).

=  

Does it actually= solve=20 it?  Sorry I wasn’f following the discussion of it on the mailin= g list,=20 but…What if there is more than one proxy in the path – which on= e is supposed to=20 return 3xx? 

What if the firs= t proxy=20 has two routes for the AoR, and one of those points to another proxy that a= lso=20 has two (different) routes for the AoR?  

Do you only want= 3xx=20 for Registered contact URI’s?  What if the proxy doesn’t k= now whether=20 they’re Registered contact URI’s vs. static routes?  =  

 

<Christer> I have mo= stly been=20 thinking about the registrar returning the 3xx, but there could be cases wh= ere=20 another forking proxy also sends 3xx, and maybe the UAC can already make so= me=20 decissions based on that. Now, in theory this could of course lead to a ser= ies=20 of 3xx response, but in real life I don't think that is going to happen. Wh= en=20 forking occurs in the first place, I think the majority of cases will conta= in=20 one point of forking. In some cases there may be two points of forking, but= more=20 than that I think is going to be extremely rare... But, if someone thinks I= 'm=20 wrong I would really much like to hear about it=20 :)

=  

Regards,

=  

Christer

=  

 

 

 

 

So, in my opinio= n the=20 "adding" word is a little missleading. Instead I think the question is whet= her=20 we want to DOCUMENT that existing feature.

=   

Second, regardin= g bugs=20 and interoperability issues in the field. Personally I am not sure of any m= ajor=20 ones at the moment, but that is probably because OPTIONS haven't been very = much=20 deployed in the first place (it has been used for some keep-alive/ping= =20 purposes, but in those cases it really doesn't matter what comes in the res= ponse=20 etc).

 

Funny enough tha= t’s the=20 only area I’ve ever actually seen OPTIONS interop problems – th= e response=20 code.  We seem to need to map the response code to something different= a=20 lot.  Not sure why though.

 

Now, however, at= least=20 I am starting to get questions regarding the usage of OPTIONS, so I guess w= e=20 need to ask ourselves whether we think the bugs WILL create interoperabilit= y=20 issues.

=  

And, the issue y= ou=20 raised regarding using the re-INVITE to re-create dialogs ("[sipcore] = Mea=20 Culpa: Dialog Necromancy in RFC 3261") also affects OPTIONS, eventhough you= want=20 to keep them separate (which is ok).

=  

Obviously I am i= n favor=20 of pursuing the work, and will be willing to author drafts=20 :)

=  

Regards,<= /FONT>

=  

Christer<= /FONT>

=  

=  

=  

=  

From:=20 sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent:= =20 30. maaliskuuta 2010 22:06
To:=20 SIPCORE
Subject: [sipcore] SIP OPTIONS: Shal= l we=20 work on this?

= [as chair]

One of the topics of discussion= at the=20 recent face-to-face meeting in Anaheim was the SIP OPTIONS method. We h= ave had=20 significant discussion of some specific technical topics on the SIPCORE mailing list, such that all participan= ts=20 should have a reasonable overview of the scope that any related work may en= tail.=20 Participants may also benefit from reading through the minutes of the=20 corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcore= .html#The%20SIP%20OPTIONS%20Method

Rather=20 than continue discussion of the specific technical topics related to OPTION= S,=20 the chairs would encourage the working group to engage in a discussion arou= nd=20 whether we should, as a group, work on addressing some of the issues that h= ave=20 been identified.

In particular, we would direct the group to conside= r the=20 nature of such work:

  • Are we=20 proposing to introduce new features, or fix existing bugs?=20
  • If we=20 are adding new features: is OPTIONS the best way to introduce these featu= res,=20 or would other mechanisms (presence, callee-caps) produce superior=20 results?=20
  • If we=20 are fixing bugs: are the bugs theoretical, or can we cite actual=20 interoperability issues in the field?
  • If=20 there are identified interoperability issues: is the level of effort invo= lved=20 in fixing them commensurate with the impact of the problems?=20

= Finally, keep in mind that work does not happen u= nless=20 participants are willing to invest time. If you speak out in favor of pursu= ing=20 this work, please indicate the level of time commitment that you will perso= nally=20 invest in bringing such work to a successful conclusion (e.g., will author= =20 drafts; will perform dedicated reviews;=20 etc).

Thanks.

/a

--_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A915ESESSCMS0354e_-- From christer.holmberg@ericsson.com Sat Apr 3 04:06:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3003A6810 for ; Sat, 3 Apr 2010 04:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHolRZCVNTcQ for ; Sat, 3 Apr 2010 04:06:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B66A03A672F for ; Sat, 3 Apr 2010 04:06:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-59-4bb7213b2399 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9C.FA.23532.B3127BB4; Sat, 3 Apr 2010 13:06:36 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sat, 3 Apr 2010 13:06:35 +0200 From: Christer Holmberg To: 'Peter Musgrave' , SIPCORE Date: Sat, 3 Apr 2010 13:06:34 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrSTB9VwMtPzKIuTk2MpG9ghMC3wgA0R2Kg Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:06:38 -0000 Hi,=20 >I agree with the assertion (Hadrials?) that there are two things here: >bugs in OPTIONS and a need to query multiple UAs. > >I have not seen wide use of OPTIONS and have not encountered these bugs, I= n general I favour fixing them but I am not sure if this is more important = that other work which could be done. > >As for assessing multiple UA capabilities - I agree this is useful. Is OPT= IONS the only way forward here? Could I not use e.g. gruu-reg-event and the= n send specifically targeted OPTIONS to each gruu? Is=20 >requiring gruu support in UAs viewed as 'setting the bar too high?' This f= ails to pick up forking due to dial plan entries - is that a requirement? In the OPTIONS 3xx case, after the UAC has received the 3xx it would send i= ndividual OPTIONS request. The 3xx may contain gruus, or normal contacts. So, it doesn't require support of gruu. It doesn't really require any suppo= rt from the UAS. Regards, Christer From christer.holmberg@ericsson.com Sat Apr 3 04:10:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6068C3A69D4 for ; Sat, 3 Apr 2010 04:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yk8JLuUj7g4 for ; Sat, 3 Apr 2010 04:10:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C38B53A69E9 for ; Sat, 3 Apr 2010 04:10:12 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-a9-4bb722127eb4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6D.F8.23740.21227BB4; Sat, 3 Apr 2010 13:10:11 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 3 Apr 2010 13:10:10 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , Hadriel Kaplan Date: Sat, 3 Apr 2010 13:10:09 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrR8pRP0fnu2ZauSYuAAFKiEOPwIwBKz40g Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> In-Reply-To: <4BB52B53.7000102@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: SIPCORE Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:10:14 -0000 Hi,=20 >>What if the first proxy has two routes for the AoR, and one of those=20 >>points to another proxy that also has two (different) routes for the AoR? > >That should all be handled by recursion on 3xx response processing. >The first proxy would return 3xx with its choices. One of those would lead= to the 2nd proxy, that then would return its own 3xx. That might happen, yes. >>Do you only want 3xx for Registered contact URI's? What if the proxy=20 >>doesn't know whether they're Registered contact URI's vs. static routes? > >IMO this is one of the big problems with the IMS approach to services.=20 >They aren't registered, and aren't anything that the S-CSCF could (or >would) return as 3xx alternatives. So the caller will be limited in what o= ptions are visible to it. I am not really sure I understand what you mean... However, there are of course limitations on how much information the caller= will get, based on what information the UAS have registered, and what info= rmation can be returned in the 3xx in the first place. Regards, Christer From christer.holmberg@ericsson.com Sat Apr 3 04:15:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B853A6993 for ; Sat, 3 Apr 2010 04:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcpOa6Gn3Bp6 for ; Sat, 3 Apr 2010 04:15:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F173F3A6358 for ; Sat, 3 Apr 2010 04:15:19 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-94-4bb72346945a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id E8.19.23740.64327BB4; Sat, 3 Apr 2010 13:15:18 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 3 Apr 2010 13:15:17 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , Salvatore Loreto , "sipcore@ietf.org" Date: Sat, 3 Apr 2010 13:15:16 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbiscsLyjPDmeQNepI4WI9i7HfwAfCR7wAE0E8JA= Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79E93040@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E93040@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:15:21 -0000 Hi,=20 >When you say "is essential to providing meaningful service" in what way do= you mean that? > >Do you mean literally that you need any UAC anywhere to be able to discove= r the capabilities of any arbitrary UAS it might want to communicate with i= n the World using OPTIONS? Anyone associated with an AOR, yes, which of course may located anywhere in= the world :) >Or do you mean within a provider's domain, having an App Server figure out= what each registered UA endpoint supports and putting that in some databas= e is very useful? (which I could see 3GPP doing) I guess that could be a potential use-case also. >Because if it's the latter, then creating an options-tag for rfc3841 and p= utting it in Proxy-Require isn't that bad an idea - proxy-require only has = deployment issues when you want to use it across=20 >proxies outside of your administrative control. Far from every proxy needs to understand RFC3841, and that is the problem w= ith Proxy-Require - it requires everyone to understand something. (It would be really great if it would be possible to require proxies to sup= port stuff only in certain conditions, e.g. if they act as a registrar and = intend to do forking). Regards, Christer =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Salvatore Loreto Sent: Thursday, April 01, 2010 3:36 AM To: sipcore@ietf.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? =20 Hi, A good mechanism to discovery UA capabilities is essential to provide meani= ngful service: So I am in favor of pursuing the work,=20 in particular the possibility to use a single OPTIONS request to retrieve t= he capabilities from ALL UAS(s) behind a forking proxy.=20 I agree with Christer, that as discussed in the ml and during the f2f meeti= ng, the 3xx solution already provide this feature even if with the limitations Paul has highlighted (e.g. honoring R-D is opt= ional by the proxy). I do think, it would be opportune document it in a BCP to document/clarify = the ambiguous stuff, and I can help to co-edit it if we decide to write one= . Explore the possibility to use other mechanisms (e.g. presence, something s= imilar to XEP-0115) and define it would be also interesting, but IMO it would require a major effort and more cycles and I am not so sur= e there are enough people willing to accomplish such effort. cheers Sal On 3/30/10 9:05 PM, Adam Roach wrote:=20 [as chair] One of the topics of discussion at the recent face-to-face meeting in Anahe= im was the SIP OPTIONS method. We have had significant discussion of some s= pecific technical topics on the SIPCORE mailing list, such that all partici= pants should have a reasonable overview of the scope that any related work = may entail. Participants may also benefit from reading through the minutes = of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTI= ONS%20Method Rather than continue discussion of the specific technical topics related to= OPTIONS, the chairs would encourage the working group to engage in a discu= ssion around whether we should, as a group, work on addressing some of the = issues that have been identified. In particular, we would direct the group to consider the nature of such wor= k: * Are we proposing to introduce new features, or fix existing bugs?=20 * If we are adding new features: is OPTIONS the best way to introduce these= features, or would other mechanisms (presence, callee-caps) produce superi= or results?=20 * If we are fixing bugs: are the bugs theoretical, or can we cite actual in= teroperability issues in the field?=20 * If there are identified interoperability issues: is the level of effort i= nvolved in fixing them commensurate with the impact of the problems?=20 Finally, keep in mind that work does not happen unless participants are wil= ling to invest time. If you speak out in favor of pursuing this work, pleas= e indicate the level of time commitment that you will personally invest in = bringing such work to a successful conclusion (e.g., will author drafts; wi= ll perform dedicated reviews; etc). Thanks. /a From pkyzivat@cisco.com Sat Apr 3 06:32:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DB13A67F4 for ; Sat, 3 Apr 2010 06:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQnUFFAJVZ3S for ; Sat, 3 Apr 2010 06:32:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 19E4F3A6452 for ; Sat, 3 Apr 2010 06:32:41 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGvgtktAZnwN/2dsb2JhbACbTHGdG5gJgluCLAQ X-IronPort-AV: E=Sophos;i="4.51,356,1267401600"; d="scan'208";a="98628889" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2010 13:32:40 +0000 Received: from [10.86.244.106] ([10.86.244.106]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o33DWdxm017254; Sat, 3 Apr 2010 13:32:39 GMT Message-ID: <4BB74377.10107@cisco.com> Date: Sat, 03 Apr 2010 09:32:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 13:32:42 -0000 Christer Holmberg wrote: >> IMO this is one of the big problems with the IMS approach to services. >> They aren't registered, and aren't anything that the S-CSCF could (or >> would) return as 3xx alternatives. So the caller will be limited in what options are visible to it. > > I am not really sure I understand what you mean... For instance, suppose I want to talk to your voicemail, without ringing your regular phone(s). I might send an OPTIONS in hope of getting a list of Contacts, among which the VM contact might be found. AFAIK, IMS isn't set up in a way to have an identifiable contact for the VM server that it could return in the 3xx. (But I'll be pleasantly surprised to learn I'm wrong.) Thanks, Paul From HKaplan@acmepacket.com Sat Apr 3 09:20:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DBE3A689C for ; Sat, 3 Apr 2010 09:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpEMCJw5aAKF for ; Sat, 3 Apr 2010 09:20:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 85AD33A63EC for ; Sat, 3 Apr 2010 09:19:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 3 Apr 2010 12:19:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 3 Apr 2010 12:19:54 -0400 From: Hadriel Kaplan To: Christer Holmberg , 'Adam Roach' , SIPCORE Date: Sat, 3 Apr 2010 12:19:36 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAB1i2VEAimGSFKUG42bG2CATAAPowaAAFszqxAATRFkUAAKf7Lw Message-ID: <430FC6BDED356B4C8498F634416644A91A79E93274@mail> References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 16:20:12 -0000 Hi Christer,=20 comments inline... (also, let's keep this plain text format :) > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Saturday, April 03, 2010 7:01 AM > To: Hadriel Kaplan; 'Adam Roach'; SIPCORE > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? > > I agree. I tried to make that separation in my presentation, by talking > about "unclear specifications"/bugs and "forking". I never intended to sa= y > that the forking case was a bug, simply that the way it is normally > usedvery much limits it's usability in forking cases. =A0 No debate there - as far as I can tell rfc3841 req-disp is used in very lim= ited and constrained cases, under specific configuration control. (when it'= s used at all) > I have mostly been thinking about the registrar returning the 3xx, but > there could be cases where another forking proxy also sends 3xx, and mayb= e > the UAC can already make some decissions based on that. Now, in theory > this could of course lead to a series of 3xx response, but in real life I > don't think that is going to happen. When forking occurs in the first > place, I think the majority of cases will contain one point of forking. I= n > some cases there may be two points of forking, but more than that I think > is going to be extremely rare... But, if someone thinks I'm wrong I would > really much like to hear about it :) Easy answer: go beyond the local domain. If the SIP request goes inter-dom= ain, it's not uncommon for proxies along the path to have multiple routes. = For example to multiple transits, or to multiple ingress/egress point next= -hops, or to PSTN-fallback gateways, etc. These are all "forks" (serial fo= rks). Even within the domain, it's not always obvious that the reg-proxy knows wh= ich database entries are registered contacts vs. static routes - for exampl= e fallback routes, or voicemail routes, or invoked b2bua app-servers - and = even if it knows, the request-disposition does not specify what types it ap= plies to. So ISTM that this thing will need to be configured: enabled on specific pro= xies for specific route types, and possibly for specific methods. -hadriel From HKaplan@acmepacket.com Sat Apr 3 09:41:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A378F3A683F for ; Sat, 3 Apr 2010 09:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsXjn4ZktBfu for ; Sat, 3 Apr 2010 09:41:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D73663A63EC for ; Sat, 3 Apr 2010 09:41:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 3 Apr 2010 12:41:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 3 Apr 2010 12:41:01 -0400 From: Hadriel Kaplan To: Christer Holmberg , Salvatore Loreto , "sipcore@ietf.org" Date: Sat, 3 Apr 2010 12:40:18 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbiscsLyjPDmeQNepI4WI9i7HfwAfCR7wAE0E8JAACsX5UA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79E93277@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79E93040@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 16:41:03 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Saturday, April 03, 2010 7:15 AM > To: Hadriel Kaplan; Salvatore Loreto; sipcore@ietf.org >=20 > Far from every proxy needs to understand RFC3841, and that is the problem > with Proxy-Require - it requires everyone to understand something. No debate there - but I don't know how you get "guaranteed" usage otherwise= . For example, if your OPTIONS request crosses a proxy which recurses on 3xx,= and that proxy forwards it to a proxy which understands req-disp and sends= back the 3xx. The recursing middle-proxy will handle it, not send it back= to you. And across domains 3xx-recursing proxies are common. -hadriel From brett@broadsoft.com Sat Apr 3 10:09:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8E73A6910 for ; Sat, 3 Apr 2010 10:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V+GB7E3OaNq for ; Sat, 3 Apr 2010 10:09:51 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 8E9DE3A68C5 for ; Sat, 3 Apr 2010 10:09:47 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Sat, 3 Apr 2010 10:09:46 -0700 From: Brett Tate To: "vbharga@cisco.com" , "paulej@packetizer.com" , "gsalguei@cisco.com" , "sipcore@ietf.org" Date: Sat, 3 Apr 2010 10:08:59 -0700 Thread-Topic: draft-jones-sip-options-ping-00: comments Thread-Index: AcrTUFoHoG3kmE8PR8OP/TTMdPkytQ== Message-ID: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> 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: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 17:09:52 -0000 Glad to see someone attempting to capture the currently common use for OPTI= ONS. Here are a few comments. Thanks, Brett --------- To help avoid receiving ignored data within 200 response, I recommend use o= f an option-tag (such a options-ping) or something else included within OPT= IONS to clearly indicate that the sender does not actually want all the dat= a which can be provided within 200 response. Section 5.1 indicates "To avoid unduly taxing a receiving SIP entity, trans= mitters of OPTIONS messages MUST honor the Retry-After header field if rece= ived." The MUST requirement is likely too strong because of implications w= hen included within a 503. The MUST requirement is likely also too strong = because of vulnerability to quit sending requests to that device for an ext= remely long time because attacker or bug caused the 503 to be sent containi= ng Retry-After with an extremely large value. Concerning receiving 503 with Retry-After, to what does it apply: 1) OPTIONS request target ip-address, 2) OPTIONS response source ip-address, 3) both 1 and 2, 4) something else. From HKaplan@acmepacket.com Sat Apr 3 12:12:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1500B28C0F9 for ; Sat, 3 Apr 2010 12:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.065 X-Spam-Level: * X-Spam-Status: No, score=1.065 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_60=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLJWih90ibro for ; Sat, 3 Apr 2010 12:12:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2753A28C0F6 for ; Sat, 3 Apr 2010 12:12:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 3 Apr 2010 15:12:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 3 Apr 2010 15:12:47 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , "sipcore@ietf.org" Date: Sat, 3 Apr 2010 15:12:40 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> In-Reply-To: <01a201cad2a5$ae1096c0$0a31c440$@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: "'Vivek Bhargava \(vbharga\)'" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 19:12:54 -0000 Hey Paul, Right, so I suspect most everyone would agree that this is the most common = usage of OPTIONS, or at least one of 'em. And I agree it has interop probl= ems left and right, and requires manual provisioning and testing of specifi= c behavior on a per hop basis.=20 The problem is I suspect it would be hard to get this to be a WG doc. :( First, because it's an ambiguous usage of the method. You could define an = option-tag to make it clear, however. (along with a header to say "I'm usin= g this option-tag's mechanism for this request") =20 But more importantly because it conflicts with two other pieces of work bei= ng done in the IETF: 1) The keep-alive portion, which is done by RFC 5626 and also being worked = on in draft-ietf-sipcore-keep. 2) The overload portion, for which people are trying to form a new WG out o= f DISPATCH, based on RFC 5390 and the work of a design team implementing an= d testing various individual drafts. If I recall right, that work actually= started because the 503 Retry-After model was found to be poor. You could, of course, just go for an individual informational publication. = But without the option-tag (which requires a standards-track doc right now= ), it wouldn't solve the problem of manual configuration, because different= devices currently do different things than what this doc recommends. Other, specific comments on the draft: 0) You might want to consider specifying what the To/From-URIs should be se= nt as, and that a receiver should be lenient. We've seen interop problems = with those URIs for OPTIONS pings. 1) Section 6 says: "When a receiving SIP entity is unable to process SIP me= ssages, it SHOULD respond with a 503 response code." Clearly you can't mea= n that literally, since OPTIONS is a SIP message and responding to it would= require processing it. :) But you presumably also don't mean when the ent= ity is too busy, because you recommend using 486 for that case. So what is= this intended to mean? Unable to process new dialogs? 2) Section 6 says: "A SIP entity MUST respond to an OPTIONS method with a 2= 00 response code when it is willing and able to process SIP messages." Aga= in, this can't be meant literally, because two paragraphs later a 486 is in= dicated when it is experiencing heavy load but still willing to accept new = dialogs. Maybe just a "...unless one of the following cases apply" needs t= o be added at the end of the sentence. BTW, do you really mean "SIP messag= es", or do you mean out-of-dialog requests other than OPTIONS, or only dial= og-forming requests? 3) Section 7 says: "If a requesting entity receives a 486 or 503 response code, it MAY send a subsequent OPTIONS messages in order to detect a change in operational status, but it MUST honor the Retry- After header field." Do you mean it must honor the Retry-After such that it does not send the OP= TIONS ping based on it? Or do you only mean it has to honor the Retry-Afte= r for other request types? Also, it's a nit, but the sentence should be ".= ..honor the Retry-After header field value received in the previous respons= e." 4) Section 5.1 says: "The OPTIONS message MUST be transmitted directly to t= he peer's IP address and not to an intermediary SIP entity." What do you m= ean by "intermediary SIP entity"? Either it is the next-hop, or it's not. = If your next-hop is X, send it to X. If to get to your "peer" you have to= use a proxy, then that proxy *is* your next-hop, and *is* your "peer". By= passing it won't help you in the general case. (in some specific cases, sur= e, but not generally; and in some cases it makes things worse, so it can't = be a MUST) -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: Friday, April 02, 2010 4:47 PM > To: sipcore@ietf.org > Cc: 'Vivek Bhargava (vbharga)'; 'Gonzalo Salgueiro' > Subject: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt >=20 > Folks, >=20 > I wanted to bring your attention to an Internet Draft we submitted today > related to one use of the SIP OPTIONS message. This draft describes the > use > of OPTIONS as an application-level "ping" mechanism. >=20 > It is important to point out two things: > 1) We are not defining any new extensions to SIP, but merely attempt > to define the use of OPTIONS as a "ping" mechanism in a way that > will be interoperable. We've found a lot of equipment that does > this and it is done inconsistently from one vendor or product > to the next. We believe we need to ensure that devices > implement an OPTIONS "ping" mechanism with some level of > consistency and suggest either a standards track document > or a BCP-type document. > 2) These procedures are not intended to be used in lieu of a proper > load balancing or capacity reporting mechanism: the scope is > deliberately narrowly focused to allowing a SIP entity to > determine the status of another entity, usually a next-hop > neighbor. >=20 > We would welcome any comments on the draft. >=20 > Paul From paulej@packetizer.com Sat Apr 3 19:42:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D443A67BD for ; Sat, 3 Apr 2010 19:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHuRiJEh7s1u for ; Sat, 3 Apr 2010 19:42:08 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 13BE73A695D for ; Sat, 3 Apr 2010 19:39:41 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o342dUUV022373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Apr 2010 22:39:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270348776; bh=qzas0e/5vpjE3MsZbnzzrnbnACa0O6gb95AaCjMamno=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bzd82hNhBjGXDn+sRvKGWVZVxIMdSUzqRe7+etY8kkJ1crThuJSOIxtUMv+XyLCJ4 oc6IkPEbbHyAOAlcBS9pvhR2w8CmYGvQwV02itQKgSl3cxPHi9F4KgK26ILM6Iv2zY waVKc6Fd3fiN21nFenBIWCgShzdKmhi58E1uQ7uc= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o342dTL7010050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Apr 2010 22:39:29 -0400 From: "Paul E. Jones" To: "'Brett Tate'" , , , References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> Date: Sat, 3 Apr 2010 22:39:19 -0400 Message-ID: <002601cad3a0$06b20ac0$14162040$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrTUFoHoG3kmE8PR8OP/TTMdPkytQASKuTA Content-Language: en-us Subject: Re: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 02:42:09 -0000 Brett, > Glad to see someone attempting to capture the currently common use for > OPTIONS. Thanks... indeed, this looked like an area that needed addressing to us. > To help avoid receiving ignored data within 200 response, I recommend > use of an option-tag (such a options-ping) or something else included > within OPTIONS to clearly indicate that the sender does not actually > want all the data which can be provided within 200 response. I'm not opposed to this, per se, but we were trying to avoid introducing any new signaling features at all. If folks thought it might be useful, we can do that. One problem, though, is that all devices would immediately be non-compliant ;-) I thought about the implications of this a little before writing the draft. If a SIP message is sent between two SBCs, for example, quite likely the receiving device is going to reply with something that's pre-configured (perhaps even pre-composed) and the receiver is only going to look at the status code of the reply. So, I wondered whether it would even matter. > Section 5.1 indicates "To avoid unduly taxing a receiving SIP entity, > transmitters of OPTIONS messages MUST honor the Retry-After header > field if received." The MUST requirement is likely too strong because > of implications when included within a 503. The MUST requirement is > likely also too strong because of vulnerability to quit sending > requests to that device for an extremely long time because attacker or > bug caused the 503 to be sent containing Retry-After with an extremely > large value. Perhaps you're right, but do you have suggestions for alternative wording? Are you suggesting to replace "MUST" with "SHOULD"? > Concerning receiving 503 with Retry-After, to what does it apply: > 1) OPTIONS request target ip-address, > 2) OPTIONS response source ip-address, > 3) both 1 and 2, > 4) something else. I'm a little confused by your question. Are you asking whether it applies to the target address to which the sender of the OPTIONS sent the request or to the address from which the recipient returned a 503, or the address of an intermediary? I would say it refers to the address to which the request was sent. If you're concerned that a reply might come from an intermediary or a rogue endpoint, I suppose you have reason for concern. That said, one should not have an intermediary in the path, as it somewhat defeats the purpose. If it's a security issue, I would say one needs to consider the security of messages just as they would any other message. Paul From paulej@packetizer.com Sat Apr 3 20:18:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC393A67BD for ; Sat, 3 Apr 2010 20:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dodKFSyV9--B for ; Sat, 3 Apr 2010 20:18:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D730B3A67DB for ; Sat, 3 Apr 2010 20:18:23 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o343IDKU024150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Apr 2010 23:18:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270351099; bh=u8ysFvrkw+ljk5JbVLDGfypb8rESJ3o+bjV7IkwY/go=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=W/vDhhWtMe0xtEhN4Gt1AbHIYHnVHoXweHEa+0y86BhhZMXl6XruKj3rpe+18B394 tbvPpWuY6mkrhH9f+duBdh+ECsR75A4k/FVcibaPh4I0H7BUof5W2MxJ0zlIlyCtKY /8/oylxItZgYUA1u+lNVmg/mYYGqO3qRGM60VSFY= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o343IBtT010103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Apr 2010 23:18:11 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> Date: Sat, 3 Apr 2010 23:18:01 -0400 Message-ID: <003201cad3a5$6f263540$4d729fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcA== Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 03:18:49 -0000 Hadriel, > The problem is I suspect it would be hard to get this to be a WG doc. > :( That might be tough, but I'd be content with something less than that, such an informational document that folks can agree to. I think it's important to get something that we can refer to and say "that's how it's supposed to work" since I see many variants. > First, because it's an ambiguous usage of the method. You could define > an option-tag to make it clear, however. (along with a header to say > "I'm using this option-tag's mechanism for this request") Is it ambiguous? The fact so many people elected to use it suggests that it makes sense to use. What is ambiguous is the exact usage. > But more importantly because it conflicts with two other pieces of work > being done in the IETF: > 1) The keep-alive portion, which is done by RFC 5626 and also being > worked on in draft-ietf-sipcore-keep. That document covers a different problem that's not related to an application "ping" between two devices. One could view it as such for active sessions, I suppose, but it really has a different focus. > 2) The overload portion, for which people are trying to form a new WG > out of DISPATCH, based on RFC 5390 and the work of a design team > implementing and testing various individual drafts. If I recall right, > that work actually started because the 503 Retry-After model was found > to be poor. Likewise, this one is also different. We're not trying to replicate the overload work. Everything specified in this document, I think, is what the SIP specs say today, except that nothing states that use of OPTIONS can be used as an application-level "ping". The 503 response indicating that the device is overloaded, for example, came directly from RFCF 3261 Section 21.5.4. If there are issues with use of 503 in a "ping" between two adjacent devices, then we ought to consider that, but in no way do I want to replicate the work over "overload", which has a far broader scope. > You could, of course, just go for an individual informational > publication. But without the option-tag (which requires a standards- > track doc right now), it wouldn't solve the problem of manual > configuration, because different devices currently do different things > than what this doc recommends. I'm happy to go either way, so long as folks agree. If we can't agree to a set of procedures, then there's not much value in publishing even an informational document. > Other, specific comments on the draft: > 0) You might want to consider specifying what the To/From-URIs should > be sent as, and that a receiver should be lenient. We've seen interop > problems with those URIs for OPTIONS pings. I wanted to be rather strict in saying that only sip:192.168.4.56 was acceptable, for example, but others I consulted with thought that was too restrictive. So, the language is soft here. What is the preference of the group on this? > 1) Section 6 says: "When a receiving SIP entity is unable to process > SIP messages, it SHOULD respond with a 503 response code." Clearly you > can't mean that literally, since OPTIONS is a SIP message and > responding to it would require processing it. :) But you presumably > also don't mean when the entity is too busy, because you recommend > using 486 for that case. So what is this intended to mean? Unable to > process new dialogs? We chose 503 because that is what section 21.5.4 of RFC 3261 says to return. So, yeah, we meant that ;-) Perhaps "unable" is the word that needs changing, but that was also the word used in 3261. What would be better? > 2) Section 6 says: "A SIP entity MUST respond to an OPTIONS method with > a 200 response code when it is willing and able to process SIP > messages." Again, this can't be meant literally, because two > paragraphs later a 486 is indicated when it is experiencing heavy load > but still willing to accept new dialogs. Maybe just a "...unless one > of the following cases apply" needs to be added at the end of the > sentence. BTW, do you really mean "SIP messages", or do you mean out- > of-dialog requests other than OPTIONS, or only dialog-forming requests? Good point. I'll adjust the sentence to add a condition as you suggest. We did mean "SIP messages" since the purpose is to determine, not whether the peer device is able to process the OPTIONS, but whether it is willing and able to process any SIP message. How to put that in words? Anyway, if the peer device is out of service, we want OPTIONS to tell us that before we waste time trying to send an INVITE. > 3) Section 7 says: "If a requesting entity receives a 486 or 503 > response code, it MAY send a subsequent OPTIONS messages in order to > detect a change in operational status, but it MUST honor the Retry- > After header field." > Do you mean it must honor the Retry-After such that it does not send > the OPTIONS ping based on it? Or do you only mean it has to honor the > Retry-After for other request types? Also, it's a nit, but the > sentence should be "...honor the Retry-After header field value > received in the previous response." I added the nit clause to the draft :-) As for the meaning, I'm confused with your question. The intent is to obey the Retry-After header. If the reply to the OPTIONS has a Retry-After header, then don't send another OPTIONS until that time expires. > 4) Section 5.1 says: "The OPTIONS message MUST be transmitted directly > to the peer's IP address and not to an intermediary SIP entity." What > do you mean by "intermediary SIP entity"? Either it is the next-hop, > or it's not. If your next-hop is X, send it to X. If to get to your > "peer" you have to use a proxy, then that proxy *is* your next-hop, and > *is* your "peer". Bypassing it won't help you in the general case. (in > some specific cases, sure, but not generally; and in some cases it > makes things worse, so it can't be a MUST) This sentence is only to reinforce what you're saying (I think). One should not use these procedures to do a "ping" between A and C by addressing the message to C, but then transmitting it to a proxy B to forward to C. Paul From christer.holmberg@ericsson.com Sat Apr 3 21:31:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14B53A67A5 for ; Sat, 3 Apr 2010 21:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iQUvLqirlk0 for ; Sat, 3 Apr 2010 21:31:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C14C33A6783 for ; Sat, 3 Apr 2010 21:31:42 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-3d-4bb8162b21ab Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 95.8F.23740.B2618BB4; Sun, 4 Apr 2010 06:31:39 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 4 Apr 2010 06:31:39 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Sun, 4 Apr 2010 06:31:38 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , Salvatore Loreto , "sipcore@ietf.org" Date: Sun, 4 Apr 2010 06:31:37 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbiscsLyjPDmeQNepI4WI9i7HfwAfCR7wAE0E8JAACsX5UAAZbtbA Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79E93040@mail> <430FC6BDED356B4C8498F634416644A91A79E93277@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E93277@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 04:31:43 -0000 Hi,=20 >>Far from every proxy needs to understand RFC3841, and that is the=20 >>problem with Proxy-Require - it requires everyone to understand something= . > >No debate there - but I don't know how you get "guaranteed" usage otherwis= e. >For example, if your OPTIONS request crosses a proxy which recurses on 3xx= , and that proxy forwards it to a proxy which understands req-disp and send= s back the 3xx. The recursing middle-proxy will=20 >handle it, not send it back to you. And across domains 3xx-recursing prox= ies are common. I agree, that might happen. But, that is a general 3xx response "feature", and again one of thoese thin= gs where there is very little we can do on a protocol level - we just have = to hope people will configure their deployments in a right way. And, having= a document (e.g. a BCP, in this case) would help them in doing that, in my= opinion. Regards, Christer From christer.holmberg@ericsson.com Sat Apr 3 21:43:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281813A68ED for ; Sat, 3 Apr 2010 21:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xazA4R8yzUjC for ; Sat, 3 Apr 2010 21:43:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5D5B73A68F0 for ; Sat, 3 Apr 2010 21:43:25 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-7a-4bb818eb066c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 23.CF.23740.BE818BB4; Sun, 4 Apr 2010 06:43:23 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 4 Apr 2010 06:43:23 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Sun, 4 Apr 2010 06:43:22 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , 'Adam Roach' , SIPCORE Date: Sun, 4 Apr 2010 06:43:21 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAB1i2VEAimGSFKUG42bG2CATAAPowaAAFszqxAATRFkUAAKf7LwABqIzDA= Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <430FC6BDED356B4C8498F634416644A91A79E93274@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E93274@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 04:43:32 -0000 Hi,=20 >>I agree. I tried to make that separation in my presentation, by=20 >>talking about "unclear specifications"/bugs and "forking". I never=20 >>intended to say that the forking case was a bug, simply that the way=20 >>it is normally usedvery much limits it's usability in forking cases. >=A0 >No debate there - as far as I can tell rfc3841 req-disp is used in very li= mited and constrained cases, under specific configuration control. (when it= 's used at all) I think 3841 is the hidden jewel of SIP. And, eventhough I may not like eve= ry detail init, in my opinion it can be a very useful tool.=20 >>I have mostly been thinking about the registrar returning the 3xx, but=20 >>there could be cases where another forking proxy also sends 3xx, and=20 >>maybe the UAC can already make some decissions based on that. Now, in=20 >>theory this could of course lead to a series of 3xx response, but in=20 >>real life I don't think that is going to happen. When forking occurs=20 >>in the first place, I think the majority of cases will contain one=20 >>point of forking. In some cases there may be two points of forking,=20 >>but more than that I think is going to be extremely rare... But, if=20 >>someone thinks I'm wrong I would really much like to hear about it :) > >Easy answer: go beyond the local domain. If the SIP request goes inter-do= main, it's not uncommon for proxies along the path to have multiple routes.= For example to multiple transits, or to multiple=20 >ingress/egress point next-hops, or to PSTN-fallback gateways, etc. These = are all "forks" (serial forks). Agree. But, in this case I don't really see a big reason in those proxies s= ending a 3xx response, since the request is forwarded towards the same dest= ination, simply using different routes. I think this is another case where we seem to think that the world spins ar= ound the protocol, and operators won't be able to configure their equipment= ... :) >Even within the domain, it's not always obvious that the reg-proxy knows w= hich database entries are registered contacts vs. static routes - for examp= le fallback routes, or voicemail routes, or invoked=20 >b2bua app-servers - and even if it knows, the request-disposition does not= specify what types it applies to. You can define new feature tags/feature tag values, if needed, e.g. to indi= cate "voicemail". Maybe that would be very useful, if I e.g. need to leave = you a message, but I don't have time to talk with you in person at this mom= ent.=20 And, local policies can be used on what contacts to return in the 3xx. >So ISTM that this thing will need to be configured: enabled on specific pr= oxies for specific route types, and possibly for specific methods. For example, yes. Regards, Christer From HKaplan@acmepacket.com Sat Apr 3 21:49:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F14A3A686A for ; Sat, 3 Apr 2010 21:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhqBPplyry4x for ; Sat, 3 Apr 2010 21:49:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 15B583A6767 for ; Sat, 3 Apr 2010 21:49:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 4 Apr 2010 00:49:39 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 4 Apr 2010 00:49:39 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Brett Tate' , "vbharga@cisco.com" , "gsalguei@cisco.com" , "sipcore@ietf.org" Date: Sun, 4 Apr 2010 00:49:35 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-00: comments Thread-Index: AcrTUFoHoG3kmE8PR8OP/TTMdPkytQASKuTAAAUuvZA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79E93292@mail> References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> In-Reply-To: <002601cad3a0$06b20ac0$14162040$@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: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 04:49:42 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: Saturday, April 03, 2010 10:39 PM >=20 > [snipped text, but topic is option-tags] > > I'm not opposed to this, per se, but we were trying to avoid introducing > any > new signaling features at all. If folks thought it might be useful, we > can > do that. One problem, though, is that all devices would immediately be > non-compliant ;-) I was worried about this too ('cause I also suggested option-tags and was w= orried about code-changes), but ISTM this is basically already the case: un= less most folks do exactly what this doc says today, they're non-compliant = and would require changing either code or config. The thing is, afaict, many folks DON'T do what the doc says. Not exactly, = which is the same thing (right?). For example, of three rather popular ven= dors I just looked at OPTION-ping traces of, none used the 486 for anything= . I don't know what they'd do if they got one. All 3 of the vendors use 5= 03 to signal "out-of-service" back, but at least 2 of them still allow (and= want/expect to receive) in-dialog messages - I can't tell with the 3rd. A= nd one of them still _sent_ all messages even if it got a 503.=20 -hadriel From christer.holmberg@ericsson.com Sat Apr 3 21:51:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D5B3A68AB for ; Sat, 3 Apr 2010 21:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1jDH5WW5KI5 for ; Sat, 3 Apr 2010 21:51:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4DCDF3A6767 for ; Sat, 3 Apr 2010 21:51:45 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-54-4bb81adf7af8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 25.FF.23740.FDA18BB4; Sun, 4 Apr 2010 06:51:43 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 4 Apr 2010 06:51:42 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Sun, 4 Apr 2010 06:51:42 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Date: Sun, 4 Apr 2010 06:51:41 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrTMiOICfNZKYi7TFe59h68kKL+/AAf0CmQ Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> In-Reply-To: <4BB74377.10107@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: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 04:51:46 -0000 Hi,=20 >>>IMO this is one of the big problems with the IMS approach to services.=20 >>>They aren't registered, and aren't anything that the S-CSCF could (or >>>would) return as 3xx alternatives. So the caller will be limited in what= options are visible to it. >>=20 >>I am not really sure I understand what you mean... > >For instance, suppose I want to talk to your voicemail, without ringing yo= ur regular phone(s). I might send an OPTIONS in hope of getting a list of C= ontacts, among which the VM contact might be found. As I also indicated in my reply to Hadriel's e-mail, for this case I think = it would be very useful to have a VM feature tag, or something else in the = returned contact that indicates voicemail. >AFAIK, IMS isn't set up in a way to have an identifiable contact for the V= M server that it could return in the 3xx. (But I'll be pleasantly surprised= to learn I'm wrong.) IMS uses 3841. Regards, Christer From christer.holmberg@ericsson.com Sat Apr 3 21:59:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A12A3A68AF for ; Sat, 3 Apr 2010 21:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4dmGEBmmcyv for ; Sat, 3 Apr 2010 21:59:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A31933A6767 for ; Sat, 3 Apr 2010 21:59:36 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-d9-4bb81cb69088 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 29.10.23740.6BC18BB4; Sun, 4 Apr 2010 06:59:34 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 4 Apr 2010 06:59:34 +0200 From: Christer Holmberg To: "'Paul E. Jones'" , 'Hadriel Kaplan' , "sipcore@ietf.org" Date: Sun, 4 Apr 2010 06:59:33 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAEMQfA Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> In-Reply-To: <003201cad3a5$6f263540$4d729fc0$@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: "'Vivek Bhargava \(vbharga\)'" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 04:59:37 -0000 Hi,=20 =20 >>But more importantly because it conflicts with two other pieces of=20 >>work being done in the IETF: >>1) The keep-alive portion, which is done by RFC 5626 and also being=20 >>worked on in draft-ietf-sipcore-keep. > >That document covers a different problem that's not related to an applicat= ion "ping" between two devices. One could view it as such for active sessi= ons, I suppose, but it really has a different focus. That is not true. If you negotiate the keep-alive as part of the registration procedure, the = "pings" will be sent during the duration of the registration - no matter wh= ether you have active sessions or not. Now, that of course only applies to nodes that are involved in registration= , and the keep draft currently says that keep alives negotiated during sess= ion setup are only valid for that session. However, I think that at some po= int there was a comment that it should also be allowed to negotiate to long= er keep-alive durations during the session setup, for proxy-to-proxy "pings= " etc. I guess we'll get back to that discussion once we get the keep discu= ssion up again (next week, according to my plans). Regards, Christer From christer.holmberg@ericsson.com Sat Apr 3 22:08:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D473A690D for ; Sat, 3 Apr 2010 22:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsrlLt8YiGej for ; Sat, 3 Apr 2010 22:08:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 39D403A679F for ; Sat, 3 Apr 2010 22:08:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-3f-4bb81eb5dc4d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 07.32.23532.5BE18BB4; Sun, 4 Apr 2010 07:08:05 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 4 Apr 2010 07:08:05 +0200 From: Christer Holmberg To: "'DRAGE, Keith (Keith)'" , Adam Roach Date: Sun, 4 Apr 2010 07:08:04 +0200 Thread-Topic: [sipcore] Consensus Call: SIP Table 2 Thread-Index: AcrRGpOCPmIVaxcjTKqhCZjnjsto0wAR/9mwAA3SQVAAhofPAA== Message-ID: References: <4BB24828.80805@nostrum.com> <4BB3C0F1.8050900@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 05:08:10 -0000 Keith, I do agree with what you are saying. I am not proposing another way forward= - I simply had some issues/questions. But, we'll learn as we walk. Instead of having text describing the proforma rules, maybe we should addop= t Annex A from 3GPP TS 24.229 ;)=20 Regards, Christer -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: 1. huhtikuuta 2010 16:24 To: Christer Holmberg; Adam Roach Cc: SIPCORE Subject: RE: [sipcore] Consensus Call: SIP Table 2 There are essentially two potential parts of the work here: - Decide on the future documentation structure - work out how to deal with interactions with legacy specifications. SIPCORE is being asked only to decide on the first of these at the moment. As Adam says, most of the existing header field usage is fully defined. The= problem exists with certain header fields where it appears a somewhat arbi= trary analysis was given to the entries, and therefore the entries appear i= nconsistent.=20 An example of this is in the RFC 3329 header fields, where I personally wou= ld expect the semantics of these headers to be dealt with before one looks = at the method. That means they should appear in all methods, but you will s= ee from RFC 3329 that the headers are not valid in PRACK. With a set of documentation rules to follow, there are no legacy issues if = a new header field is defined. It follows one of the proforma rules, or cre= ates a new one. There is a legacy issue if a new method is created, but it is a long while = since we created a new method. Yes we hit the documentation issues with the= update to INFO and event packages, but for existing headers we can just ca= rry on with table 2 and 3 if we really need to. Or at that point we can cho= ose to create a new specification that updates those RFCs that do define he= ader fields. I would note however that that may well result in some technic= al change, due to perceived inconsistencies in the current definitions, as = in the example indicated above. At the moment I do not favour the existing table method of documentation. I do favour a set of proforma rules that specifiers can choose from. A couple of examples of these proforma rules would be something like: "The use of the header field is optional in all requests that are expected = to be exchanged end-to-end between UAs. Implementations of this extension M= UST support reception of this header field in such requests." "The use of the header field is optional in all requests that initiate a di= alog, or are used outside of a dialog being created. Implementations of thi= s extension MUST support reception of this header field in such requests." I suspect we could deal with most of the current header field usage with ab= out 10 or so such proforma rules, and I do not expect new header fields to = create a substantial set of new ones. These need to specify both use (mandatory/optional) and if it is not otherw= ise clear, support (mandatory/optional). The latter is missing from the exi= sting tables. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, April 01, 2010 7:45 AM > To: Adam Roach > Cc: SIPCORE > Subject: Re: [sipcore] Consensus Call: SIP Table 2 >=20 >=20 > Hi, >=20 > >Just to clarify: both alternatives will leave whatever is > currently unclear as it is.... > > =09 > > > >[as individual] > >=09 > >In truth, I don't think anything is particularly unclear -- > it's just > >not documented the same way. The documents that didn't > expand table 2 while adding new header fields all have prose that=20 > describes when the header field can appear. (Yes, I know this, because=20 > I looked at every one of them when I did the table 2 expansion that=20 > appears in the slides). > > > >So, you are saying that by reading the specs we would be > able to complete the table you had put toghether? > >=09 > > [as chair] > >=09 > >But, yes, the consensus call only deals with actions as they > apply to > >future documents -- such as RFC3265bis -- and does not > address actions that would affect RFCs or any other documents that=20 > have already cleared IETF review. > >=09 > >And, couldn't alternative 1 result in lots of "defined semantics" -=20 > >especially if we define a new method and may have to take a > large number of header fields into consideration? Maybe you'll even=20 > end up with something that looks like Table 2... > > > > > >[as individual again] > >=09 > >I don't think so. As Keith has pointed out, statements like "both=20 > >header fields defined in this document can appear only in > methods that > >create new dialogs" fill out entire swaths of the table all > at once. They also have the pleasantly future-proof quality that we=20 > don't need to say anything specifically about the header fields when=20 > someone creates a new method. A simple evaluation of the new method's=20 > properties against the header fields' normative text makes the answer=20 > brilliantly clear. >=20 > Sure. That is fine when you define new headers, and when you define=20 > new methods and need to cover those new headers. >=20 > But, when you define a new method, you still also need to consider all=20 > "old" existing header fields - for which we unfortunately do not have=20 > statements as those suggested by Keith. >=20 > Take 3265bis as an example, and assume you remove table 2.=20 > The text will of course describe the usage of header fields directly=20 > associated with SUB/NOT, eg. Allow-Events. But, how will you deal with=20 > all the other header fields that we have defined over the years? I am=20 > sure there are header fields that we do NOT need to cover, because=20 > they are associated with specific mechanisms (e.g. RSeq and RAck).=20 > But, there is a huge number of more "generic" header fields that=20 > somehow need to be covered. >=20 > Anyway, there is only one way to figure out: by doing the work :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 30. maaliskuuta 2010 21:51 > To: SIPCORE > Subject: [sipcore] Consensus Call: SIP Table 2 > =09 > =09 > [as chair] > =09 > Last week, at the face-to-face meeting in Anaheim, the SIPCORE=20 > participants in attendance had a discussion regarding the future of=20 > Tables 2 and 3 in RFC 3261. A summary of the conversation, along with=20 > links to the presentations and an audio recording of the conversation,=20 > can be found in the minutes: > =09 > =09 > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP > %20Table%202%20/%203 > =09 > During that conversation, the chairs polled those present for=20 > support between two options: > =09 >=20 > 1. Produce an artifact stating that=20 > documents defining new header fields and methods define semantics in=20 > prose, and will no longer extend Table 2; or > =09 > =09 > 2. Produce an RFC that defines new=20 > procedures for adding elements to Table 2 as new header fields and=20 > methods are defined >=20 > Among those present, there was strong support for option 1. If you=20 > wish to raise an objection to this direction, please do so on the=20 > SIPCORE mailing list before April 15th. > =09 > Thank you. > =09 > /a > =09 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From brett@broadsoft.com Sun Apr 4 07:23:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAD53A69D7 for ; Sun, 4 Apr 2010 07:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQwutvp0uhHP for ; Sun, 4 Apr 2010 07:23:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 6E7EF3A69C0 for ; Sun, 4 Apr 2010 07:23:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 4 Apr 2010 07:23:34 -0700 From: Brett Tate To: "Paul E. Jones" , "sipcore@ietf.org" Date: Sun, 4 Apr 2010 07:22:45 -0700 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAXhQZA Message-ID: <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> In-Reply-To: <003201cad3a5$6f263540$4d729fc0$@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: 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 14:23:40 -0000 > As for the meaning, I'm confused with your question. =20 > The intent is to obey the Retry-After header. If the=20 > reply to the OPTIONS has a Retry-After header, then=20 > don't send another OPTIONS until that time expires. Your response is appropriate for responses like 486 and 500 with Retry-Afte= r; however a 503 with Retry-After applies to more than OPTIONS. Per RFC 32= 61 section 21.5.4, it means you SHOULD NOT send any requests (INVITE, BYE, = ACK, CANCEL, REGISTER, ...) during that interval. From brett@broadsoft.com Sun Apr 4 08:37:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486C03A6A09 for ; Sun, 4 Apr 2010 08:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWkPr9-31DDr for ; Sun, 4 Apr 2010 08:37:16 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id B7E7B3A6846 for ; Sun, 4 Apr 2010 08:37:16 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 4 Apr 2010 08:37:15 -0700 From: Brett Tate To: "Paul E. Jones" , "sipcore@ietf.org" Date: Sun, 4 Apr 2010 08:36:29 -0700 Thread-Topic: [sipcore] draft-jones-sip-options-ping-00: comments Thread-Index: AcrTUFoHoG3kmE8PR8OP/TTMdPkytQASKuTAABp9kuA= Message-ID: <747A6506A991724FB09B129B79D5FEB61480BBFAD1@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> In-Reply-To: <002601cad3a0$06b20ac0$14162040$@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: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 15:37:18 -0000 > > To help avoid receiving ignored data within 200 response, I recommend > > use of an option-tag (such a options-ping) or something else included > > within OPTIONS to clearly indicate that the sender does not actually > > want all the data which can be provided within 200 response. >=20 > I'm not opposed to this, per se, but we were trying to avoid > introducing any new signaling features at all. If folks thought=20 > it might be useful, we can do that. =20 Yes; it would be useful for both the sender and receiver. > One problem, though, is that all devices would immediately be non-complia= nt ;-) That is okay with me. > > Section 5.1 indicates "To avoid unduly taxing a receiving SIP=20 > > entity, transmitters of OPTIONS messages MUST honor the=20 > > Retry-After header field if received." The MUST requirement=20 > > is likely too strong because of implications when included=20 > > within a 503. The MUST requirement is likely also too strong=20 > > because of vulnerability to quit sending requests to that device=20 > > for an extremely long time because attacker or bug caused the=20 > > 503 to be sent containing Retry-After with an extremely > > large value. >=20 > Perhaps you're right, but do you have suggestions for alternative > wording? Are you suggesting to replace "MUST" with "SHOULD"? The current wording requires honoring the 503 with Retry-After overload mec= hanism. RFC 3261 section 21.5.4 is at the SHOULD level instead of a MUST. = =20 If you only intended the Retry-After to apply to OPTIONS (instead of all re= quests), you can't use a 503 response (unless maybe you used an option-tag = or something to indicate a meaning other than RFC 3261 section 21.5.4). > > Concerning receiving 503 with Retry-After, to what does it apply: > > 1) OPTIONS request target ip-address, > > 2) OPTIONS response source ip-address, > > 3) both 1 and 2, > > 4) something else. >=20 > I'm a little confused by your question. Are you asking whether=20 > it applies to the target address to which the sender of the=20 > OPTIONS sent the request or to the address from which the=20 > recipient returned a 503, or the address of an intermediary? I'm not referring to intermediaries; however yes to other parts of the ques= tion (although also asking if applies to more or both). =20 I'm referring to devices with multiple ip-addresses such as 1 or more IPv4 = addresses and/or 1 or more IPv6 addresses. Thus the source ip-address of 5= 03 response may be different from where UAC sent the OPTIONS; and the sende= r of 503 may have additional ip-addresses used for SIP communication betwee= n these two servers. Since rfc3261 was somewhat vague, I'm attempting to e= nsure the draft is clear since it is requiring or recommending the use of 5= 03 with Retry-After. From christer.holmberg@ericsson.com Mon Apr 5 04:06:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFB43A692F for ; Mon, 5 Apr 2010 04:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zt+u1VwTjsz for ; Mon, 5 Apr 2010 04:06:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id ECF853A68DE for ; Mon, 5 Apr 2010 04:06:29 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-17-4bb9c4311db8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id E5.2F.23740.134C9BB4; Mon, 5 Apr 2010 13:06:25 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 5 Apr 2010 13:06:25 +0200 From: Christer Holmberg To: Adam Roach , SIPCORE Date: Mon, 5 Apr 2010 13:06:25 +0200 Thread-Topic: rfc3265bis: SIP events redux [was [sipcore] Minutes Posted] Thread-Index: AQHK1LAIYBlaeVQ5vke21hZ5yC0/FA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 11:06:32 -0000 Hi, For the 3265bis thing the following is stated: "Unless there are objections on the list, the draft will go into WGLC with = these changes." I think there are still a few issues we need to solve before we should go t= o WGLC. 1. As indicated in the meeting (also stated in the report), we need to disc= uss when REFER implicit subscriptions are created - on REFER 200 OK or on N= OTIFY. 2. There is still an open issue in the draft whether timer N applies to pro= xies. I may have missed it, but I don't see any conclusion on that.=20 3. A while ago there was a discussion on what happens in case timer N expir= es. There was a suggestion that the subscription would be terminated, but I= am not sure whether there is a decission on that. Also, I think that is im= pacted by the etag issue I raised on the list a few days ago ('RFC3265/3265= bis and draft-ietf-sipcore-subnot-etags issue regarding notification suppre= ssion'). If Adam's agenda allows it, having dedicated phone meetings to discuss thes= e issue could be a way to move things forward, in order to be able to initi= ate the WGLC. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Tuesday, March 30, 2010 9:38 PM To: SIPCORE Subject: [sipcore] Minutes Posted [as chair] A draft version of the minutes from the recent IETF meeting in Anaheim has been posted to the proceedings site: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html Please review the minutes and submit any corrections to the chairs no later than April 15th. Thank you. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From pkyzivat@cisco.com Mon Apr 5 05:51:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80ECA3A6998 for ; Mon, 5 Apr 2010 05:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp-uxPY7-gmT for ; Mon, 5 Apr 2010 05:51:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B72F3A6992 for ; Mon, 5 Apr 2010 05:51:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,365,1267401600"; d="scan'208";a="98956666" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2010 12:51:49 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35Cpn0W022970; Mon, 5 Apr 2010 12:51:49 GMT Message-ID: <4BB9DCE4.4070502@cisco.com> Date: Mon, 05 Apr 2010 08:51:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> In-Reply-To: <003201cad3a5$6f263540$4d729fc0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 12:51:52 -0000 [as an individual] Paul E. Jones wrote: >> Other, specific comments on the draft: >> 0) You might want to consider specifying what the To/From-URIs should >> be sent as, and that a receiver should be lenient. We've seen interop >> problems with those URIs for OPTIONS pings. > > I wanted to be rather strict in saying that only sip:192.168.4.56 was > acceptable, for example, but others I consulted with thought that was too > restrictive. So, the language is soft here. I believe I was one of the "others". My personal concern was that making such a mandate starts to interfere with the layering of the sip stack. If you "know" your neighbors via DNS names, then the translation to ip addresses occurs in the code that implements 3263, which is way below where you construct, send, and receive responses to messages. I didn't want to see a set of recommendations that require violation of such layering. But I'd be interested in hearing other points of view on this. Thanks, Paul From pkyzivat@cisco.com Mon Apr 5 06:03:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B1B3A698A for ; Mon, 5 Apr 2010 06:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waFpOTPxGcWd for ; Mon, 5 Apr 2010 06:03:24 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 068F03A6992 for ; Mon, 5 Apr 2010 06:03:24 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACZ8uUtAaHte/2dsb2JhbACbSnGbc5digluCLAQ X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="110275658" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2010 13:03:21 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o35D3Jn1014405; Mon, 5 Apr 2010 13:03:19 GMT Message-ID: <4BB9DF95.6040608@cisco.com> Date: Mon, 05 Apr 2010 09:03:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 13:03:25 -0000 [as individual] Christer Holmberg wrote: > Hi, > >>>> IMO this is one of the big problems with the IMS approach to services. >>>> They aren't registered, and aren't anything that the S-CSCF could (or >>>> would) return as 3xx alternatives. So the caller will be limited in what options are visible to it. >>> I am not really sure I understand what you mean... >> For instance, suppose I want to talk to your voicemail, without ringing your regular phone(s). I might send an OPTIONS in hope of getting a list of Contacts, among which the VM contact might be found. > > As I also indicated in my reply to Hadriel's e-mail, for this case I think it would be very useful to have a VM feature tag, or something else in the returned contact that indicates voicemail. Its already there, defined in 3840: actor="msg-taker". >> AFAIK, IMS isn't set up in a way to have an identifiable contact for the VM server that it could return in the 3xx. (But I'll be pleasantly surprised to learn I'm wrong.) > > IMS uses 3841. Yeah, I know that it uses 3841, but the last I knew it only did so to select among the registered contacts, after it has already applied all of the configured services. And its my impression that VM is applied as a service, that sits in the signaling path, observes the responses from UAs, and then eventually routes to VM (using a configured URI). I don't see how 3841 preferences (either to prefer or reject VM) would ever be operable in this environment. But I'd be pleased to hear that I'm wrong about this. Thanks, Paul From pkyzivat@cisco.com Mon Apr 5 06:36:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B27E28C0DE for ; Mon, 5 Apr 2010 06:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs829rt4XJfY for ; Mon, 5 Apr 2010 06:36:30 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0C99B3A69C9 for ; Mon, 5 Apr 2010 06:36:28 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANKEuUtAZnwM/2dsb2JhbACbS3GcYZdqhQcE X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="98831829" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2010 13:36:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o35DaEOK016568; Mon, 5 Apr 2010 13:36:14 GMT Message-ID: <4BB9E74E.2050209@cisco.com> Date: Mon, 05 Apr 2010 09:36:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 13:36:31 -0000 [as individual] Christer Holmberg wrote: > 3. A while ago there was a discussion on what happens in case timer N expires. > There was a suggestion that the subscription would be terminated, > but I am not sure whether there is a decission on that. Are you asking about *initial* subscriptions, or resubscribes? For initial subscription requests, there is no subscription to terminate. For resubscribes, its currently an open issue in section B.3. Are you just asking to have the open issue resolved? Thanks, Paul From adam@nostrum.com Mon Apr 5 08:07:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44B928C12F for ; Mon, 5 Apr 2010 08:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8myQE+xpj1CD for ; Mon, 5 Apr 2010 08:07:01 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 68E6928C140 for ; Mon, 5 Apr 2010 08:06:58 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o35F6qL8036057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 10:06:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB9FC8C.5040600@nostrum.com> Date: Mon, 05 Apr 2010 10:06:52 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB9E74E.2050209@cisco.com> In-Reply-To: <4BB9E74E.2050209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 15:07:02 -0000 On 4/5/10 8:36 AM, Paul Kyzivat wrote: > [as individual] > > Christer Holmberg wrote: > >> 3. A while ago there was a discussion on what happens in case timer N >> expires. There was a suggestion that the subscription would be >> terminated, >> but I am not sure whether there is a decission on that. > > Are you asking about *initial* subscriptions, or resubscribes? > > For initial subscription requests, there is no subscription to terminate. > > For resubscribes, its currently an open issue in section B.3. > > Are you just asking to have the open issue resolved? [as a document author] We had discussion around this point in Stockholm, and drove it to a conclusion on list afterwards. I put it up in Anaheim one more time, with a summary of what that conversation concluded. If someone wants to raise an objection to the decision to treat Timer N expiration the same way we treat SUBSCRIBE transaction timeouts, I'm happy to engage in that discussion. /a From adam@nostrum.com Mon Apr 5 08:16:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D1A3A69FD for ; Mon, 5 Apr 2010 08:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+ygUrdULxpV for ; Mon, 5 Apr 2010 08:16:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2EA9128C12F for ; Mon, 5 Apr 2010 08:16:07 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o35FG2gQ036750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 10:16:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB9FEB2.3030400@nostrum.com> Date: Mon, 05 Apr 2010 10:16:02 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 15:16:28 -0000 On 4/5/10 6:06 AM, Christer Holmberg wrote: > Hi, > > For the 3265bis thing the following is stated: > > "Unless there are objections on the list, the draft will go into WGLC with these changes." > > I think there are still a few issues we need to solve before we should go to WGLC. > [as document author] I think you're misinterpreting that statement. It's not saying that the document is ready for WGLC -- the proposed resolution for the various issues still needs to go into the document. The point of the note is that, barring any concrete objections to the proposed resolutions, I'll be updating the document to reflect those resolutions, and will treat them as closed. In other words, it's the last time I plan on bringing them up for discussion. I consider a yearlong effort of waving these issues at the working group to be sufficient time to let anyone's concerns be expressed. One point I would like you to clarify: > 2. There is still an open issue in the draft whether timer N applies to proxies. I may have missed it, but I don't see any conclusion on that. > Where do you see this in the draft? In any case, proxies don't inherently care about subscription state. If you're doing something in your proxy that is attempting to figure out the state of a subscription, you need to take care to figure out what's going on. In that case, yeah, Timer N is going to be of interest to you. But that's not something we need to specify -- it's actually very application-specific. /a From christer.holmberg@ericsson.com Mon Apr 5 12:02:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7988B3A6A3B for ; Mon, 5 Apr 2010 12:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zoyi+cb3N5X5 for ; Mon, 5 Apr 2010 12:02:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 92F073A6A45 for ; Mon, 5 Apr 2010 12:02:54 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-53-4bba33db4a85 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DE.39.23740.BD33ABB4; Mon, 5 Apr 2010 21:02:51 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 5 Apr 2010 21:02:51 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 5 Apr 2010 21:02:50 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrUwGETC+mv1XiKTq65T9y7Eq7LoAAMCqsq Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> , <4BB9DF95.6040608@cisco.com> In-Reply-To: <4BB9DF95.6040608@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: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:02:56 -0000 Hi, >>>>>> IMO this is one of the big problems with the IMS approach to service= s. >>>>> They aren't registered, and aren't anything that the S-CSCF could (or >>>>> would) return as 3xx alternatives. So the caller will be limited in w= hat options are visible to it. >>>> I am not really sure I understand what you mean... >>> For instance, suppose I want to talk to your voicemail, without ringing= your regular phone(s). I might send an OPTIONS in hope of getting a list o= f Contacts, among which the VM contact might be found. >> >> As I also indicated in my reply to Hadriel's e-mail, for this case I thi= nk it would be very useful to have a VM feature tag, or something else in t= he returned contact that indicates voicemail. > >Its already there, defined in 3840: actor=3D"msg-taker". True. >>>AFAIK, IMS isn't set up in a way to have an identifiable contact for the= VM server that it could return in the 3xx. (But I'll be pleasantly surpris= ed to learn I'm wrong.) >> >>IMS uses 3841. > >Yeah, I know that it uses 3841, but the last I knew it only did so to sele= ct among the registered contacts, after it has already applied all of the c= onfigured services. > >And its my impression that VM is applied as a service, that sits in the si= gnaling path, observes the responses from >UAs, and then eventually routes to VM (using a configured URI). I don't se= e how 3841 preferences (either to prefer or reject VM) would ever be >operable in this environment. As far as I know you can use ANY information, including feature tag values,= to choose the application servers to which an initial request is to be rou= ted (the procedure is called initial filter criteria in IMS language) - or = decide not to route the request to any ASs. And, I don't think there is any= thing in the IMS specifications that forbids a user to have a "local" voice= mail service. Regards, Christer= From christer.holmberg@ericsson.com Mon Apr 5 12:14:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334AD3A68D8 for ; Mon, 5 Apr 2010 12:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.043 X-Spam-Level: X-Spam-Status: No, score=-4.043 tagged_above=-999 required=5 tests=[AWL=2.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4N4wPgtsTwW for ; Mon, 5 Apr 2010 12:14:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 01F7A3A67A4 for ; Mon, 5 Apr 2010 12:14:12 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-69-4bba368112b0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A0.6B.23532.1863ABB4; Mon, 5 Apr 2010 21:14:09 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 5 Apr 2010 21:14:10 +0200 From: Christer Holmberg To: Adam Roach , Paul Kyzivat Date: Mon, 5 Apr 2010 21:14:09 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrU0aGVfPwXGjzuSo2VcsxmDFmFnwAIQhiR Message-ID: References: <4BB9E74E.2050209@cisco.com>,<4BB9FC8C.5040600@nostrum.com> In-Reply-To: <4BB9FC8C.5040600@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:14:14 -0000 Hi, >>>3. A while ago there was a discussion on what happens in case timer N >>>expires. There was a suggestion that the subscription would be >>>terminated, but I am not sure whether there is a decission on that. >> >>Are you asking about *initial* subscriptions, or resubscribes? Resubscribes. >>For initial subscription requests, there is no subscription to terminate. Agree. >>For resubscribes, its currently an open issue in section B.3. Yes. >>Are you just asking to have the open issue resolved? It seems like I missunderstood the report regarding WGLC (see Adam's e-mail= ), so I said that in my opinion we should solve the issue before we initiat= e WGLC. >[as a document author] > >We had discussion around this point in Stockholm, and drove it to a >conclusion on list afterwards. I put it up in Anaheim one more time, >with a summary of what that conversation concluded. If someone wants to >raise an objection to the decision to treat Timer N expiration the same >way we treat SUBSCRIBE transaction timeouts, I'm happy to engage in that >discussion. One alternative would be to fallback whatever state was used before the SUB= SCRIBE was sent. However, I don't really have any strong opinions about tha= t as such. My issue was that, IF there are intermediaries that maintain subscription s= tate, and they don't support subnot, they could terminate the subscription = in cases where the NOTIFY is suppressed. Of course, in case we would choose= that timer N expiration would cause a fallback there could be some state u= nsynchs between entities. So, a related question to that was: since the NOTIFY request is so essentia= l to 3265bis, should we allow it to be suppressed in the first place?=20 Regards, Christer= From christer.holmberg@ericsson.com Mon Apr 5 12:37:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AF43A6A73 for ; Mon, 5 Apr 2010 12:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=2.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eTMIiwD6MMl for ; Mon, 5 Apr 2010 12:37:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2A0CC3A6A27 for ; Mon, 5 Apr 2010 12:37:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-d2-4bba3bf02134 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D0.2C.23532.0FB3ABB4; Mon, 5 Apr 2010 21:37:21 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 5 Apr 2010 21:37:20 +0200 From: Christer Holmberg To: Adam Roach Date: Mon, 5 Apr 2010 21:37:20 +0200 Thread-Topic: rfc3265bis: SIP events redux [was [sipcore] Minutes Posted] Thread-Index: AcrU0ur+FregNEceTkSwNehl2cs+wwAI09Sp Message-ID: References: , <4BB9FEB2.3030400@nostrum.com> In-Reply-To: <4BB9FEB2.3030400@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:37:25 -0000 Hi, >>2. There is still an open issue in the draft whether timer N applies to p= roxies. I may have missed it, but I don't see any conclusion on that. > > >Where do you see this in the draft? It is not indicated in the draft. I meant that it is one of the issues I ha= ve. >In any case, proxies don't inherently care about subscription state. If >you're doing something in your proxy that is attempting to figure out >the state of a subscription, you need to take care to figure out what's >going on. In that case, yeah, Timer N is going to be of interest to you. >But that's not something we need to specify -- it's actually very >application-specific. The draft says that proxies no not need to support anything in addition to = 3261, so from that point of view you are correct. However, at the same time it talks about proxies adding Record-Route if the= y are interested in the SUBs and NOTs, so I assumed that means that they ar= e "allowed" to actually maintain subscription dialog state - in the same wa= y as they might maintain invite dialog state. Regards, Christer= From HKaplan@acmepacket.com Mon Apr 5 14:31:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADEA3A6A79 for ; Mon, 5 Apr 2010 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVTkz-HyAZ1N for ; Mon, 5 Apr 2010 14:31:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 88D0D3A6891 for ; Mon, 5 Apr 2010 14:31:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 5 Apr 2010 17:31:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 5 Apr 2010 17:31:51 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Paul E. Jones" Date: Mon, 5 Apr 2010 17:31:50 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> In-Reply-To: <4BB9DCE4.4070502@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: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 21:31:56 -0000 One problem I've seen is when something like a UA or IP-PBX is OPTIONS ping= ing "sip:sip.ssp.com" - that will resolve in DNS to an ingress proxy, which= actually is the real target of the ping request - but the ingress proxy it= self may think the OPTIONS needs to get routed to the authoritative server = for sip.ssp.com, which may well be something _after_ the proxy. =20 Setting max-forwards to 1 helps avoid that, but in some proxies that will g= et back a 483 too many hops, which is actually ok in my book - after all yo= u know its alive and processing requests - but in some devices that increme= nts error counters which people don't like. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 05, 2010 8:52 AM > To: Paul E. Jones > Cc: Hadriel Kaplan; sipcore@ietf.org; 'Vivek Bhargava (vbharga)'; 'Gonzal= o > Salgueiro' > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt >=20 > [as an individual] >=20 > Paul E. Jones wrote: >=20 > >> Other, specific comments on the draft: > >> 0) You might want to consider specifying what the To/From-URIs should > >> be sent as, and that a receiver should be lenient. We've seen interop > >> problems with those URIs for OPTIONS pings. > > > > I wanted to be rather strict in saying that only sip:192.168.4.56 was > > acceptable, for example, but others I consulted with thought that was > too > > restrictive. So, the language is soft here. >=20 > I believe I was one of the "others". >=20 > My personal concern was that making such a mandate starts to interfere > with the layering of the sip stack. If you "know" your neighbors via DNS > names, then the translation to ip addresses occurs in the code that > implements 3263, which is way below where you construct, send, and > receive responses to messages. >=20 > I didn't want to see a set of recommendations that require violation of > such layering. >=20 > But I'd be interested in hearing other points of view on this. >=20 > Thanks, > Paul From dean.willis@softarmor.com Mon Apr 5 15:40:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D062B3A6876 for ; Mon, 5 Apr 2010 15:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opBhASg62hbW for ; Mon, 5 Apr 2010 15:40:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0DE1E3A67E1 for ; Mon, 5 Apr 2010 15:40:16 -0700 (PDT) Received: from [192.168.2.109] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o35Me701004357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Apr 2010 17:40:08 -0500 Message-Id: <3D377BC0-680D-425E-A543-D71DDE6E4B38@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BB9DF95.6040608@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 17:40:01 -0500 References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> <4BB9DF95.6040608@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 22:40:16 -0000 On Apr 5, 2010, at 8:03 AM, Paul Kyzivat wrote: > g-taker". > >>> AFAIK, IMS isn't set up in a way to have an identifiable contact >>> for the VM server that it could return in the 3xx. (But I'll be >>> pleasantly surprised to learn I'm wrong.) >> IMS uses 3841. > > Yeah, I know that it uses 3841, but the last I knew it only did so > to select among the registered contacts, after it has already > applied all of the configured services. And its my impression that > VM is applied as a service, that sits in the signaling path, > observes the responses from UAs, and then eventually routes to VM > (using a configured URI). I don't see how 3841 preferences (either > to prefer or reject VM) would ever be operable in this environment. AFAIK, the AS MAY divert the INVITE to the configured VM URI if there is one, the user's profile allows this, and the request indicates a preference for VM. -- Dean From pkyzivat@cisco.com Mon Apr 5 16:10:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A68E3A6842 for ; Mon, 5 Apr 2010 16:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rw-i1TUr3F6 for ; Mon, 5 Apr 2010 16:10:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7DA723A66B4 for ; Mon, 5 Apr 2010 16:10:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKcKuktAaHte/2dsb2JhbACbTXGff5hKgluCLAQ X-IronPort-AV: E=Sophos;i="4.51,367,1267401600"; d="scan'208";a="178211342" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2010 23:09:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o35N9aC7019461; Mon, 5 Apr 2010 23:09:37 GMT Message-ID: <4BBA6DAF.9040407@cisco.com> Date: Mon, 05 Apr 2010 19:09:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> <4BB9DF95.6040608@cisco.com> <3D377BC0-680D-425E-A543-D71DDE6E4B38@softarmor.com> In-Reply-To: <3D377BC0-680D-425E-A543-D71DDE6E4B38@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 23:10:12 -0000 Dean Willis wrote: > > On Apr 5, 2010, at 8:03 AM, Paul Kyzivat wrote: >> g-taker". >> >>>> AFAIK, IMS isn't set up in a way to have an identifiable contact for >>>> the VM server that it could return in the 3xx. (But I'll be >>>> pleasantly surprised to learn I'm wrong.) >>> IMS uses 3841. >> >> Yeah, I know that it uses 3841, but the last I knew it only did so to >> select among the registered contacts, after it has already applied all >> of the configured services. And its my impression that VM is applied >> as a service, that sits in the signaling path, observes the responses >> from UAs, and then eventually routes to VM (using a configured URI). I >> don't see how 3841 preferences (either to prefer or reject VM) would >> ever be operable in this environment. > > AFAIK, the AS MAY divert the INVITE to the configured VM URI if there is > one, the user's profile allows this, and the request indicates a > preference for VM. My *impression* is that the AS would receive the call initially, note that VM is configured, set a timer for itself, Record-Route itself, and forward the call back to the S-CSCF. Eventually the S-CSCF will get around to considering registered contacts. If it honors Request-Disposition:redirect, then it will return a 3xx with the registered contacts. That 3xx will be received by the AS. If it is clever, it will realize the best thing it can do is add its VM contact to the 3xx, with a lower priority than all the others. If so, then the caller should indeed see all the possibilities, with their capabilities, and be able to make its own choice. That's actually the best outcome I have ever seen for this with IMS. I hope it all works that way. Without Request-Disposition:redirect I have not seen how this would ever work right for IMS. Chalk up another success for redirect rather than forking. Thanks, Paul From dean.willis@softarmor.com Mon Apr 5 17:09:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F9F3A6A24 for ; Mon, 5 Apr 2010 17:09:10 -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.350, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJZTOUWIaTAg for ; Mon, 5 Apr 2010 17:09:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1F0663A6A20 for ; Mon, 5 Apr 2010 17:09:09 -0700 (PDT) Received: from [192.168.2.109] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o360906V017963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Apr 2010 19:09:01 -0500 Message-Id: <266D7E51-FDE7-403A-9E78-6EB6917FC5F5@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BBA6DAF.9040407@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 19:08:54 -0500 References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> <4BB9DF95.6040608@cisco.com> <3D377BC0-680D-425E-A543-D71DDE6E4B38@softarmor.com> <4BBA6DAF.9040407@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 00:09:10 -0000 On Apr 5, 2010, at 6:09 PM, Paul Kyzivat wrote: >> > > My *impression* is that the AS would receive the call initially, > note that VM is configured, set a timer for itself, Record-Route > itself, and forward the call back to the S-CSCF. Eventually the S- > CSCF will get around to considering registered contacts. If it > honors Request-Disposition:redirect, then it will return a 3xx with > the registered contacts. > > That 3xx will be received by the AS. If it is clever, it will > realize the best thing it can do is add its VM contact to the 3xx, > with a lower priority than all the others. > > If so, then the caller should indeed see all the possibilities, with > their capabilities, and be able to make its own choice. > > That's actually the best outcome I have ever seen for this with IMS. > I hope it all works that way. Without Request-Disposition:redirect I > have not seen how this would ever work right for IMS. > > Chalk up another success for redirect rather than forking. Hmm.I thought that the S-CSCF would chain the INVITE through a series of AS, and if an AS's service needed to, it would just divert the call to VM instead of sending it to the next AS. At least that's the way we wrote the stuff originally, and it's how Dynamicsoft's stuff worked. In other words, an AS can generate the 200 OK on an initial INVITE, short-circuiting the other ASs (as well as any Registered Contacts) that might have been invoked by the profile. This 200OK follows the inverted route back through any other AS that had been invoked on the call, on to the S-CSCF, and back towards the originating UA. So, for example if the first AS invoked is set up to do a "Busy Everywhere", that's what gets returned to the caller, no matter what other AS might have been in the profile or what contacts might be registered. It makes for some careful service composition logic -- yo ucan shoot yourself in the foot -- but the composition mechanics are a lot easier than what I think you;re describing. Did somebody change this stuff while I wasn't looking? -- Dean From christer.holmberg@ericsson.com Mon Apr 5 22:35:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED103A68CC for ; Mon, 5 Apr 2010 22:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ATekX60TYa8 for ; Mon, 5 Apr 2010 22:35:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D1B1B3A6A8B for ; Mon, 5 Apr 2010 22:35:22 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-3b-4bbac8166bfb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F6.94.23740.618CABB4; Tue, 6 Apr 2010 07:35:18 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 6 Apr 2010 07:35:18 +0200 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Tue, 6 Apr 2010 07:35:17 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrVHWAiINV0YfMQT3agXiWlRkF6RQALP9RQ Message-ID: References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> <4BB9DF95.6040608@cisco.com> <3D377BC0-680D-425E-A543-D71DDE6E4B38@softarmor.com> <4BBA6DAF.9040407@cisco.com> <266D7E51-FDE7-403A-9E78-6EB6917FC5F5@softarmor.com> In-Reply-To: <266D7E51-FDE7-403A-9E78-6EB6917FC5F5@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 05:35:24 -0000 Hi,=20 >>My *impression* is that the AS would receive the call initially, note=20 >>that VM is configured, set a timer for itself, Record-Route itself,=20 >>and forward the call back to the S-CSCF. Eventually the S-=20 >>CSCF will get around to considering registered contacts. If it honors=20 >>Request-Disposition:redirect, then it will return a 3xx with the=20 >>registered contacts. >> >>That 3xx will be received by the AS. If it is clever, it=20 >>will realize the best thing it can do is add its VM contact to the 3xx, w= ith a=20 >>lower priority than all the others. >> >>If so, then the caller should indeed see all the possibilities, with=20 >>their capabilities, and be able to make its own choice. >> >>That's actually the best outcome I have ever seen for this with IMS. >>I hope it all works that way. Without Request-Disposition:redirect I=20 >>have not seen how this would ever work right for IMS. >> >>Chalk up another success for redirect rather than forking. >=20 >Hmm.I thought that the S-CSCF would chain the INVITE through=20 >a series of AS, and if an AS's service needed to, it would=20 >just divert the call to VM instead of sending it to the next=20 >AS. At least that's the way we wrote the stuff originally,=20 >and it's how Dynamicsoft's stuff worked. >=20 >In other words, an AS can generate the 200 OK on an initial=20 >INVITE, short-circuiting the other ASs (as well as any=20 >Registered Contacts) that might have been invoked by the=20 >profile. This 200OK follows the inverted route back through=20 >any other AS that had been invoked on the call, on to the=20 >S-CSCF, and back towards the originating UA. >=20 >So, for example if the first AS invoked is set up to do a=20 >"Busy Everywhere", that's what gets returned to the caller,=20 >no matter what other AS might have been in the profile or=20 >what contacts might be registered. It makes for some careful=20 >service composition logic -- yo ucan shoot yourself in the=20 >foot -- but the composition mechanics are a lot easier than=20 >what I think you;re describing. >=20 >Did somebody change this stuff while I wasn't looking? You haven't been looking for a long time :) Anyway, I don't think it has been changed. But, I think you are talking abo= ut an INVITE 3xx use-case, not an OPTIONS 3xx use-case. OPTIONS is used in order to query capabilities, and I think it is a policy/= implementation issue whether the operator wants to return contacts pointing= to specific services. Regards, Christer From pkyzivat@cisco.com Tue Apr 6 05:49:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8973A68E8 for ; Tue, 6 Apr 2010 05:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.835 X-Spam-Level: X-Spam-Status: No, score=-9.835 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahHwN1hvIPpp for ; Tue, 6 Apr 2010 05:49:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9F8BD3A68AA for ; Tue, 6 Apr 2010 05:49:25 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8CANbKukuQ/uCWe2dsb2JhbACbShUBAQsLIgYcn2mYf4UJBA X-IronPort-AV: E=Sophos;i="4.51,372,1267401600"; d="scan'208";a="59029642" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2010 12:49:22 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o36CnLli009277; Tue, 6 Apr 2010 12:49:21 GMT Message-ID: <4BBB2DD1.8050802@cisco.com> Date: Tue, 06 Apr 2010 08:49:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <4BB24B81.1050006@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79E9303F@mail> <4BB52B53.7000102@cisco.com> <4BB74377.10107@cisco.com> <4BB9DF95.6040608@cisco.com> <3D377BC0-680D-425E-A543-D71DDE6E4B38@softarmor.com> <4BBA6DAF.9040407@cisco.com> <266D7E51-FDE7-403A-9E78-6EB6917FC5F5@softarmor.com> In-Reply-To: <266D7E51-FDE7-403A-9E78-6EB6917FC5F5@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:49:30 -0000 Dean Willis wrote: > > On Apr 5, 2010, at 6:09 PM, Paul Kyzivat wrote: >>> >> >> My *impression* is that the AS would receive the call initially, note >> that VM is configured, set a timer for itself, Record-Route itself, >> and forward the call back to the S-CSCF. Eventually the S-CSCF will >> get around to considering registered contacts. If it honors >> Request-Disposition:redirect, then it will return a 3xx with the >> registered contacts. >> >> That 3xx will be received by the AS. If it is clever, it will realize >> the best thing it can do is add its VM contact to the 3xx, with a >> lower priority than all the others. >> >> If so, then the caller should indeed see all the possibilities, with >> their capabilities, and be able to make its own choice. >> >> That's actually the best outcome I have ever seen for this with IMS. >> I hope it all works that way. Without Request-Disposition:redirect I >> have not seen how this would ever work right for IMS. >> >> Chalk up another success for redirect rather than forking. > > Hmm.I thought that the S-CSCF would chain the INVITE through a series of > AS, and if an AS's service needed to, it would just divert the call to > VM instead of sending it to the next AS. At least that's the way we > wrote the stuff originally, and it's how Dynamicsoft's stuff worked. My knowledge is probably no more recent than yours. AFAIK it *could* do that. But in the case of VM, it first has to know that VM is required on the call. Normally that doesn't happen until the registered contacts are tried. And VM isn't one of the registered contacts. So I *think* the AS just lurks as a proxy to see what else will happen, and then later might divert the call to VM. > In other words, an AS can generate the 200 OK on an initial INVITE, > short-circuiting the other ASs (as well as any Registered Contacts) that > might have been invoked by the profile. This 200OK follows the inverted > route back through any other AS that had been invoked on the call, on to > the S-CSCF, and back towards the originating UA. It could do that if it was able to conclude that VM was the desired outcome without trying any of the other candidates. But how would it figure that out? > So, for example if the first AS invoked is set up to do a "Busy > Everywhere", that's what gets returned to the caller, no matter what > other AS might have been in the profile or what contacts might be > registered. It makes for some careful service composition logic -- yo > ucan shoot yourself in the foot -- but the composition mechanics are a > lot easier than what I think you;re describing. > > Did somebody change this stuff while I wasn't looking? Probably not. But either we should stop talking about it here, or else we should get somebody who really knows to tell us the answer. Thanks, Paul From Martin.Thomson@andrew.com Mon Apr 5 22:26:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CBB3A686A; Mon, 5 Apr 2010 22:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jjo9DfWdxv6; Mon, 5 Apr 2010 22:26:03 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 02CE43A69FF; Mon, 5 Apr 2010 22:22:26 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:61473 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S16329260Ab0DFFWJ (ORCPT + 2 others); Tue, 6 Apr 2010 00:22:09 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 6 Apr 2010 00:22:08 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 6 Apr 2010 13:22:06 +0800 From: "Thomson, Martin" To: Simple WG , "Peterson, Jon" , "James M. Polk" Date: Tue, 6 Apr 2010 13:23:29 +0800 Thread-Topic: By-reference and by-value Thread-Index: AcrVSUqeyckad73EREiiZPDXKHf86Q== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E3F3060A@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-Mailman-Approved-At: Tue, 06 Apr 2010 06:32:33 -0700 Subject: [sipcore] By-reference and by-value X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 05:26:13 -0000 VGhlIHNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZSByZWJvb3QgZGlzY3Vzc2lvbiBbMV0gcmFp c2VkIGFuIGludGVyZXN0aW5nIHByb2JsZW0uDQoNCiggSSd2ZSBzdGFydGVkIHRoaXMgZGlzY3Vz c2lvbiBvbiB0aGUgc2ltcGxlIFdHIGxpc3QsIHNpbmNlIHRoYXQgaXMgd2hlcmUgSSBiZWxpZXZl IG1vc3QgcHJlc2VuY2UgZGF0YSBtb2RlbCBleHBlcnRpc2UgaXMgbGlrZWx5IHRvIGJlIGNvbmNl bnRyYXRlZC4gIEkndmUgYmNjJ2Qgc2lwY29yZSBhbmQgZ2VvcHJpdiwgZnJvbSB3aGljaCB0aGVy ZSBtaWdodCBiZSBpbnRlcmVzdCBpbiB0aGlzIGRpc2N1c3Npb24uICkNCg0KT25lIGltcG9ydGFu dCBmZWF0dXJlIGlzIGNvbmN1cnJlbnQgY29udmV5YW5jZSBvZiBsb2NhdGlvbiBieS1yZWZlcmVu Y2UgYW5kIGJ5LXZhbHVlLiAgVGhpcyBpcyBhcHBsaWVkIGluIGRpZmZlcmVudCB3YXlzLg0KDQpJ biBvbmUgdXNlIGNhc2UsIGEgcmVjaXBpZW50IG1pZ2h0IHVzZSB0aGlzIHRvIGdldCB0aGUgbG9j YXRpb24gZm9yIG5vdywgYW5kIGhhdmUgYSBtZWFucyBvZiBnZXR0aW5nIGxvY2F0aW9uIGZvciBs YXRlci4gIFRoaXMgaXMgaW1wb3J0YW50IGZvciBlbWVyZ2VuY3kgY2FsbGluZyBhbmQgaXQgaXMg ZnVuZGFtZW50YWwgdG8gbG9jYXRpb24gaGlkaW5nIGluIEVDUklUIChkcmFmdC1pZXRmLWVjcml0 LWxvY2F0aW9uLWhpZGluZy1yZXEgYW5kIGRyYWZ0LWlldGYtZWNyaXQtcm91Z2gtbG9jKS4NCg0K Sm9uIHN1Z2dlc3RzIHRoYXQgIml0IGlzIGZhciBsZXNzIGJyaXR0bGUgdG8gZXh0ZW5kIFBJREYg dGhhbiB0byBhZGQgdGhpcyB0byBTSVAiLiAgQSBjbGFpbSB0aGF0IHNlZW1zIGFtcGx5IHN1cHBv cnRlZCBieSBleGhpYml0IEIgWzJdIGFuZCBpdHMgcGVyc2lzdGVudCBkcmFmdCBzdGF0dXMuDQoN CkknZCBsaWtlIHRvIGV4cGxvcmUgaG93IHdlIGFkZHJlc3MgdGhpcyBwcm9ibGVtIHdpdGggYSBQ SURGIGV4dGVuc2lvbi4NCg0KQW5kLi4uaWYgdGhpcyB3b3JrcyBvdXQsIHBlcmhhcHMgd2UgY2Fu IGFsc28ga2lsbCBhbm90aGVyIGJpcmQgWzNdIHdpdGggdGhlIHNhbWUgc3RvbmUuDQoNClRoZSBw cm9ibGVtLCBhcyBJIHNlZSBpdCwgaXMgdGhlIGluY2x1c2lvbiBvZiBwcmVzZW5jZSBzdGF0ZSBi eSByZWZlcmVuY2UsIHVzaW5nIGEgVVJJLiAgDQoNCk9yLCBpZiB3ZSB0aGluayBvZiB0aGUgVVJJ IGFzIGFuIHVubGlua2VkIHBzZXVkb255bSB3aXRoIGFzc29jaWF0ZWQgcHJlc2VuY2Ugc3RhdGUs IGl0IGlzIHRoZSBsaW5raW5nIG9mIHRoYXQgcHNldWRvbnltIHRvIGFub3RoZXIgZW50aXR5IHdp dGggdGhlIGludGVudCBvZiBhbHNvIGxpbmtpbmcgdGhlIHN0YXRlLg0KDQooIFRoYXQgbGFzdCBz dGF0ZW1lbnQgcHJvYmFibHkgbmVlZHMgYSBiaXQgbW9yZSBleHBsYW5hdGlvbi4gIEluIEhFTEQs IGEgTElTIGNyZWF0ZXMgYSBsb2NhdGlvbiBvYmplY3QuICBUaGUgc3ViamVjdCwgb3IgcHJlc2Vu dGl0eSwgb2YgdGhhdCBsb2NhdGlvbiBvYmplY3QgaXMgYSBkZXZpY2UuIA0KDQooIEZvciBwcml2 YWN5IHJlYXNvbnMsIHdlIGRvbid0IHdhbnQgdG8gbGluayB0aGUgZGV2aWNlIGlkZW50aXR5IHRv IHRoZSBsb2NhdGlvbi4gIFRoZSBkZXZpY2Ugb3duZXIvcnVsZSBtYWtlciBtaWdodCBub3Qgd2lz aCBmb3IgdGhhdCB0byBoYXBwZW4gLSB0aGlzIGxpbmthZ2UgbXVzdCBvY2N1ciB1bmRlciB0aGVp ciBjb250cm9sLiAgVGh1cywgdGhlIExJUyBjcmVhdGVzIGFuIHVubGlua2VkIHBzZXVkb255bSBm b3IgdGhlIGRldmljZSB0byB1c2UgYXMgdGhlIHByZXNlbnRpdHkgaWRlbnRpZmllciBbNF0uICkN Cg0KSWYgYW4gZW50aXR5IC0gdXNlciwgZGV2aWNlIG9yIG90aGVyd2lzZSAtIHdpc2hlcyBmb3Ig dGhpcyBpbmZvcm1hdGlvbiB0byBiZSBsaW5rZWQgd2l0aCB0aGVtLCB0aGV5IHRha2UgdGhlIGxv Y2F0aW9uIGluZm9ybWF0aW9uIGFuZCB1c2UgaXQgaW4gdGhlaXIgb3duIHByZXNlbmNlLg0KDQpX aGF0IHRoaXMgaW1wbGllcyBpcyB0aGF0IHdlIG5lZWQgYSB3YXkgdG8gbGluayBvbmUgcHJlc2Vu Y2UgZG9jdW1lbnQgdG8gYW5vdGhlciwgdXNpbmcgYSBVUkkuDQoNCllvdSBjYW4gYWxzbyBtYWRl IGEgZ29vZCBhcmd1bWVudCB0aGF0IHRoZSBsaW5rYWdlIHN0YXJ0IGZyb20gYW55IG9mIHRoZSBm b3VyIGZ1bmRhbWVudGFsIGVsZW1lbnRzIGluIHRoZSBkYXRhIG1vZGVsIFtSRkM0NDc5XTogdGhl IHVuLXR5cGVkIDx0dXBsZT4sIDxwZXJzb24+LCA8ZGV2aWNlPiwgb3IgPHNlcnZpY2U+Lg0KDQpU aGUgcmVmZXJlbmNlIGJlY29tZXMgdGhlICJzdGF0dXMiIG9mIHRoZSBlbGVtZW50LiAgVGh1cywg d2UgaGF2ZToNCg0KICA8cHJlc2VuY2UgZW50aXR5PSJwcmVzOmZvb0BleGFtcGxlLmNvbSI+DQog ICAgPHR1cGxlIGlkPSJzZzg5YWUiPg0KICAgICAgPHN0YXR1cz4NCiAgICAgICAgPGJyOnJlZmVy ZW5jZT5wcmVzOnRoaW5nQGV4YW1wbGUubmV0PC9icjpyZWZlcmVuY2U+DQogICAgICA8L3N0YXR1 cz4NCiAgICA8L3R1cGxlPg0KICAgIDxkbTpwZXJzb24gaWQ9InAxIj4NCiAgICAgIDxicjpyZWZl cmVuY2U+cHJlczpwZXJzb25AZXhhbXBsZS5uZXQ8L2JyOnJlZmVyZW5jZT4NCiAgICA8L2RtOnBl cnNvbj4NCiAgICA8ZG06ZGV2aWNlIGlkPSJwYzEyMiI+DQogICAgICA8YnI6cmVmZXJlbmNlPnBy ZXM6ZGV2aWNlQGV4YW1wbGUubmV0PC9icjpyZWZlcmVuY2U+DQogICAgICA8ZG06ZGV2aWNlSUQ+ bWFjOjhhc2Q3ZDdkNzA8L2RtOmRldmljZUlEPg0KICAgIDwvZG06ZGV2aWNlPg0KICA8L3ByZXNl bmNlPg0KDQpJbmZvcm1hdGlvbiBwcm92aWRlZCBieSBIRUxEIG9yIERIQ1AgcmVsYXRlcyB0byBh IGRldmljZSAoSEVMRCBpcyBjbGVhciBhYm91dCB0aGlzLCBhbmQgSSBhc3N1bWUgdGhlIHNhbWUg dG8gYmUgdHJ1ZSBmb3IgREhDUCkuICBGb3IgbG9jYXRpb24sIHRoZSByZWZlcmVuY2VkIGRvY3Vt ZW50IG1pZ2h0IGluY2x1ZGUgc3BlY2lmaWMgdHlwaW5nIGZvciB0aGUgcHJlc2VuY2UgZGF0YSB0 aGF0IGl0IGluY2x1ZGVzLCBvciBpdCBtaWdodCBiZSBpbnRlbnRpb25hbGx5IHNpbGVudC4NCg0K QSBQSURGIGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgYSByZWZlcmVuY2UgY291bGQgc3BlY2lmeSB0 eXBlLCBieSBhZGRpbmcgdGhlIHJlZmVyZW5jZSB0byBhIHR5cGVkIGVsZW1lbnQuICBJbiB0aGlz IHNpbXBsZSBjYXNlLCB0aGlzIHdvdWxkIGJlIDxkZXZpY2U+LCBidXQgaXQncyBhbHNvIHBvc3Np YmxlIHRvIG1ha2UgYSBzdGF0ZW1lbnQgYWJvdXQgYSBwZXJzb24gLSBhbmQgdGhlaXIgcHJveGlt aXR5IHRvIHRoZSBkZXZpY2UgLSBieSB1c2luZyB0aGUgPHBlcnNvbj4gZWxlbWVudC4NCg0KVGhl IHJlZmVyZW5jZWQgZG9jdW1lbnQgbWlnaHQgdXNlIHR5cGVkIGVsZW1lbnRzLiAgT3IsIGJvdGgg ZG9jdW1lbnRzIGNvdWxkIGF2b2lkIGV4cGxpY2l0IHN0YXRlbWVudHMgb24gdHlwZS4gIFRoZXJl IGlzIG5vIHJlYWwgcmlzayBvZiBjb25mdXNpb24gLSBldmVuIGlmIGJvdGggZG9jdW1lbnRzIHNw ZWNpZnkgdHlwZSwgdGhpcyBvbmx5IGRlY2xhcmVzIHRoYXQgYm90aCBlbnRpdGllcyBzaGFyZSBw cmVzZW5jZSBkYXRhLg0KDQpJdCdzIHRlbXB0aW5nIHRvIHNwZWNpZnkgaG93IHRoaXMgaW5mb3Jt YXRpb24gaXMgc3Vic2VxdWVudGx5IGNvbXBvc2l0ZWQuICBIb3dldmVyLCBzb21lb25lIHdpdGgg ZmFyIG1vcmUgZXhwZXJpZW5jZSBpbiB0aGlzIGFyZWEgdGhhbiBJIHBvaW50ZWQgb3V0IHRoYXQg YW55IGF0dGVtcHQgdG8gZG8gc28gd291bGQgYmUgYm90aCBkZXN0cnVjdGl2ZSBhbmQgZnV0aWxl LiAgTGV0IHRoZSByZWNpcGllbnRzIGRlY2lkZSBob3cgdGhleSB3YW50IHRvIHN0cnVjdHVyZSB0 aGUgZGF0YS4NCg0KRm9yIGEgcHJlc2VuY2Ugc2VydmVyIHRoYXQgcmVjZWl2ZXMgYSBwdWJsaXNo IGNvbnRhaW5pbmcgdGhpcyBkYXRhLCB0aGV5IGNob29zZSBob3cgdGhpcyBpcyBwcmVzZW50ZWQg dG8gd2F0Y2hlcnMuICBUaGVyZSBpcyBhIGNob2ljZSBvdmVyIHdoYXQgdG8gcHJvdmlkZTogbm8g aW5mb3JtYXRpb24sIGluZm9ybWF0aW9uIHJldHJpZXZlZCBmcm9tIHRoZSByZWZlcmVuY2UgYW5k IGNvbXBvc2l0ZWQgc29tZWhvdywgb3IgdGhlIFVSSS4gIFBvbGljeSBhbHNvIGhhcyBhIHNheSBp biB0aGlzLg0KDQpJdCB3b3VsZCBiZSByZW1pc3Mgbm90IHRvIGFsc28gYWRkcmVzcyB0aGUgcG9s aWN5IGNvbmNlcm5zLiAgUkZDIDUwMjUgKHByZXNlbmNlIHBvbGljeSkgZGVzY3JpYmVzIHByb3Zp ZGUtKiBydWxlcyB0aGF0IGFyZSB1c2VkIHRvIGxpbWl0IHdoYXQgYSBwcmVzZW5jZSByZWNpcGll bnQgY2FuIHNlZS4gIFRoaXMgaXMgcGFydGljdWxhcmx5IGltcG9ydGFudCBpbiB0aGlzIGNhc2Uu DQoNClBvbGljeSBjYW4gYmUgY3JhZnRlZCB0byBhcHBseSB0byBhIHN1YnNjcmlwdGlvbiwgYnV0 IHRoZSBzYW1lIG1pZ2h0IG5vdCBiZSB0cnVlIG9mIHRoZSByZWZlcmVuY2UgdGhhdCBpcyB0aGVy ZWJ5IHJldmVhbGVkLiAgRnJvbSBhIHByaXZhY3kgcG9saWN5IHBlcnNwZWN0aXZlLCB0aGlzIGlz IGEgcHJvYmxlbS4gIFRoaXMgaXMgZXNwZWNpYWxseSBwcm9ibGVtYXRpYyB3aGVuIHlvdSBjb25z aWRlciB0aGF0IGEgcmVmZXJlbmNlIGNhbiBsaXZlIGxvbmdlciB0aGFuIHRoZSBzdWJzY3JpcHRp b24gdGhhdCByZXZlYWxlZCBpdC4NCg0KUkZDIDUwMjUgaGFzIHNwZWNpZmljIHBvbGljeSBwb2lu dHMgZm9yIGNvbnRyb2xsaW5nIGhvdyBlYWNoIHByZXNlbmNlIGF0dHJpYnV0ZSBpcyByZXZlYWxl ZC4gIEdlb3ByaXYtcG9saWN5IGV4dGVuZHMgdGhvc2UgZm9yIGJvdGggb2YgdGhlIGxvY2F0aW9u IHR5cGVzLiAgRGVmYXVsdCBpcyB0byBzdXBwcmVzcyB1bmtub3duIGF0dHJpYnV0ZXMsIHdoaWNo IGlzIGdvb2QsIGJ1dCBubyBleGlzdGluZyBlbGVtZW50IGhhcyB0aGUgc2FtZSBwb3RlbnRpYWwg Zm9yIGRhbWFnZSBhcyBhIHJlZmVyZW5jZS4NCg0KVGh1cywgd2UgbmVlZCB0byBkZWZpbmUgYSA8 cHJvdmlkZS1yZWZlcmVuY2U+IGV4dGVuc2lvbiB0byBwcmVzZW5jZSBwb2xpY3kuICBNb3Jlb3Zl ciwgdGhlIHJlbGF0ZWQgZGlzY3Vzc2lvbiBvbiB0aGUgaW1wbGljYXRpb25zIG9mIGluY2x1ZGlu ZyB0aGlzIGluIGEgcG9saWN5IG5lZWQgdG8gYmUgbWFkZSBjbGVhci4gIEJldHRlciB0aGF0IHRo YW4gcmVseSBvbiA8cHJvdmlkZS11bmtub3duLWF0dHJpYnV0ZT4gYW5kIHRoZSBhYmlsaXR5IG9m IHJ1bGUgbWFrZXJzIHRvIHJlY29nbml6ZSBhbGwgdGhlIHJpc2tzLg0KDQpNeSBpbnRlbnQgaXMg dG8gc3VibWl0IGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgaG93IHRvIGluY2x1ZGUgYSByZWZlcmVu Y2UgaW4gYSBQSURGIGRvY3VtZW50IGFuZCBhbGwgdGhlIGNvbnNlcXVlbmNlcyBhcmlzaW5nIGZy b20gdGhhdC4NCg0KSSdkIGJlIGhhcHB5IHRvIGhlYXIgZnJvbSBzb21lb25lIHdobyBpcyB3aWxs aW5nIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSBvciBldmVuIHRvIHVuZGVydGFrZSB0aGUgZWZmb3J0 IHRoZW1zZWx2ZXMuDQoNCi0tTWFydGluDQoNClsxXSBUaHJlYWQgaGVhZDogPGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDIyMDIuaHRtbD4N ClsyXSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLWxvY2F0 aW9uLWNvbnZleWFuY2U+DQpbM10gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdh cmNpYS1nZW9wcml2LWluZGlyZWN0LXB1Ymxpc2g+IC4uLmFuZCBieSBraWxsLCBJIHJlYWxseSBt ZWFuIGl0LiAgVGhpcyBlZmZvcnQgaXMgbGlrZWx5IHN1YnN1bWVkIGJ5IHRoZSBwcm9wb3NlZCB3 b3JrLCB0aG91Z2ggYSBzZWN0aW9uIG9uIHRoZSBpbXBsaWNhdGlvbnMgc2VlbXMgYXBwcm9wcmlh dGUuDQpbNF0gRm9yIHRoZSBzYW1lIHJlYXNvbiwgb3VyIHByb2R1Y3QgZG9lcyBub3QgdXNlIHRo ZSA8ZGV2aWNlPiBlbGVtZW50LCBiZWNhdXNlIHRoYXQgcmVxdWlyZXMgYSBsaW5rYWdlIHRvIGRl dmljZSBpZGVudGl0eS4NCg== From john.elwell@siemens-enterprise.com Tue Apr 6 07:09:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE2F3A68AC for ; Tue, 6 Apr 2010 07:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kysl0jor56cZ for ; Tue, 6 Apr 2010 07:09:21 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 27A7E3A687F for ; Tue, 6 Apr 2010 07:09:20 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1455553; Tue, 6 Apr 2010 16:09:17 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 938D81EB82AB; Tue, 6 Apr 2010 16:09:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 6 Apr 2010 16:09:17 +0200 From: "Elwell, John" To: Adam Roach , SIPCORE Date: Tue, 6 Apr 2010 16:09:16 +0200 Thread-Topic: [sipcore] Consensus Call: SIP Table 2 Thread-Index: AcrQOgOMJALMTvR0Qp2zQNiBIGpt+wFWLPIQ Message-ID: References: <4BB24828.80805@nostrum.com> In-Reply-To: <4BB24828.80805@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CADE203FD4MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:09:22 -0000 --_000_A444A0F8084434499206E78C106220CADE203FD4MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No objection. John ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 30 March 2010 19:51 To: SIPCORE Subject: [sipcore] Consensus Call: SIP Table 2 [as chair] Last week, at the face-to-face meeting in Anaheim, the SIPCORE participants= in attendance had a discussion regarding the future of Tables 2 and 3 in R= FC 3261. A summary of the conversation, along with links to the presentatio= ns and an audio recording of the conversation, can be found in the minutes: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%= 20/%203 During that conversation, the chairs polled those present for support betwe= en two options: 1. Produce an artifact stating that documents defining new header fields = and methods define semantics in prose, and will no longer extend Table 2; o= r 2. Produce an RFC that defines new procedures for adding elements to Tabl= e 2 as new header fields and methods are defined Among those present, there was strong support for option 1. If you wish to = raise an objection to this direction, please do so on the SIPCORE mailing l= ist before April 15th. Thank you. /a --_000_A444A0F8084434499206E78C106220CADE203FD4MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No objection.
 
John

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 30 March 2010 19:51
To:=20 SIPCORE
Subject: [sipcore] Consensus Call: SIP Table=20 2

[as chair]

Last week, at the face-to-face meeting in=20 Anaheim, the SIPCORE participants in attendance had a discussion regardin= g the=20 future of Tables 2 and 3 in RFC 3261. A summary of the conversation, alon= g=20 with links to the presentations and an audio recording of the conversatio= n,=20 can be found in the minutes:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.ht= ml#SIP%20Table%202%20/%203

During=20 that conversation, the chairs polled those present for support between tw= o=20 options:
  1. Produce an artifact stating that documents defining new header fiel= ds=20 and methods define semantics in prose, and will no longer extend Table = 2;=20 or

  2. Produce an RFC that defines new procedures for adding elements to T= able=20 2 as new header fields and methods are defined
Among those pr= esent,=20 there was strong support for option 1. If you wish to raise an objection = to=20 this direction, please do so on the SIPCORE mailing list before April=20 15th.

Thank you.

/a
--_000_A444A0F8084434499206E78C106220CADE203FD4MCHP058Aglobala_-- From pkyzivat@cisco.com Tue Apr 6 07:16:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973B43A67F4 for ; Tue, 6 Apr 2010 07:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rrmoG2wPzGn for ; Tue, 6 Apr 2010 07:16:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A8DE13A68B3 for ; Tue, 6 Apr 2010 07:16:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPfuktAZnwN/2dsb2JhbACbSnGhQJh4hQkE X-IronPort-AV: E=Sophos;i="4.51,372,1267401600"; d="scan'208";a="99302930" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2010 14:16:31 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o36EGV70028968; Tue, 6 Apr 2010 14:16:31 GMT Message-ID: <4BBB423F.5090109@cisco.com> Date: Tue, 06 Apr 2010 10:16:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <4BB24828.80805@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:16:43 -0000 +1 Elwell, John wrote: > No objection. > > John > > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > *On Behalf Of *Adam Roach > *Sent:* 30 March 2010 19:51 > *To:* SIPCORE > *Subject:* [sipcore] Consensus Call: SIP Table 2 > > [as chair] > > Last week, at the face-to-face meeting in Anaheim, the SIPCORE > participants in attendance had a discussion regarding the future of > Tables 2 and 3 in RFC 3261. A summary of the conversation, along > with links to the presentations and an audio recording of the > conversation, can be found in the minutes: > > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203 > > During that conversation, the chairs polled those present for > support between two options: > > 1. Produce an artifact stating that documents defining new header > fields and methods define semantics in prose, and will no > longer extend Table 2; or > > 2. Produce an RFC that defines new procedures for adding elements > to Table 2 as new header fields and methods are defined > > Among those present, there was strong support for option 1. If you > wish to raise an objection to this direction, please do so on the > SIPCORE mailing list before April 15th. > > Thank you. > > /a > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Apr 6 07:18:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D266E3A6961 for ; Tue, 6 Apr 2010 07:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkkwVw1Tp+kG for ; Tue, 6 Apr 2010 07:18:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B26063A68C2 for ; Tue, 6 Apr 2010 07:18:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPfuktAZnwM/2dsb2JhbACbSnGhQJh4hQkE X-IronPort-AV: E=Sophos;i="4.51,372,1267401600"; d="scan'208";a="99303335" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2010 14:17:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o36EHvwR022689; Tue, 6 Apr 2010 14:17:58 GMT Message-ID: <4BBB4295.7070201@cisco.com> Date: Tue, 06 Apr 2010 10:17:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <4BB24828.80805@nostrum.com> <4BBB423F.5090109@cisco.com> In-Reply-To: <4BBB423F.5090109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:18:02 -0000 [this was as an individual] Paul Kyzivat wrote: > +1 > > Elwell, John wrote: >> No objection. >> >> John >> >> >> ------------------------------------------------------------------------ >> *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] >> *On Behalf Of *Adam Roach >> *Sent:* 30 March 2010 19:51 >> *To:* SIPCORE >> *Subject:* [sipcore] Consensus Call: SIP Table 2 >> >> [as chair] >> >> Last week, at the face-to-face meeting in Anaheim, the SIPCORE >> participants in attendance had a discussion regarding the future of >> Tables 2 and 3 in RFC 3261. A summary of the conversation, along >> with links to the presentations and an audio recording of the >> conversation, can be found in the minutes: >> >> >> http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203 >> >> >> During that conversation, the chairs polled those present for >> support between two options: >> >> 1. Produce an artifact stating that documents defining new header >> fields and methods define semantics in prose, and will no >> longer extend Table 2; or >> >> 2. Produce an RFC that defines new procedures for adding elements >> to Table 2 as new header fields and methods are defined >> Among those present, there was strong support for option 1. If you >> wish to raise an objection to this direction, please do so on the >> SIPCORE mailing list before April 15th. >> >> Thank you. >> >> /a >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Tue Apr 6 10:56:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BBD3A681C for ; Tue, 6 Apr 2010 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=1.865, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAFtw72jmqjY for ; Tue, 6 Apr 2010 10:56:40 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 47AF03A6841 for ; Tue, 6 Apr 2010 10:56:34 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 6 Apr 2010 10:56:31 -0700 From: Brett Tate To: Adam Roach , SIPCORE Date: Tue, 6 Apr 2010 10:55:43 -0700 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrU0bu62BCqas2pR6eucY/CrHCXVwA3VoTA Message-ID: <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com> In-Reply-To: <4BB9FC8C.5040600@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:56:41 -0000 > If someone wants to raise an objection to the decision to=20 > treat Timer N expiration the same way we treat SUBSCRIBE=20 > transaction timeouts, I'm happy to engage in that discussion. The decision has an interesting interaction concerning overload. More spec= ifically if SUBSCRIBE received from device that the notifier still thinks i= s in overload, notifier will send 200 response but not the NOTIFY until lat= er. Or an overloaded middle box throttling some traffic might reject the N= OTIFY with 500/503 Retry-After. Concerning the overload interactions, is the decision concerning Timer N ex= piration acceptable since not allowing SUBSCRIBE 200 response to confirm th= e subscription creation? From dworley@avaya.com Tue Apr 6 12:31:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757FF3A6AEF for ; Tue, 6 Apr 2010 12:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Y9Qm1Npq5L for ; Tue, 6 Apr 2010 12:31:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D50D33A6AE8 for ; Tue, 6 Apr 2010 12:29:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="212343416" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Apr 2010 15:29:36 -0400 X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="449142325" Received: from unknown (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Apr 2010 15:28:56 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 6 Apr 2010 15:28:56 -0400 From: "WORLEY, DALE R (DALE)" To: Christer Holmberg , Adam Roach Date: Tue, 6 Apr 2010 15:26:04 -0400 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrU0ur+FregNEceTkSwNehl2cs+wwAI09SpADIxTwk= Message-ID: References: , <4BB9FEB2.3030400@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:31:52 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] >In any case, proxies don't inherently care about subscription state. If >you're doing something in your proxy that is attempting to figure out >the state of a subscription, you need to take care to figure out what's >going on. In that case, yeah, Timer N is going to be of interest to you. >But that's not something we need to specify -- it's actually very >application-specific. The draft says that proxies no not need to support anything in addition to = 3261, so from that point of view you are correct. However, at the same time it talks about proxies adding Record-Route if the= y are interested in the SUBs and NOTs, so I assumed that means that they ar= e "allowed" to actually maintain subscription dialog state - in the same wa= y as they might maintain invite dialog state. _______________________________________________ Even if a proxy is keeping subscription-state information, I don't see Time= r N introducing a problem. The proxy sees all the SUBSCRIBEs and NOTIFYs a= nd their responses. Under 3265bis, the NOTIFYs, actually, the the *respons= es* to the NOTIFYs show all of the subscription state. In particular, in s= eciton 4.1.2.4, I see: Until Timer N expires, several NOTIFY messages may arrive from different destinations (see Section 4.4.1). Each of these messages establish a new dialog and a new subscription. After the expiration of Timer N, the subscriber SHOULD reject any such NOTIFY messages that would otherwise establish a new dialog with a "481" response code. Dale From dworley@avaya.com Tue Apr 6 13:01:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E916C28C0DD for ; Tue, 6 Apr 2010 13:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHVqxVybffxc for ; Tue, 6 Apr 2010 13:01:31 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id F0EB528C0D0 for ; Tue, 6 Apr 2010 13:01:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="10494951" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 06 Apr 2010 16:01:28 -0400 X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="462069641" Received: from unknown (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Apr 2010 16:01:27 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 6 Apr 2010 16:01:27 -0400 From: "WORLEY, DALE R (DALE)" To: Salvatore Loreto , "sipcore@ietf.org" Date: Tue, 6 Apr 2010 16:01:26 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3 Message-ID: References: <4BB24B81.1050006@nostrum.com>,<4BB44CE6.2070402@ericsson.com> In-Reply-To: <4BB44CE6.2070402@ericsson.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: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:01:32 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Salv= atore Loreto [salvatore.loreto@ericsson.com] Sent: Thursday, April 01, 2010 3:36 AM A good mechanism to discovery UA capabilities is essential to provide meani= ngful service: So I am in favor of pursuing the work, in particular the possibility to use a single OPTIONS request to retrieve t= he capabilities from ALL UAS(s) behind a forking proxy. _______________________________________ I think it is a misconception to use UA discovery to provide services. The= difficulty is that the set of available UAs for a given destination URI ch= anges unpredictably -- elements become inacessible (mobile phone out of ran= ge!), call routing changes due to time of day, etc. Instead, SIP provides = a remarkably effective system for selecting the best target of a call *at t= he moment the call is initiated* -- the caller declares his preferences, an= d the various intermediate elements combine the caller's desires with the r= outing information that they possess to forward the call closer to the pref= erred destination. As a developer, I've had to wrestle with this. In order to provide clean "= Is extension 1234 busy?" information, our "BLF agent" maintains subscriptio= ns to the "reg" event package for the AOR "sip:1234@example.com". For each= reported contact for the AOR, it maintains a dialog subscription to the co= ntact. Only by tracking the "reg" events can it keep track of the UAs avai= lable for that AOR. And even then, it is at the mercy of network failures. Dale From christer.holmberg@ericsson.com Tue Apr 6 13:02:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1693C28C0D0 for ; Tue, 6 Apr 2010 13:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=1.850, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MenEmXwh2v+n for ; Tue, 6 Apr 2010 13:02:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E9DE328C0DD for ; Tue, 6 Apr 2010 13:02:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-2a-4bbb9351485c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8A.AA.23532.1539BBB4; Tue, 6 Apr 2010 22:02:26 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 6 Apr 2010 22:02:25 +0200 From: Christer Holmberg To: "WORLEY, DALE R (DALE)" , Adam Roach Date: Tue, 6 Apr 2010 22:02:25 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrU0ur+FregNEceTkSwNehl2cs+wwAI09SpADIxTwkAAQUhLA== Message-ID: References: , <4BB9FEB2.3030400@nostrum.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:02:31 -0000 Hi, >>In any case, proxies don't inherently care about subscription state. If >>you're doing something in your proxy that is attempting to figure out >>the state of a subscription, you need to take care to figure out what's >>going on. In that case, yeah, Timer N is going to be of interest to you. >>But that's not something we need to specify -- it's actually very >>application-specific. > >The draft says that proxies no not need to support anything in addition to= 3261, so from that point of view you are correct. > >However, at the same time it talks about proxies adding Record-Route if th= ey are interested in the SUBs and NOTs, so I assumed that means that they a= re "allowed" to actually maintain subscription dialog state - in the same w= ay as they might maintain invite dialog state. >_______________________________________________ > >Even if a proxy is keeping subscription-state information, I don't see Tim= er N introducing a problem. The proxy sees all the SUBSCRIBEs and NOTIFYs = and their responses. Under 3265bis, the NOTIFYs, actually, the the *respon= ses* to the NOTIFYs show all of the=20 >subscription state. In particular, in seciton 4.1.2.4, I see: > > Until Timer N expires, several NOTIFY messages may arrive from > different destinations (see Section 4.4.1). Each of these messages > establish a new dialog and a new subscription. After the expiration > of Timer N, the subscriber SHOULD reject any such NOTIFY messages > that would otherwise establish a new dialog with a "481" response > code. Exactly, and that's why I think draft-ietf-sipcore-subnot-etags could cause= issues, because it allows the NOTIFY to be suppressed. Now, if the proxy d= oes not support that draft, and it doesn't receive a NOTIFY (since it has b= een suppressed) it could terminate the subsciption dialog state. Please also note that my issue is related to re/de-subscriptions, when all = dialogs already exist. Regards, Christer= From christer.holmberg@ericsson.com Tue Apr 6 13:07:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00823A67EF for ; Tue, 6 Apr 2010 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[AWL=1.748, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbAjeVOSnutT for ; Tue, 6 Apr 2010 13:07:22 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B3BEC3A677E for ; Tue, 6 Apr 2010 13:07:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-62-4bbb947572c1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 11.FA.23532.5749BBB4; Tue, 6 Apr 2010 22:07:18 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 6 Apr 2010 22:07:17 +0200 From: Christer Holmberg To: Brett Tate , Adam Roach , SIPCORE Date: Tue, 6 Apr 2010 22:04:58 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrU0bu62BCqas2pR6eucY/CrHCXVwA3VoTAAAVWUuw= Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> 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: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:07:23 -0000 Hi, Overload, that would "delay" the NOTIFY, is in fact one of the scenarios I = also had in mind, and got me thinking whether it would not simply be better= to maintain the pre-SUB dialog state, instead of terminating the dialog. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Bret= t Tate [brett@broadsoft.com] Sent: Tuesday, April 06, 2010 8:55 PM To: Adam Roach; SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] > If someone wants to raise an objection to the decision to > treat Timer N expiration the same way we treat SUBSCRIBE > transaction timeouts, I'm happy to engage in that discussion. The decision has an interesting interaction concerning overload. More spec= ifically if SUBSCRIBE received from device that the notifier still thinks i= s in overload, notifier will send 200 response but not the NOTIFY until lat= er. Or an overloaded middle box throttling some traffic might reject the N= OTIFY with 500/503 Retry-After. Concerning the overload interactions, is the decision concerning Timer N ex= piration acceptable since not allowing SUBSCRIBE 200 response to confirm th= e subscription creation? _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Tue Apr 6 13:10:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4EB3A6968 for ; Tue, 6 Apr 2010 13:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfsw+5Q-1r0B for ; Tue, 6 Apr 2010 13:10:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0B9CE3A68ED for ; Tue, 6 Apr 2010 13:10:00 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ab-4bbb951561ca Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CF.29.23740.5159BBB4; Tue, 6 Apr 2010 22:09:57 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 6 Apr 2010 22:09:56 +0200 From: Christer Holmberg To: "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Tue, 6 Apr 2010 22:08:04 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5w= Message-ID: References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:10:03 -0000 Hi Dale, >From my perspective, the main use-case is not to discover services, but to = discover capabilities in order to determine what services can be applied. The idea is also that the OPTIONS request would be sent prior to the INVITE= , to try to make sure that the returned contacts are actually available. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of WORL= EY, DALE R (DALE) [dworley@avaya.com] Sent: Tuesday, April 06, 2010 11:01 PM To: Salvatore Loreto; sipcore@ietf.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Salv= atore Loreto [salvatore.loreto@ericsson.com] Sent: Thursday, April 01, 2010 3:36 AM A good mechanism to discovery UA capabilities is essential to provide meani= ngful service: So I am in favor of pursuing the work, in particular the possibility to use a single OPTIONS request to retrieve t= he capabilities from ALL UAS(s) behind a forking proxy. _______________________________________ I think it is a misconception to use UA discovery to provide services. The= difficulty is that the set of available UAs for a given destination URI ch= anges unpredictably -- elements become inacessible (mobile phone out of ran= ge!), call routing changes due to time of day, etc. Instead, SIP provides = a remarkably effective system for selecting the best target of a call *at t= he moment the call is initiated* -- the caller declares his preferences, an= d the various intermediate elements combine the caller's desires with the r= outing information that they possess to forward the call closer to the pref= erred destination. As a developer, I've had to wrestle with this. In order to provide clean "= Is extension 1234 busy?" information, our "BLF agent" maintains subscriptio= ns to the "reg" event package for the AOR "sip:1234@example.com". For each= reported contact for the AOR, it maintains a dialog subscription to the co= ntact. Only by tracking the "reg" events can it keep track of the UAs avai= lable for that AOR. And even then, it is at the mercy of network failures. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From dworley@avaya.com Tue Apr 6 13:10:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486903A69D7 for ; Tue, 6 Apr 2010 13:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB6ybjUGO4Yc for ; Tue, 6 Apr 2010 13:10:25 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 5FCD13A69B0 for ; Tue, 6 Apr 2010 13:10:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="10496049" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 06 Apr 2010 16:10:21 -0400 X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="462072696" Received: from unknown (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Apr 2010 16:10:21 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Tue, 6 Apr 2010 16:10:20 -0400 From: "WORLEY, DALE R (DALE)" To: SIPCORE Date: Tue, 6 Apr 2010 16:10:20 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAxyw+++vy/SReaaIS3wIr8yYwFh/Zib Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: <4BB24B81.1050006@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:10:26 -0000 No matter what we do here, it is inevitable that the implementions of OPTIO= NS in the network will be very uneven. Uneven to the degree that it is unl= ikely that any SIP element will be able to depend on another SIP element's = OPTIONS response to automatically decide how to proceed. (Possibly with th= e exception of "If I send OPTIONS to an IP address and get a response, then= the SIP element at that IP address is functional.") The sipXecs system th= at I work on uses OPTIONS for liveness testing when we are manually monitor= ing a system, but the failure responses are handed over to a human for comp= rehension; forking et al. considers only responses to "real" requests. Within that context, if we want to define robust ways to probe the SIP netw= ork, we should define new protocol elements, preferably new methods, with c= arefully defined behaviors. On the other hand, I see benefit in defining not best practices (which we c= onsider should exclude all others) but "good practices" (guides to implemen= tors of OPTIONS) and especially "warnings to users" (caveats to users of OP= TIONS that it may not function as they desire). Dale From dworley@avaya.com Tue Apr 6 13:17:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF0F3A6A63 for ; Tue, 6 Apr 2010 13:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yy82LfT1Xbk for ; Tue, 6 Apr 2010 13:17:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 16A4028C117 for ; Tue, 6 Apr 2010 13:15:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="212349989" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Apr 2010 16:15:38 -0400 X-IronPort-AV: E=Sophos;i="4.51,374,1267419600"; d="scan'208";a="462074554" Received: from unknown (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Apr 2010 16:15:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Tue, 6 Apr 2010 16:15:38 -0400 From: "WORLEY, DALE R (DALE)" To: Christer Holmberg , Salvatore Loreto , "sipcore@ietf.org" Date: Tue, 6 Apr 2010 16:12:05 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAACPuvQ== Message-ID: References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:17:24 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] > From my perspective, the main use-case is not to discover services, > but to discover capabilities in order to determine what services can be a= pplied. That's very difficult, though, as you need to monitor when the contacts bec= ome available and unavailable. It's more reliable to attempt the call with the service a= ctive, and if it fails, fall back to attempting the call without the service. > The idea is also that the OPTIONS request would be sent prior to the INVI= TE, > to try to make sure that the returned contacts are actually available. Why not just send the INVITE and see if it fails? In the most common case = (success), that saves one round-trip. Dale From christer.holmberg@ericsson.com Tue Apr 6 13:58:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7C83A6A14 for ; Tue, 6 Apr 2010 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.006 X-Spam-Level: X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+ifWjlhoaAu for ; Tue, 6 Apr 2010 13:58:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 131313A69FC for ; Tue, 6 Apr 2010 13:58:50 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-a1-4bbba086a7a6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 01.8B.23740.680ABBB4; Tue, 6 Apr 2010 22:58:46 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 6 Apr 2010 22:58:46 +0200 From: Christer Holmberg To: "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Tue, 6 Apr 2010 22:55:04 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAACPuvQABgDy5 Message-ID: References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:58:52 -0000 Hi, >>From my perspective, the main use-case is not to discover services, >>but to discover capabilities in order to determine what services can be a= pplied. > >That's very difficult, though, as you need to monitor when the contacts be= come available >and unavailable. It's more reliable to attempt the call with the service = active, and if it fails, >fall back to attempting the call without the service. > >>The idea is also that the OPTIONS request would be sent prior to the INVI= TE, >>to try to make sure that the returned contacts are actually available. > >Why not just send the INVITE and see if it fails? In the most common case= (success), that saves one round-trip. Because that is crappy protocol design. And, the INVITE might trigger diffe= rent resources etc to be reserved, so you don't want to keep sending those. Please not that functionwise I am not trying to "enhance" OPTIONS as such -= I am simply trying to solve the forking case. Otherwise, if we think OPTIONS is useless, it should be removed from the pr= otocol... Regards, Christer= From christer.holmberg@ericsson.com Tue Apr 6 14:05:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E2A3A69D7 for ; Tue, 6 Apr 2010 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd38hoY5T3SL for ; Tue, 6 Apr 2010 14:05:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 311203A6A00 for ; Tue, 6 Apr 2010 14:05:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-5d-4bbba225adbd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DC.BD.23532.522ABBB4; Tue, 6 Apr 2010 23:05:41 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 6 Apr 2010 23:05:41 +0200 From: Christer Holmberg To: "WORLEY, DALE R (DALE)" , SIPCORE Date: Tue, 6 Apr 2010 23:05:40 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAxyw+++vy/SReaaIS3wIr8yYwFh/ZibAAICP7s= Message-ID: References: <4BB24B81.1050006@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:05:46 -0000 Hi, >No matter what we do here, it is inevitable that the implementions of OPTI= ONS in the network will be very uneven. Uneven to the degree that it is un= likely that any SIP element will be able to depend on another SIP element's= OPTIONS response to automatically decide=20 >how to proceed. (Possibly with the exception of "If I send OPTIONS to an = IP address and get a response, then the SIP element at that IP address is f= unctional.") I don't agree. There is much usable information you can receive in the OPTI= ONS response. >The sipXecs system that I work on uses OPTIONS for liveness testing when w= e are manually monitoring a system, but the failure responses are handed ov= er to a human for comprehension; forking et al. considers only responses to= "real" requests. So, maybe you can now start using OPTIONS for what it was intented to be us= ed for :) >Within that context, if we want to define robust ways to probe the SIP net= work, we should define new protocol elements, preferably new methods, with = carefully defined behaviors. Sure, if someone comes up with cases that OPTIONS can't be used for. At thi= s point I think we are only speculating, especially since OPTIONS hasn't be= en used very much for capability quering. And, the forking issue has at lea= st been one reason for that. >On the other hand, I see benefit in defining not best practices (which we = consider should exclude all others) but "good practices" (guides to impleme= ntors of OPTIONS) and especially "warnings to users" (caveats to users of O= PTIONS that it may not function as they=20 >desire). Whatever you wanna call it :) Regards, Christer= From pkyzivat@cisco.com Tue Apr 6 14:49:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1D928C110 for ; Tue, 6 Apr 2010 14:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17sCiJi041nY for ; Tue, 6 Apr 2010 14:49:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 97F1E3A68A4 for ; Tue, 6 Apr 2010 14:49:35 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACpJu0tAZnwN/2dsb2JhbACbOnGhUJkThQkE X-IronPort-AV: E=Sophos;i="4.51,374,1267401600"; d="scan'208";a="99453747" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2010 21:49:32 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o36LnWAl025109; Tue, 6 Apr 2010 21:49:32 GMT Message-ID: <4BBBAC6C.6070103@cisco.com> Date: Tue, 06 Apr 2010 17:49:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:49:37 -0000 [as individual] I'm having trouble understanding the issue here. I presume we are talking about *initial* subscribe here, not resubscribe. IIUC the case under discussion is: - Bob sends Alice some message - Alice responds with 503, retry-after because she is overloaded - Alice then sends Bob a SUBSCRIBE - Bob replies 200 to that - Bob delays the NOTIFY for the subscribe due to the retry-after timer - Timer-N expires so Alice considers the subscribe a failure. - Eventually Bob sends the NOTIFY, but Alice rejects it with 481 OR Bob realizes that Timer-N has expired and so does not send the NOTIFY. Is there *any* problem here? This seems to be working about as well as anyone might hope. What would you expect to happen? Thanks, Paul Christer Holmberg wrote: > Hi, > > Overload, that would "delay" the NOTIFY, is in fact one of the scenarios I also had in mind, and got me thinking whether it would not simply be better to maintain the pre-SUB dialog state, instead of terminating the dialog. > > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Brett Tate [brett@broadsoft.com] > Sent: Tuesday, April 06, 2010 8:55 PM > To: Adam Roach; SIPCORE > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] > >> If someone wants to raise an objection to the decision to >> treat Timer N expiration the same way we treat SUBSCRIBE >> transaction timeouts, I'm happy to engage in that discussion. > > The decision has an interesting interaction concerning overload. More specifically if SUBSCRIBE received from device that the notifier still thinks is in overload, notifier will send 200 response but not the NOTIFY until later. Or an overloaded middle box throttling some traffic might reject the NOTIFY with 500/503 Retry-After. > > Concerning the overload interactions, is the decision concerning Timer N expiration acceptable since not allowing SUBSCRIBE 200 response to confirm the subscription creation? > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Tue Apr 6 15:00:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11D03A68A5 for ; Tue, 6 Apr 2010 15:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4mtXZ2Q-bmK for ; Tue, 6 Apr 2010 15:00:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6313F3A683F for ; Tue, 6 Apr 2010 15:00:52 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36M0FXY076486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 17:00:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBBAEEF.3060802@nostrum.com> Date: Tue, 06 Apr 2010 17:00:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> In-Reply-To: <4BBBAC6C.6070103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:00:54 -0000 On 4/6/10 16:49, Apr 6, Paul Kyzivat wrote: > [as individual] > > I'm having trouble understanding the issue here. > I presume we are talking about *initial* subscribe here, not resubscribe. [also as individual] No, we know how initial subscribe behaves. The issue under discussion is: what happens if Timer N expires during a resubscription attempt? /a From brett@broadsoft.com Tue Apr 6 15:04:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB73E3A6933 for ; Tue, 6 Apr 2010 15:04:22 -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.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0qMO8zhXZQU for ; Tue, 6 Apr 2010 15:04:22 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 249103A68C5 for ; Tue, 6 Apr 2010 15:04:22 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 6 Apr 2010 15:04:17 -0700 From: Brett Tate To: Adam Roach , SIPCORE Date: Tue, 6 Apr 2010 15:03:29 -0700 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrV1IqISthvz2XgSiGC9BwTnQuksAAAArhg Message-ID: <747A6506A991724FB09B129B79D5FEB61480C55D13@EXMBXCLUS01.citservers.local> References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <4BBBAEEF.3060802@nostrum.com> In-Reply-To: <4BBBAEEF.3060802@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:04:23 -0000 :) My understanding is that both are being discussed since relevant to both= situations. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 06, 2010 6:00 PM > To: Paul Kyzivat > Cc: Christer Holmberg; Brett Tate; SIPCORE > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes > Posted] >=20 > On 4/6/10 16:49, Apr 6, Paul Kyzivat wrote: > > [as individual] > > > > I'm having trouble understanding the issue here. > > I presume we are talking about *initial* subscribe here, not > resubscribe. >=20 > [also as individual] >=20 > No, we know how initial subscribe behaves. The issue under discussion > is: what happens if Timer N expires during a resubscription attempt? >=20 > /a From adam@nostrum.com Tue Apr 6 15:44:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCB13A69ED for ; Tue, 6 Apr 2010 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM90cJDpkzkl for ; Tue, 6 Apr 2010 15:44:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 160253A68E9 for ; Tue, 6 Apr 2010 15:44:53 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36Milhg079743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 17:44:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBBB95F.9000805@nostrum.com> Date: Tue, 06 Apr 2010 17:44:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brett Tate References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <4BBBAEEF.3060802@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480C55D13@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C55D13@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:44:59 -0000 [as individual] Ah, okay. For initial subscriptions: the problem that Timer N solves is a very real one. I think it is reasonable to trade-off the ambiguity around subscription establishment for the extremely rare failure in overload conditions. IMHO, the failure to timer supervise the period between an initial SUBSCRIBE and an initial NOTIFY was the largest flaw in RFC 3265 when we published it. It's worth mentioning in the bis draft that there can be circumstances -- notably, related to congestion conditions -- that might lead to these kinds of failures. I'll add something to this effect in the next draft. But I think removing Timer N would be a huge step backwards. Regarding the behavior of Timer N on a *re*subscribe: I don't strongly care one way or another. But it needs to be unambiguous and documented. I'm happy to say "Timer N expiration on a resubscribe destroys the subscription." I'm also happy to say "Timer N isn't even run for resubscriptions." I'm slightly biased towards the first case, since the situation clearly means something has gone wrong in the network. Your overload scenario is an interesting one, and we should certainly consider how the system should behave in this case. On first blush, it seems to me that if the network is so congested that it can't get the NOTIFY through within a 32-second window, everyone might benefit from the subscription going away anyway. /a On 4/6/10 17:03, Apr 6, Brett Tate wrote: > :) My understanding is that both are being discussed since relevant to both situations. > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, April 06, 2010 6:00 PM >> To: Paul Kyzivat >> Cc: Christer Holmberg; Brett Tate; SIPCORE >> Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes >> Posted] >> >> On 4/6/10 16:49, Apr 6, Paul Kyzivat wrote: >> >>> [as individual] >>> >>> I'm having trouble understanding the issue here. >>> I presume we are talking about *initial* subscribe here, not >>> >> resubscribe. >> >> [also as individual] >> >> No, we know how initial subscribe behaves. The issue under discussion >> is: what happens if Timer N expires during a resubscription attempt? >> >> /a >> From brett@broadsoft.com Tue Apr 6 15:47:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CDA3A6A21 for ; Tue, 6 Apr 2010 15:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xltE-CfnsqWD for ; Tue, 6 Apr 2010 15:47:12 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 4D8BE3A69B0 for ; Tue, 6 Apr 2010 15:47:12 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 6 Apr 2010 15:47:10 -0700 From: Brett Tate To: Paul Kyzivat , SIPCORE Date: Tue, 6 Apr 2010 15:46:22 -0700 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrV0wwiUvsXw+qfS/2OfEuV4byxSwAAEWRw Message-ID: <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> In-Reply-To: <4BBBAC6C.6070103@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 Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:47:13 -0000 > Is there *any* problem here? This seems to be working about=20 > as well as anyone might hope.=20 It works okay excluding the non backward compatibility with RFC 3265 (conce= rning SUBSCRIBE's 2xx response impacts) and continuing to uselessly repeat = the Timer N expiration's subscription teardown process until related overlo= ad issue resolved. > What would you expect to happen? Potentially allow the SUBSCRIBE's 200 response to create the subscription/d= ialog similar to RFC 3265. =20 The draft's Timer N (and lack of related NOTIFY) text is potentially worded= in a way which does not require the tear down (and non creation) of subscr= iption. From pkyzivat@cisco.com Tue Apr 6 16:20:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04C683A68AE for ; Tue, 6 Apr 2010 16:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgivweoUyjeQ for ; Tue, 6 Apr 2010 16:20:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A9DA03A6A4A for ; Tue, 6 Apr 2010 16:20:47 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAENeu0tAZnwN/2dsb2JhbACbO3GhEJkShQkE X-IronPort-AV: E=Sophos;i="4.51,374,1267401600"; d="scan'208";a="99471996" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2010 23:20:43 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o36NKhT0017468; Tue, 6 Apr 2010 23:20:43 GMT Message-ID: <4BBBC1CB.4050501@cisco.com> Date: Tue, 06 Apr 2010 19:20:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:20:57 -0000 Brett Tate wrote: >> Is there *any* problem here? This seems to be working about >> as well as anyone might hope. > > It works okay excluding the non backward compatibility with RFC 3265 (concerning SUBSCRIBE's 2xx response impacts) and continuing to uselessly repeat the Timer N expiration's subscription teardown process until related overload issue resolved. > > >> What would you expect to happen? > > Potentially allow the SUBSCRIBE's 200 response to create the subscription/dialog similar to RFC 3265. Then what would happen in a polling subscribe (Expires:0) if the 200 is received and the NOTIFY is not received? How long should you wait before giving up? ISTM you still need timer-N to tell you it failed, so you can give up waiting. Thanks, Paul From adam@nostrum.com Tue Apr 6 16:31:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3E93A68A7 for ; Tue, 6 Apr 2010 16:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogQtn0o4WdAN for ; Tue, 6 Apr 2010 16:31:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 39DD93A67E1 for ; Tue, 6 Apr 2010 16:31:30 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36NVMlp083131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 18:31:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBBC44A.30103@nostrum.com> Date: Tue, 06 Apr 2010 18:31:22 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: , <4BB9FEB2.3030400@nostrum.com>, , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:31:32 -0000 On 4/6/10 15:02, Apr 6, Christer Holmberg wrote: > Hi, > > >>> In any case, proxies don't inherently care about subscription state. If >>> you're doing something in your proxy that is attempting to figure out >>> the state of a subscription, you need to take care to figure out what's >>> going on. In that case, yeah, Timer N is going to be of interest to you. >>> But that's not something we need to specify -- it's actually very >>> application-specific. >>> >> The draft says that proxies no not need to support anything in addition to 3261, so from that point of view you are correct. >> >> However, at the same time it talks about proxies adding Record-Route if they are interested in the SUBs and NOTs, so I assumed that means that they are "allowed" to actually maintain subscription dialog state - in the same way as they might maintain invite dialog state. >> _______________________________________________ >> >> Even if a proxy is keeping subscription-state information, I don't see Timer N introducing a problem. The proxy sees all the SUBSCRIBEs and NOTIFYs and their responses. Under 3265bis, the NOTIFYs, actually, the the *responses* to the NOTIFYs show all of the >> subscription state. In particular, in seciton 4.1.2.4, I see: >> >> Until Timer N expires, several NOTIFY messages may arrive from >> different destinations (see Section 4.4.1). Each of these messages >> establish a new dialog and a new subscription. After the expiration >> of Timer N, the subscriber SHOULD reject any such NOTIFY messages >> that would otherwise establish a new dialog with a "481" response >> code. >> > Exactly, and that's why I think draft-ietf-sipcore-subnot-etags could cause issues, because it allows the NOTIFY to be suppressed. You're conflating *initial* NOTIFYs with *refresh* NOTIFYs. The subnot-etags document explicitly does not allow suppression of initial NOTIFY messages. They are critical to establishing a dialog. The text Dale cites relates exclusively to handling of *initial* NOTIFYs. It is unrelated to the kinds of NOTIFY messages that subnot-etags is allows to suppress. /a From adam@nostrum.com Tue Apr 6 16:37:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6498E3A67E1 for ; Tue, 6 Apr 2010 16:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-lp+DJyKrqs for ; Tue, 6 Apr 2010 16:37:40 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2E1BF3A69ED for ; Tue, 6 Apr 2010 16:37:38 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36Nag65083492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 18:36:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBBC58A.10407@nostrum.com> Date: Tue, 06 Apr 2010 18:36:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Brett Tate References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:37:41 -0000 On 4/6/10 17:46, Apr 6, Brett Tate wrote: >> Is there *any* problem here? This seems to be working about >> as well as anyone might hope. >> > It works okay excluding the non backward compatibility with RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)... I don't think it's accurate to characterize the change as non-backwards-compatible. The only wire-visible behavior that one could conceivable observe is that a subscriber might make a different decision about which subscription to accept if the SUBSCRIBE forks and the subscriber wants only one subscription. What we *do* gain is a simplification for implementors. Because the behavior of establishing the dialog when a NOTIFY shows up (instead of "the first of a 2xx or a NOTIFY) is much easier to code, people will make fewer mistakes, and have fewer bugs. But you'd be hard pressed to see a difference on the wire. > The draft's Timer N (and lack of related NOTIFY) text is potentially > worded in a way which does not require the tear down (and non > creation) of subscription. Tear-down of existing dialogs is still an open issue, sure. I don't get where you see any wiggle room in what happens if Timer N fires for the first SUBSCRIBE/NOTIFY exchange. /a From gao.yang2@zte.com.cn Tue Apr 6 20:41:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAAAD3A68A3 for ; Tue, 6 Apr 2010 20:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.661 X-Spam-Level: X-Spam-Status: No, score=-100.661 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UIHCsKfBrsc for ; Tue, 6 Apr 2010 20:41:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 75FC23A6827 for ; Tue, 6 Apr 2010 20:41:30 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Wed, 7 Apr 2010 11:39:21 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 62186.4786316380; Wed, 7 Apr 2010 11:38:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o373fCsi018369; Wed, 7 Apr 2010 11:41:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org, Gonzalo.Camarillo@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Apr 2010 11:39:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-07 11:41:08, Serialize complete at 2010-04-07 11:41:08 Content-Type: multipart/alternative; boundary="=_alternative 00143AA1482576FE_=" X-MAIL: mse2.zte.com.cn o373fCsi018369 Subject: [sipcore] About O/A rules in RFC3261: X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 03:41:33 -0000 This is a multipart message in MIME format. --=_alternative 00143AA1482576FE_= Content-Type: text/plain; charset="US-ASCII" Hi, While considering one problem in our productions' interoperability testing, I re-read some parts of offeranswer draft and correlative part of RFC3261. And I find a potential description problem in RFC3261 incidentally. //correlative part of RFC3261 o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. As the text allow UAS send SDP before the final answer, the first session description UAC receives can not be treated as answer in such cases. And the current text defines that UAC MUST ignore any SDP in subsequent responses to the initial INVITE. whick may make the UAC ignore the real answer in some case. I think the description should be: The UAC MUST treat the first session description which is in a reliable non-failure message it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. And if the problem is exist, where should be the correction's location? I think draft-ietf-sipcore-reinvite-03 is not proper, as it aims for Re-INVITE. And a new draft for such tiny *potential* problem is also not proper. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00143AA1482576FE_= Content-Type: text/html; charset="US-ASCII"
Hi,

While considering one problem in our productions' interoperability testing, I re-read some parts of offeranswer draft and correlative part of RFC3261. And I find a potential description problem in RFC3261 incidentally.

//correlative part of RFC3261
o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

As the text allow UAS send SDP before the final answer, the first session description UAC receives can not be treated as answer in such cases. And the current text defines that UAC MUST ignore any SDP in subsequent responses to the initial INVITE. whick may make the UAC ignore the real answer in some case.

I think the description should be:
The UAC MUST treat the first session description which is in a reliable non-failure message it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.

And if the problem is exist, where should be the correction's location?
I think draft-ietf-sipcore-reinvite-03 is not proper, as it aims for Re-INVITE. And a new draft for such tiny *potential* problem is also not proper.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00143AA1482576FE_=-- From christer.holmberg@ericsson.com Tue Apr 6 22:33:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E483A6A7A for ; Tue, 6 Apr 2010 22:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzryqtR4wm3H for ; Tue, 6 Apr 2010 22:33:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 01E423A6862 for ; Tue, 6 Apr 2010 22:33:44 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9d-4bbc1933ca46 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 99.63.23740.3391CBB4; Wed, 7 Apr 2010 07:33:39 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 07:33:39 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 7 Apr 2010 07:33:39 +0200 From: Christer Holmberg To: Adam Roach Date: Wed, 7 Apr 2010 07:33:35 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrV4UddN0IsyN9jSu+5AxKBaU89WAAMjpCg Message-ID: References: , <4BB9FEB2.3030400@nostrum.com>, , <4BBBC44A.30103@nostrum.com> In-Reply-To: <4BBBC44A.30103@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 05:33:54 -0000 Hi,=20 >>>>In any case, proxies don't inherently care about subscription state.=20 >>>>If you're doing something in your proxy that is attempting to figure=20 >>>>out the state of a subscription, you need to take care to=20 >>>>figure out what's going on. In that case, yeah, Timer N is going to=20 >>>>be of interest to you. >>>>But that's not something we need to specify -- it's actually very=20 >>>>application-specific. >>>> =20 >>>The draft says that proxies no not need to support=20 >>>anything in addition to 3261, so from that point of view you=20 >>>are correct. >>> >>>However, at the same time it talks about proxies adding=20 >>>Record-Route if they are interested in the SUBs and NOTs, so=20 >>>I assumed that means that they are "allowed" to actually=20 >>>maintain subscription dialog state - in the same way as they=20 >>>might maintain invite dialog state. >>> _______________________________________________ >>> >>> Even if a proxy is keeping subscription-state information, I don't=20 >>> see Timer N introducing a problem. The proxy sees all the=20 >>> SUBSCRIBEs and NOTIFYs and their responses. Under 3265bis,=20 >>> the NOTIFYs, actually, the the *responses* to the NOTIFYs=20 >>> show all of the subscription state. In particular, in=20 >>> seciton 4.1.2.4, I see: >>> >>> Until Timer N expires, several NOTIFY messages may arrive from >>> different destinations (see Section 4.4.1). Each of these messages >>> establish a new dialog and a new subscription. After the expiration >>> of Timer N, the subscriber SHOULD reject any such NOTIFY messages >>> that would otherwise establish a new dialog with a "481" response >>> code. >>> =20 >>Exactly, and that's why I think draft-ietf-sipcore-subnot-etags could cau= se issues, because=20 >>it allows the NOTIFY to be suppressed. >=20 >You're conflating *initial* NOTIFYs with *refresh* NOTIFYs. >=20 >The subnot-etags document explicitly does not allow=20 >suppression of initial NOTIFY messages. They are critical to=20 >establishing a dialog. > >The text Dale cites relates exclusively to handling of=20 >*initial* NOTIFYs. It is unrelated to the kinds of NOTIFY=20 >messages that subnot-etags is allows to suppress. Correct. I've been trying to say that, but I appologise if it didn't apply = to Dale's case. Regards, Christer From christer.holmberg@ericsson.com Tue Apr 6 23:20:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBA63A6807 for ; Tue, 6 Apr 2010 23:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=1.510, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxZ3TtXYLvKr for ; Tue, 6 Apr 2010 23:20:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id ACDD43A66B4 for ; Tue, 6 Apr 2010 23:20:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-ff-4bbc24377ad7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D2.A9.23532.7342CBB4; Wed, 7 Apr 2010 08:20:39 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 08:20:39 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 7 Apr 2010 08:20:39 +0200 From: Christer Holmberg To: Adam Roach , Brett Tate Date: Wed, 7 Apr 2010 08:20:38 +0200 Thread-Topic: Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] Thread-Index: AcrV4iet/Jl04c79TTyKI1KBY3+fSQAN9L+Q Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: <4BBBC58A.10407@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:20:48 -0000 Hi, I haven't double checked whether it is said in 3265bis, but we also need to= make clear whether it is the NOTIFY request, or the NOT 200 response, that= "acknowledges" the (re-)subscription. Because, a NOTIFY request can also be rejected (e.g. due to overload), so i= n order to avoid sub state unsynch every entity in the path needs to know w= hat a NOT non-200 response means. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 7. huhtikuuta 2010 2:37 > To: Brett Tate > Cc: SIPCORE > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was=20 > Minutes Posted] >=20 > On 4/6/10 17:46, Apr 6, Brett Tate wrote: > >> Is there *any* problem here? This seems to be working=20 > about as well=20 > >> as anyone might hope. > >> =20 > > It works okay excluding the non backward compatibility with=20 > RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)... >=20 > I don't think it's accurate to characterize the change as=20 > non-backwards-compatible. The only wire-visible behavior that=20 > one could conceivable observe is that a subscriber might make=20 > a different decision about which subscription to accept if=20 > the SUBSCRIBE forks and the subscriber wants only one subscription. >=20 > What we *do* gain is a simplification for implementors.=20 > Because the behavior of establishing the dialog when a NOTIFY=20 > shows up (instead of "the first of a 2xx or a NOTIFY) is much=20 > easier to code, people will make fewer mistakes, and have=20 > fewer bugs. But you'd be hard pressed to see a difference on the wire. >=20 > > The draft's Timer N (and lack of related NOTIFY) text is=20 > potentially=20 > > worded in a way which does not require the tear down (and non > > creation) of subscription. >=20 > Tear-down of existing dialogs is still an open issue, sure. I=20 > don't get where you see any wiggle room in what happens if=20 > Timer N fires for the first SUBSCRIBE/NOTIFY exchange. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Apr 6 23:27:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EBB3A66B4 for ; Tue, 6 Apr 2010 23:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[AWL=1.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRsXCYUbfXyk for ; Tue, 6 Apr 2010 23:27:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C2E333A6807 for ; Tue, 6 Apr 2010 23:27:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-8f-4bbc25cb8f08 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 95.6A.23532.BC52CBB4; Wed, 7 Apr 2010 08:27:24 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 7 Apr 2010 08:27:23 +0200 From: Christer Holmberg To: Adam Roach , Brett Tate Date: Wed, 7 Apr 2010 08:27:22 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrV4iet/Jl04c79TTyKI1KBY3+fSQAOLxGQ Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: <4BBBC58A.10407@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:27:29 -0000 Hi,=20 >>>Is there *any* problem here? This seems to be working about as well=20 >>>as anyone might hope. >>> =20 >>It works okay excluding the non backward compatibility with RFC 3265 (con= cerning SUBSCRIBE's 2xx response impacts)... >=20 >I don't think it's accurate to characterize the change as=20 >non-backwards-compatible. The only wire-visible behavior that=20 >one could conceivable observe is that a subscriber might make=20 >a different decision about which subscription to accept if=20 >the SUBSCRIBE forks and the subscriber wants only one subscription. >=20 >What we *do* gain is a simplification for implementors.=20 >Because the behavior of establishing the dialog when a NOTIFY=20 >shows up (instead of "the first of a 2xx or a NOTIFY) is much=20 >easier to code, people will make fewer mistakes, and have=20 >fewer bugs. But you'd be hard pressed to see a difference on the wire. I agree with Adam. Of course, for resubscriptions we don't have the forking issue, but I still= think we should have the same behavior, ie the NOTIFY acknowledges the res= ub. ...and, again, that is why I have an issue with allowing the suppression of= NOTIFYs. It's not a problem for endpoints, but for stateful intermediaries= (proxies ARE allowed to Record-Route SUB requests, so) >>The draft's Timer N (and lack of related NOTIFY) text is potentially=20 >>worded in a way which does not require the tear down (and non >>creation) of subscription. >=20 >Tear-down of existing dialogs is still an open issue, sure. I=20 >don't get where you see any wiggle room in what happens if=20 >Timer N fires for the first SUBSCRIBE/NOTIFY exchange. For the initial SUB/NOT, I think that tearing down the dialog is the only t= hing you can do. Regards, Christer From john.elwell@siemens-enterprise.com Tue Apr 6 23:32:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C333A67FF for ; Tue, 6 Apr 2010 23:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyRQX7is9gC2 for ; Tue, 6 Apr 2010 23:32:04 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7B5F33A68A8 for ; Tue, 6 Apr 2010 23:32:04 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1463220; Wed, 7 Apr 2010 08:32:00 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4F18723F0278; Wed, 7 Apr 2010 08:31:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 7 Apr 2010 08:31:59 +0200 From: "Elwell, John" To: "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 08:31:57 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3ABXHvOA= Message-ID: References: <4BB24B81.1050006@nostrum.com>,<4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:32:06 -0000 I agree with Dale. What happens to an OPTIONS request will not necessarily = be reflected when an INVITE request is sent shortly afterwards. As a furthe= r examples, in contact centres, it is usual to distribute calls cyclically = or randomly between qualified and available agents. Sending an INVITE reque= st to a UA determined by responses to an OPTIONS request would break that m= odel - the issuer of the OPTIONS and INVITE requests cannot be expected to = obey the same rotation rules as the domain proxy that routes INVITE request= s. Issuing an INVITE request to the AOR is unlikely to result in it being d= elivered to the UA that might be expected from analysis of responses to an = OPTIONS request. I don't think we should work on trying to make OPTIONS work for this purpos= e. If we really need to do anything with OPTIONS, we should just issue warn= ings about its unsuitability for purposes other than a simple ping. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of WORLEY, DALE R (DALE) > Sent: 06 April 2010 21:01 > To: Salvatore Loreto; sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On=20 > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com] > Sent: Thursday, April 01, 2010 3:36 AM >=20 > A good mechanism to discovery UA capabilities is essential to=20 > provide meaningful service: > So I am in favor of pursuing the work, > in particular the possibility to use a single OPTIONS request=20 > to retrieve the capabilities from ALL UAS(s) behind a forking proxy. > _______________________________________ >=20 > I think it is a misconception to use UA discovery to provide=20 > services. The difficulty is that the set of available UAs=20 > for a given destination URI changes unpredictably -- elements=20 > become inacessible (mobile phone out of range!), call routing=20 > changes due to time of day, etc. Instead, SIP provides a=20 > remarkably effective system for selecting the best target of=20 > a call *at the moment the call is initiated* -- the caller=20 > declares his preferences, and the various intermediate=20 > elements combine the caller's desires with the routing=20 > information that they possess to forward the call closer to=20 > the preferred destination. >=20 > As a developer, I've had to wrestle with this. In order to=20 > provide clean "Is extension 1234 busy?" information, our "BLF=20 > agent" maintains subscriptions to the "reg" event package for=20 > the AOR "sip:1234@example.com". For each reported contact=20 > for the AOR, it maintains a dialog subscription to the=20 > contact. Only by tracking the "reg" events can it keep track=20 > of the UAs available for that AOR. And even then, it is at=20 > the mercy of network failures. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Apr 6 23:37:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5043A6A84 for ; Tue, 6 Apr 2010 23:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=1.398, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PboiWXMtNiEn for ; Tue, 6 Apr 2010 23:37:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B57973A6A83 for ; Tue, 6 Apr 2010 23:37:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-09-4bbc282a6561 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F5.AB.23532.A282CBB4; Wed, 7 Apr 2010 08:37:30 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 08:37:30 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 7 Apr 2010 08:37:30 +0200 From: Christer Holmberg To: "Elwell, John" , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 08:37:29 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3ABXHvOAAAIgdEA== Message-ID: References: <4BB24B81.1050006@nostrum.com>,<4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:37:37 -0000 Hi,=20 >I agree with Dale. What happens to an OPTIONS request will=20 >not necessarily be reflected when an INVITE request is sent=20 >shortly afterwards. As a further examples, in contact=20 >centres, it is usual to distribute calls cyclically or=20 >randomly between qualified and available agents. Sure, there are cases when it may not be feasible. >Sending an INVITE request to a UA determined by responses to an OPTIONS=20 >request would break that model - the issuer of the OPTIONS=20 >and INVITE requests cannot be expected to obey the same=20 >rotation rules as the domain proxy that routes INVITE=20 >requests. Issuing an INVITE request to the AOR is unlikely to=20 >result in it being delivered to the UA that might be expected=20 >from analysis of responses to an OPTIONS request. I think the main use-case is when you want to contact end users.=20 >I don't think we should work on trying to make OPTIONS work=20 >for this purpose. If we really need to do anything with=20 >OPTIONS, we should just issue warnings about its=20 >unsuitability for purposes other than a simple ping. Again, protocolwise we don't need to do anything for OPTIONS 3xx, because w= e already have the tools to do it :) The question is whether it would be good to document it. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of WORLEY, DALE R (DALE) > > Sent: 06 April 2010 21:01 > > To: Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > >=20 > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org]=20 > On Behalf Of=20 > > Salvatore Loreto [salvatore.loreto@ericsson.com] > > Sent: Thursday, April 01, 2010 3:36 AM > >=20 > > A good mechanism to discovery UA capabilities is essential=20 > to provide=20 > > meaningful service: > > So I am in favor of pursuing the work, in particular the=20 > possibility=20 > > to use a single OPTIONS request to retrieve the=20 > capabilities from ALL=20 > > UAS(s) behind a forking proxy. > > _______________________________________ > >=20 > > I think it is a misconception to use UA discovery to=20 > provide services. =20 > > The difficulty is that the set of available UAs for a given=20 > > destination URI changes unpredictably -- elements become=20 > inacessible=20 > > (mobile phone out of range!), call routing changes due to=20 > time of day,=20 > > etc. Instead, SIP provides a remarkably effective system for=20 > > selecting the best target of a call *at the moment the call is=20 > > initiated* -- the caller declares his preferences, and the various=20 > > intermediate elements combine the caller's desires with the routing=20 > > information that they possess to forward the call closer to the=20 > > preferred destination. > >=20 > > As a developer, I've had to wrestle with this. In order to provide=20 > > clean "Is extension 1234 busy?" information, our "BLF=20 > agent" maintains=20 > > subscriptions to the "reg" event package for the AOR=20 > > "sip:1234@example.com". For each reported contact for the AOR, it=20 > > maintains a dialog subscription to the contact. Only by=20 > tracking the=20 > > "reg" events can it keep track of the UAs available for=20 > that AOR. And=20 > > even then, it is at the mercy of network failures. > >=20 > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Tue Apr 6 23:56:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBEC3A67FB for ; Tue, 6 Apr 2010 23:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYMRuRX3GKos for ; Tue, 6 Apr 2010 23:56:03 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BD9B83A6774 for ; Tue, 6 Apr 2010 23:56:02 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1464748; Wed, 7 Apr 2010 08:55:59 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 4AE0D1EB82AB; Wed, 7 Apr 2010 08:55:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 7 Apr 2010 08:55:59 +0200 From: "Elwell, John" To: Christer Holmberg , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 08:55:57 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3ABXHvOAAAIgdEAAAhuww Message-ID: References: <4BB24B81.1050006@nostrum.com>,<4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:56:04 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 07 April 2010 07:37 > To: Elwell, John; WORLEY, DALE R (DALE); Salvatore Loreto;=20 > sipcore@ietf.org > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > Hi,=20 >=20 > >I agree with Dale. What happens to an OPTIONS request will=20 > >not necessarily be reflected when an INVITE request is sent=20 > >shortly afterwards. As a further examples, in contact=20 > >centres, it is usual to distribute calls cyclically or=20 > >randomly between qualified and available agents. >=20 > Sure, there are cases when it may not be feasible. >=20 > >Sending an INVITE request to a UA determined by responses to=20 > an OPTIONS=20 > >request would break that model - the issuer of the OPTIONS=20 > >and INVITE requests cannot be expected to obey the same=20 > >rotation rules as the domain proxy that routes INVITE=20 > >requests. Issuing an INVITE request to the AOR is unlikely to=20 > >result in it being delivered to the UA that might be expected=20 > >from analysis of responses to an OPTIONS request. >=20 > I think the main use-case is when you want to contact end users.=20 [JRE] A contact centre agent is indeed an end user. >=20 > >I don't think we should work on trying to make OPTIONS work=20 > >for this purpose. If we really need to do anything with=20 > >OPTIONS, we should just issue warnings about its=20 > >unsuitability for purposes other than a simple ping. >=20 > Again, protocolwise we don't need to do anything for OPTIONS=20 > 3xx, because we already have the tools to do it :) [JRE] Yes, but a forking proxy at present probably doesn't issue 3xx respon= ses, so for the mechanism to be usable we would need to mandate this behavi= our. Then we would still be left with legacy forking proxies that don't sup= port the newly mandated behaviour, so do we have to specify an option tag a= nd Proxy-Require? I am not convinced we already have the tools. >=20 > The question is whether it would be good to document it. [JRE] As somebody else pointed out, if you want to obtain OPTIONS responses= from individual UAs registered against an AOR, you can use the registratio= n event package to identify them and send OPTIONS requests to them individu= ally. If we are going to document a practice (which I do not necessarily ag= ree with), we should at least consider alternatives. John >=20 > Regards, >=20 > Christer >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of WORLEY,=20 > DALE R (DALE) > > > Sent: 06 April 2010 21:01 > > > To: Salvatore Loreto; sipcore@ietf.org > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > >=20 > > > ________________________________________ > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org]=20 > > On Behalf Of=20 > > > Salvatore Loreto [salvatore.loreto@ericsson.com] > > > Sent: Thursday, April 01, 2010 3:36 AM > > >=20 > > > A good mechanism to discovery UA capabilities is essential=20 > > to provide=20 > > > meaningful service: > > > So I am in favor of pursuing the work, in particular the=20 > > possibility=20 > > > to use a single OPTIONS request to retrieve the=20 > > capabilities from ALL=20 > > > UAS(s) behind a forking proxy. > > > _______________________________________ > > >=20 > > > I think it is a misconception to use UA discovery to=20 > > provide services. =20 > > > The difficulty is that the set of available UAs for a given=20 > > > destination URI changes unpredictably -- elements become=20 > > inacessible=20 > > > (mobile phone out of range!), call routing changes due to=20 > > time of day,=20 > > > etc. Instead, SIP provides a remarkably effective system for=20 > > > selecting the best target of a call *at the moment the call is=20 > > > initiated* -- the caller declares his preferences, and=20 > the various=20 > > > intermediate elements combine the caller's desires with=20 > the routing=20 > > > information that they possess to forward the call closer to the=20 > > > preferred destination. > > >=20 > > > As a developer, I've had to wrestle with this. In order=20 > to provide=20 > > > clean "Is extension 1234 busy?" information, our "BLF=20 > > agent" maintains=20 > > > subscriptions to the "reg" event package for the AOR=20 > > > "sip:1234@example.com". For each reported contact for=20 > the AOR, it=20 > > > maintains a dialog subscription to the contact. Only by=20 > > tracking the=20 > > > "reg" events can it keep track of the UAs available for=20 > > that AOR. And=20 > > > even then, it is at the mercy of network failures. > > >=20 > > > Dale > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From christer.holmberg@ericsson.com Wed Apr 7 00:01:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBEC3A684C for ; Wed, 7 Apr 2010 00:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVoKFFpvk7dO for ; Wed, 7 Apr 2010 00:01:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 410BC3A6774 for ; Wed, 7 Apr 2010 00:01:54 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-f8-4bbc2dde6c0a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id E2.BC.23740.EDD2CBB4; Wed, 7 Apr 2010 09:01:50 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 7 Apr 2010 09:01:50 +0200 From: Christer Holmberg To: "Elwell, John" , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 09:01:48 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3ABXHvOAAAIgdEAAAhuwwAABKF3A= Message-ID: References: <4BB24B81.1050006@nostrum.com>,<4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:01:55 -0000 Hi,=20 >>I think the main use-case is when you want to contact end users.=20 >[JRE] A contact centre agent is indeed an end user. Yes, but not the same kind of end user :) >>Again, protocolwise we don't need to do anything for OPTIONS 3xx,=20 >>because we already have the tools to do it :) >[JRE] Yes, but a forking proxy at present probably doesn't=20 >issue 3xx responses, so for the mechanism to be usable we=20 >would need to mandate this behaviour. Then we would still be=20 >left with legacy forking proxies that don't support the newly=20 >mandated behaviour, so do we have to specify an option tag=20 >and Proxy-Require? I am not convinced we already have the tools. We have the Request-Disposition "redirect" feature tag. No, I know that not all proxies support it, but the tool exists. There is NO mechanism which will ensure that it always works. If the remote= end doesn't support it - it won't work. >>The question is whether it would be good to document it. >[JRE] As somebody else pointed out, if you want to obtain=20 >OPTIONS responses from individual UAs registered against an=20 >AOR, you can use the registration event package to identify=20 >them and send OPTIONS requests to them individually. If we=20 >are going to document a practice (which I do not necessarily=20 >agree with), we should at least consider alternatives. I have no problem to also look at other solutions, and we can even allow di= fferent alternatives. It would be good to document the pros and cons of eac= h alternatives, and people can then choose what to use based on their use-c= ases and requirements etc. And, keep in mind that the event package solution requires support of the e= vent package, so it won't always work either :) Regards, Christer > > Regards, > >=20 > > Christer > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of WORLEY, > > DALE R (DALE) > > > > Sent: 06 April 2010 21:01 > > > > To: Salvatore Loreto; sipcore@ietf.org > > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > >=20 > > > > ________________________________________ > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] > > > On Behalf Of > > > > Salvatore Loreto [salvatore.loreto@ericsson.com] > > > > Sent: Thursday, April 01, 2010 3:36 AM > > > >=20 > > > > A good mechanism to discovery UA capabilities is essential > > > to provide > > > > meaningful service: > > > > So I am in favor of pursuing the work, in particular the > > > possibility > > > > to use a single OPTIONS request to retrieve the > > > capabilities from ALL > > > > UAS(s) behind a forking proxy. > > > > _______________________________________ > > > >=20 > > > > I think it is a misconception to use UA discovery to > > > provide services. =20 > > > > The difficulty is that the set of available UAs for a given=20 > > > > destination URI changes unpredictably -- elements become > > > inacessible > > > > (mobile phone out of range!), call routing changes due to > > > time of day, > > > > etc. Instead, SIP provides a remarkably effective system for=20 > > > > selecting the best target of a call *at the moment the call is > > > > initiated* -- the caller declares his preferences, and > > the various > > > > intermediate elements combine the caller's desires with > > the routing > > > > information that they possess to forward the call closer to the=20 > > > > preferred destination. > > > >=20 > > > > As a developer, I've had to wrestle with this. In order > > to provide > > > > clean "Is extension 1234 busy?" information, our "BLF > > > agent" maintains > > > > subscriptions to the "reg" event package for the AOR=20 > > > > "sip:1234@example.com". For each reported contact for > > the AOR, it > > > > maintains a dialog subscription to the contact. Only by > > > tracking the > > > > "reg" events can it keep track of the UAs available for > > > that AOR. And > > > > even then, it is at the mercy of network failures. > > > >=20 > > > > Dale > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > >=20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > = From john.elwell@siemens-enterprise.com Wed Apr 7 00:09:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836F73A6774 for ; Wed, 7 Apr 2010 00:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCEb0SBLA4ec for ; Wed, 7 Apr 2010 00:09:50 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 749CB3A67FB for ; Wed, 7 Apr 2010 00:09:49 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1464034; Wed, 7 Apr 2010 09:09:46 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4496023F0278; Wed, 7 Apr 2010 09:09:46 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 7 Apr 2010 09:09:46 +0200 From: "Elwell, John" To: Christer Holmberg , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 09:09:44 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3ABXHvOAAAIgdEAAAhuwwAABKF3AAAFB6kA== Message-ID: References: <4BB24B81.1050006@nostrum.com>,<4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:09:53 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 07 April 2010 08:02 > To: Elwell, John; WORLEY, DALE R (DALE); Salvatore Loreto;=20 > sipcore@ietf.org > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > Hi,=20 >=20 > >>I think the main use-case is when you want to contact end users.=20 > >[JRE] A contact centre agent is indeed an end user. >=20 > Yes, but not the same kind of end user :) [JRE] So what kind of end user is within scope of this work? How does the i= ssuer of OPTIONS/INVITE requests know whether he is targeting the right sor= t of end user for the mechanism to work? I think it is dangerous to base me= chanisms on assumptions about particular types of end user. John From ietf.hanserik@gmail.com Wed Apr 7 00:24:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81EC3A6891 for ; Wed, 7 Apr 2010 00:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRRSVPA7pawF for ; Wed, 7 Apr 2010 00:24:00 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D176A3A681D for ; Wed, 7 Apr 2010 00:23:59 -0700 (PDT) Received: by ewy24 with SMTP id 24so371392ewy.13 for ; Wed, 07 Apr 2010 00:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=AghFLAsg4Vv9aQ5MMLFAMZQKUrxn1n5MUBPjXQjrjwg=; b=Y4px1BbD8ecn6rqFgLEuHnTPlPNSqHN9BOewEG0z/X+YETInH95f1b0Reo+Skei+rs 77fH72X3DAOHp52NNOkuXxqH4b6r6mXVWtgN+9C+j3r396fCkZZayeT+tD8nSXv3gNAS HDTK2KewLRGBZ2KIOObIs+SjEvQd6Vrx6MXsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ePXNXQjGFaZThJ9t/CRhOZlsuEUcMcNc2pAL228VClNdoBOK7IMrfSiSi6iLxGTOsF 3FYGk4b/iMCYev3Kf6wSjylL6zTbQVLYFSeGANZZQryN6RF4FJrfPtyy+hq7b9bosm0R iTIm4f1b7lDL10T2oR9dyrKpwzXozS4JLmp+M= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 00:23:52 -0700 (PDT) In-Reply-To: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> Date: Wed, 7 Apr 2010 09:23:52 +0200 Received: by 10.213.55.138 with SMTP id u10mr1688362ebg.23.1270625032973; Wed, 07 Apr 2010 00:23:52 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0014852f5770bbb1f30483a07162 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:24:02 -0000 --0014852f5770bbb1f30483a07162 Content-Type: text/plain; charset=ISO-8859-1 This is a special case. And the application you are talking about is a B2BUA, right? In this case the AOR addressed is an application address without registered contacts. One can argue that the OPTIONS request should return the general capabilities of the application. No OPTIONS forking is happening in this case, no registered contacts. No issue? In reality what the B2BUA will do with the OPTION request (forward or answer) depends on the fantasy of the B2BUA developer. I dont think this scenario is actually usefull in discussing whether or not to write a BCP on OPTIONS handling. Or maybe it is as implication of B2BUA behaviours can be taken into account. /Hans Erik van Elburg On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > I agree with Dale. What happens to an OPTIONS request will not necessarily > be reflected when an INVITE request is sent shortly afterwards. As a further > examples, in contact centres, it is usual to distribute calls cyclically or > randomly between qualified and available agents. Sending an INVITE request > to a UA determined by responses to an OPTIONS request would break that model > - the issuer of the OPTIONS and INVITE requests cannot be expected to obey > the same rotation rules as the domain proxy that routes INVITE requests. > Issuing an INVITE request to the AOR is unlikely to result in it being > delivered to the UA that might be expected from analysis of responses to an > OPTIONS request. > > I don't think we should work on trying to make OPTIONS work for this > purpose. If we really need to do anything with OPTIONS, we should just issue > warnings about its unsuitability for purposes other than a simple ping. > > John > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of WORLEY, DALE R (DALE) > > Sent: 06 April 2010 21:01 > > To: Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com] > > Sent: Thursday, April 01, 2010 3:36 AM > > > > A good mechanism to discovery UA capabilities is essential to > > provide meaningful service: > > So I am in favor of pursuing the work, > > in particular the possibility to use a single OPTIONS request > > to retrieve the capabilities from ALL UAS(s) behind a forking proxy. > > _______________________________________ > > > > I think it is a misconception to use UA discovery to provide > > services. The difficulty is that the set of available UAs > > for a given destination URI changes unpredictably -- elements > > become inacessible (mobile phone out of range!), call routing > > changes due to time of day, etc. Instead, SIP provides a > > remarkably effective system for selecting the best target of > > a call *at the moment the call is initiated* -- the caller > > declares his preferences, and the various intermediate > > elements combine the caller's desires with the routing > > information that they possess to forward the call closer to > > the preferred destination. > > > > As a developer, I've had to wrestle with this. In order to > > provide clean "Is extension 1234 busy?" information, our "BLF > > agent" maintains subscriptions to the "reg" event package for > > the AOR "sip:1234@example.com ". For each > reported contact > > for the AOR, it maintains a dialog subscription to the > > contact. Only by tracking the "reg" events can it keep track > > of the UAs available for that AOR. And even then, it is at > > the mercy of network failures. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0014852f5770bbb1f30483a07162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a special case. And the application you are talking about is a B2BU= A, right?

In this case the AOR addressed is an application address w= ithout registered contacts. One can argue that the OPTIONS request should r= eturn the general capabilities of the application. No OPTIONS forking is ha= ppening in this case, no registered contacts. No issue?

In reality what the B2BUA will do with the OPTION request (forward or a= nswer) depends on the fantasy of the B2BUA developer.

I dont think t= his scenario is actually usefull in discussing whether or not to write a BC= P on OPTIONS handling. Or maybe it is as implication of B2BUA behaviours ca= n be taken into account.

/Hans Erik van Elburg


On Wed, Apr 7, 2010 at 8:31 AM, Elwell, = John <john.elwell@siemens-enterprise.com> w= rote:
I agree with Dale. What happens to an OPTIONS request will not necessarily = be reflected when an INVITE request is sent shortly afterwards. As a furthe= r examples, in contact centres, it is usual to distribute calls cyclically = or randomly between qualified and available agents. Sending an INVITE reque= st to a UA determined by responses to an OPTIONS request would break that m= odel - the issuer of the OPTIONS and INVITE requests cannot be expected to = obey the same rotation rules as the domain proxy that routes INVITE request= s. Issuing an INVITE request to the AOR is unlikely to result in it being d= elivered to the UA that might be expected from analysis of responses to an = OPTIONS request.

I don't think we should work on trying to make OPTIONS work for this pu= rpose. If we really need to do anything with OPTIONS, we should just issue = warnings about its unsuitability for purposes other than a simple ping.

John


> -----Original Message-----
> From: si= pcore-bounces@ietf.org
> [mailto:sipcore-bounces@ietf.org] On Behalf Of WORLEY, DALE R (DALE= )
> Sent: 06 April 2010 21:01
> To: Salvatore Loreto; sipcore@ietf.org
> Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?
>
> ________________________________________
> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On<= br> > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com]
> Sent: Thursday, April 01, 2010 3:36 AM
>
> A good mechanism to discovery UA capabilities is essential to
> provide meaningful service:
> So I am in favor of pursuing the work,
> in particular the possibility to use a single OPTIONS request
> to retrieve the capabilities from ALL UAS(s) behind a forking proxy. > _______________________________________
>
> I think it is a misconception to use UA discovery to provide
> services. =A0The difficulty is that the set of available UAs
> for a given destination URI changes unpredictably -- elements
> become inacessible (mobile phone out of range!), call routing
> changes due to time of day, etc. =A0Instead, SIP provides a
> remarkably effective system for selecting the best target of
> a call *at the moment the call is initiated* -- the caller
> declares his preferences, and the various intermediate
> elements combine the caller's desires with the routing
> information that they possess to forward the call closer to
> the preferred destination.
>
> As a developer, I've had to wrestle with this. =A0In order to
> provide clean "Is extension 1234 busy?" information, our &qu= ot;BLF
> agent" maintains subscriptions to the "reg" event packa= ge for
> the AOR "sip:1234@example.com". =A0For each reported contact
> for the AOR, it maintains a dialog subscription to the
> contact. =A0Only by tracking the "reg" events can it keep tr= ack
> of the UAs available for that AOR. =A0And even then, it is at
> the mercy of network failures.
>
> Dale
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--0014852f5770bbb1f30483a07162-- From ietf.hanserik@gmail.com Wed Apr 7 00:34:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC423A6A82 for ; Wed, 7 Apr 2010 00:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN6K4ax4WioS for ; Wed, 7 Apr 2010 00:34:23 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 75BC23A6359 for ; Wed, 7 Apr 2010 00:34:23 -0700 (PDT) Received: by ewy24 with SMTP id 24so375015ewy.13 for ; Wed, 07 Apr 2010 00:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Y5Apr4lAPdmIAyWGtmZNC/wuZVuywqX7Vdz7r+0d97Y=; b=b2XPVX0L06jhNd5sRl2BrC4edky8D1KvpvVTSeOJfK+0mHsVXktcj9dMAGxrrApZdB Ku5vwJeoyGxSqYzmDTTsHuZ7occ2eg3jk0eCU1BLyx5fsiewryFTIlh9zVOcJXz85vxd zrVLCqfpd6MyIs4HQWIopnnv8qbGpHKCV5sYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s2WXD8wk07EZaqJskvzwhUPIz5R/IOYjDFflVhPTDcGXrrUQJCz3hXj3wqMsPoeuA5 BN9953Sf2WOMR+7wuPJE6qm869+RohkGLre2/sWNn5nKfw54y8Bt2SHi3dSu08eiEpGN 5YmA0OXIWjptWdYWW6R3x+xHWisF+ghjYk5U4= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 00:34:15 -0700 (PDT) In-Reply-To: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> Date: Wed, 7 Apr 2010 09:34:15 +0200 Received: by 10.213.57.138 with SMTP id c10mr1773743ebh.58.1270625656090; Wed, 07 Apr 2010 00:34:16 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=00c09ffb4e23dfb1910483a09612 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:34:24 -0000 --00c09ffb4e23dfb1910483a09612 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 7, 2010 at 9:09 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > >>I think the main use-case is when you want to contact end users. > > >[JRE] A contact centre agent is indeed an end user. > > > > Yes, but not the same kind of end user :) > [JRE] So what kind of end user is within scope of this work? How does the > issuer of OPTIONS/INVITE requests know whether he is targeting the right > sort of end user for the mechanism to work? I think it is dangerous to base > mechanisms on assumptions about particular types of end user. > > [HE] I guess as long as the AOR addressed represents the user and the AOR's domain portion is owned by the proxy at which the user registered with the AOR's user-portion. Then there is no need to distinguish end users. Throwing in any B2BUA or other anomaly will of course break things. But that is in the nature of SIP's design. And maybe not really relevant for this discussion. /Hans Erik van Elburg --00c09ffb4e23dfb1910483a09612 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 7, 2010 at 9:09 AM, Elwell, = John <john.elwell@siemens-enterprise.com> wrote:
> >>I think the main use-case is when you want t= o contact end users.
> >[JRE] A contact centre agent is indeed an end user.
>
> Yes, but not the same kind of end user :)
[JRE] So what kind of end user is within scope of this work? How does= the issuer of OPTIONS/INVITE requests know whether he is targeting the rig= ht sort of end user for the mechanism to work? I think it is dangerous to b= ase mechanisms on assumptions about particular types of end user.

[HE] I guess as long a= s the AOR addressed represents the user and the AOR's domain portion is= owned by the proxy at which the user registered with the AOR's user-po= rtion. Then there is no need to distinguish end users.

Throwing in any B2BUA or other anomaly will of course break things. But= that is in the nature of SIP's design. =A0 And maybe not really releva= nt for this discussion.

/Hans Erik van Elburg
--00c09ffb4e23dfb1910483a09612-- From john.elwell@siemens-enterprise.com Wed Apr 7 01:41:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8193A6826 for ; Wed, 7 Apr 2010 01:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8HY4ft3wJH3 for ; Wed, 7 Apr 2010 01:41:59 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A30A13A67F0 for ; Wed, 7 Apr 2010 01:41:58 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1466174; Wed, 7 Apr 2010 10:41:55 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2B0EF23F0278; Wed, 7 Apr 2010 10:41:55 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 7 Apr 2010 10:41:55 +0200 From: "Elwell, John" To: Hans Erik van Elburg Date: Wed, 7 Apr 2010 10:41:53 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWI0ca54Os5Zx+TUCgr+6AVDofRAACnyqQ Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 08:42:00 -0000 =20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 07 April 2010 08:24 > To: Elwell, John > Cc: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 > This is a special case. And the application you are talking=20 > about is a B2BUA, right? [JRE] Not necessarily. A proxy can be scripted to cycle between multiple re= gistered contacts. This doesn't make it a B2BUA. John >=20 > In this case the AOR addressed is an application address=20 > without registered contacts. One can argue that the OPTIONS=20 > request should return the general capabilities of the=20 > application. No OPTIONS forking is happening in this case, no=20 > registered contacts. No issue? >=20 > In reality what the B2BUA will do with the OPTION request=20 > (forward or answer) depends on the fantasy of the B2BUA developer. >=20 > I dont think this scenario is actually usefull in discussing=20 > whether or not to write a BCP on OPTIONS handling. Or maybe=20 > it is as implication of B2BUA behaviours can be taken into account.=20 >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John=20 > wrote: >=20 >=20 > I agree with Dale. What happens to an OPTIONS request=20 > will not necessarily be reflected when an INVITE request is=20 > sent shortly afterwards. As a further examples, in contact=20 > centres, it is usual to distribute calls cyclically or=20 > randomly between qualified and available agents. Sending an=20 > INVITE request to a UA determined by responses to an OPTIONS=20 > request would break that model - the issuer of the OPTIONS=20 > and INVITE requests cannot be expected to obey the same=20 > rotation rules as the domain proxy that routes INVITE=20 > requests. Issuing an INVITE request to the AOR is unlikely to=20 > result in it being delivered to the UA that might be expected=20 > from analysis of responses to an OPTIONS request. > =09 > I don't think we should work on trying to make OPTIONS=20 > work for this purpose. If we really need to do anything with=20 > OPTIONS, we should just issue warnings about its=20 > unsuitability for purposes other than a simple ping. > =09 > John > =09 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > =09 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > WORLEY, DALE R (DALE) > > Sent: 06 April 2010 21:01 > > To: Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > ________________________________________ > =09 > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com] > > Sent: Thursday, April 01, 2010 3:36 AM > > > > A good mechanism to discovery UA capabilities is essential to > > provide meaningful service: > > So I am in favor of pursuing the work, > > in particular the possibility to use a single OPTIONS request > > to retrieve the capabilities from ALL UAS(s) behind a=20 > forking proxy. > > _______________________________________ > > > > I think it is a misconception to use UA discovery to provide > > services. The difficulty is that the set of available UAs > > for a given destination URI changes unpredictably -- elements > > become inacessible (mobile phone out of range!), call routing > > changes due to time of day, etc. Instead, SIP provides a > > remarkably effective system for selecting the best target of > > a call *at the moment the call is initiated* -- the caller > > declares his preferences, and the various intermediate > > elements combine the caller's desires with the routing > > information that they possess to forward the call closer to > > the preferred destination. > > > > As a developer, I've had to wrestle with this. In order to > > provide clean "Is extension 1234 busy?" information, our "BLF > > agent" maintains subscriptions to the "reg" event package for > > the AOR "sip:1234@example.com=20 > ". For each reported contact > > for the AOR, it maintains a dialog subscription to the > > contact. Only by tracking the "reg" events can it keep track > > of the UAs available for that AOR. And even then, it is at > > the mercy of network failures. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =09 >=20 >=20 > = From ietf.hanserik@gmail.com Wed Apr 7 02:18:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255AA3A68CC for ; Wed, 7 Apr 2010 02:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id durRvdzVNjOK for ; Wed, 7 Apr 2010 02:18:24 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id EA9763A6874 for ; Wed, 7 Apr 2010 02:18:21 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so83776eyf.51 for ; Wed, 07 Apr 2010 02:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=68A6cKknRi5PJlEVkkDh6iZshcIO48FbM1U2r8qiFys=; b=jWzJN/mQLvJbeFHzewJW8zs7BUxqxdIWB1S2+0qpNqIrSjCY0mbY8BSMIi4IIyktJg C1yAaX81ft5cz+3NO46juLgoYqWvNE7NaOKLNSiPFnQ3sL8veurxo/aakUMfXbKHXjMb ZywPcMUwO7+y9z+WnRMPlio7XDgIHvieDtmoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J+6/wE3gzpYuogZhGKj6N5P0PFRwnWeIeAUI8ldjgmMUN2yTiXzroGRE1JenLf5EPr V0+6hDGtAeeWI0U56duGtU4M2ZusS6yMJ6vyCGgXeYIjLf6bi+rzJ/iKmGYT9wPPIz6M kmhmdMk0CjvQrn6mFKP0zgw3cpv8kYNaZZaeM= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 02:18:15 -0700 (PDT) In-Reply-To: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> Date: Wed, 7 Apr 2010 11:18:15 +0200 Received: by 10.213.39.196 with SMTP id h4mr1754466ebe.97.1270631895887; Wed, 07 Apr 2010 02:18:15 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=00148531a91acb71940483a20ab4 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 09:18:26 -0000 --00148531a91acb71940483a20ab4 Content-Type: text/plain; charset=ISO-8859-1 Of course you can implement all kind of policies, but that makes this AOR quite of a special user. I would argue that this is some kind of service AOR and not a "normal" user AOR. The service AOR representing a group of different and dynamically changing users... Demonstrating that this is not a "normal" user. I expect that in practice one would solve this differently... making the case rather artificial. /Hans Erik van Elburg On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 07 April 2010 08:24 > > To: Elwell, John > > Cc: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > This is a special case. And the application you are talking > > about is a B2BUA, right? > [JRE] Not necessarily. A proxy can be scripted to cycle between multiple > registered contacts. This doesn't make it a B2BUA. > > John > > > > > In this case the AOR addressed is an application address > > without registered contacts. One can argue that the OPTIONS > > request should return the general capabilities of the > > application. No OPTIONS forking is happening in this case, no > > registered contacts. No issue? > > > > In reality what the B2BUA will do with the OPTION request > > (forward or answer) depends on the fantasy of the B2BUA developer. > > > > I dont think this scenario is actually usefull in discussing > > whether or not to write a BCP on OPTIONS handling. Or maybe > > it is as implication of B2BUA behaviours can be taken into account. > > > > /Hans Erik van Elburg > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > wrote: > > > > > > I agree with Dale. What happens to an OPTIONS request > > will not necessarily be reflected when an INVITE request is > > sent shortly afterwards. As a further examples, in contact > > centres, it is usual to distribute calls cyclically or > > randomly between qualified and available agents. Sending an > > INVITE request to a UA determined by responses to an OPTIONS > > request would break that model - the issuer of the OPTIONS > > and INVITE requests cannot be expected to obey the same > > rotation rules as the domain proxy that routes INVITE > > requests. Issuing an INVITE request to the AOR is unlikely to > > result in it being delivered to the UA that might be expected > > from analysis of responses to an OPTIONS request. > > > > I don't think we should work on trying to make OPTIONS > > work for this purpose. If we really need to do anything with > > OPTIONS, we should just issue warnings about its > > unsuitability for purposes other than a simple ping. > > > > John > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > WORLEY, DALE R (DALE) > > > Sent: 06 April 2010 21:01 > > > To: Salvatore Loreto; sipcore@ietf.org > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > > ________________________________________ > > > > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > > > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com] > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > A good mechanism to discovery UA capabilities is essential to > > > provide meaningful service: > > > So I am in favor of pursuing the work, > > > in particular the possibility to use a single OPTIONS request > > > to retrieve the capabilities from ALL UAS(s) behind a > > forking proxy. > > > _______________________________________ > > > > > > I think it is a misconception to use UA discovery to provide > > > services. The difficulty is that the set of available UAs > > > for a given destination URI changes unpredictably -- elements > > > become inacessible (mobile phone out of range!), call routing > > > changes due to time of day, etc. Instead, SIP provides a > > > remarkably effective system for selecting the best target of > > > a call *at the moment the call is initiated* -- the caller > > > declares his preferences, and the various intermediate > > > elements combine the caller's desires with the routing > > > information that they possess to forward the call closer to > > > the preferred destination. > > > > > > As a developer, I've had to wrestle with this. In order to > > > provide clean "Is extension 1234 busy?" information, our "BLF > > > agent" maintains subscriptions to the "reg" event package for > > > the AOR "sip:1234@example.com > > > ". For each > reported contact > > > for the AOR, it maintains a dialog subscription to the > > > contact. Only by tracking the "reg" events can it keep track > > > of the UAs available for that AOR. And even then, it is at > > > the mercy of network failures. > > > > > > Dale > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > --00148531a91acb71940483a20ab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Of course you can implement all kind of policies, but that makes this AOR q= uite of a special user. I would argue that this is some kind of service AOR= and not a "normal" user AOR. The service AOR representing a grou= p of different and dynamically changing users...

Demonstrating that this is not a "normal" user.

I expe= ct that in practice one would solve this differently... making the case rat= her artificial.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 10:41 AM, Elwell, Joh= n <john.elwell@siemens-enterprise.com> wrote:


> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: 07 April 2010 08:24
> To: Elwell, John
> Cc: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
> Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?
>
> This is a special case. And the application yo= u are talking
> about is a B2BUA, right?
[JRE] Not necessarily. A proxy can be scripted to cycle between multi= ple registered contacts. This doesn't make it a B2BUA.

John

>
> In this case the AOR addressed is an application address
> without registered contacts. One can argue that the OPTIONS
> request should return the general capabilities of the
> application. No OPTIONS forking is happening in this case, no
> registered contacts. No issue?
>
> In reality what the B2BUA will do with the OPTION request
> (forward or answer) depends on the fantasy of the B2BUA developer.
>
> I dont think this scenario is actually usefull in discussing
> whether or not to write a BCP on OPTIONS handling. Or maybe
> it is as implication of B2BUA behaviours can be taken into account. >
> /Hans Erik van Elburg
>
>
>
> On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 I agree with Dale. What happens to an OPTIONS request
> will not necessarily be reflected when an INVITE request is
> sent shortly afterwards. As a further examples, in contact
> centres, it is usual to distribute calls cyclically or
> randomly between qualified and available agents. Sending an
> INVITE request to a UA determined by responses to an OPTIONS
> request would break that model - the issuer of the OPTIONS
> and INVITE requests cannot be expected to obey the same
> rotation rules as the domain proxy that routes INVITE
> requests. Issuing an INVITE request to the AOR is unlikely to
> result in it being delivered to the UA that might be expected
> from analysis of responses to an OPTIONS request.
>
> =A0 =A0 =A0 I don't think we should work on trying to make OPTIONS=
> work for this purpose. If we really need to do anything with
> OPTIONS, we should just issue warnings about its
> unsuitability for purposes other than a simple ping.
>
> =A0 =A0 =A0 John
>
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: sip= core-bounces@ietf.org
>
> =A0 =A0 =A0 > [mailto:s= ipcore-bounces@ietf.org] On Behalf Of
> WORLEY, DALE R (DALE)
> =A0 =A0 =A0 > Sent: 06 April 2010 21:01
> =A0 =A0 =A0 > To: Salvatore Loreto; sipcore@ietf.org
> =A0 =A0 =A0 > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on = this?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > ________________________________________
>
> =A0 =A0 =A0 > From: sip= core-bounces@ietf.org [sipc= ore-bounces@ietf.org] On
> =A0 =A0 =A0 > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com]
> =A0 =A0 =A0 > Sent: Thursday, April 01, 2010 3:36 AM
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > A good mechanism to discovery UA capabilities is esse= ntial to
> =A0 =A0 =A0 > provide meaningful service:
> =A0 =A0 =A0 > So I am in favor of pursuing the work,
> =A0 =A0 =A0 > in particular the possibility to use a single OPTIONS= request
> =A0 =A0 =A0 > to retrieve the capabilities from ALL UAS(s) behind a=
> forking proxy.
> =A0 =A0 =A0 > _______________________________________
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I think it is a misconception to use UA discovery to = provide
> =A0 =A0 =A0 > services. =A0The difficulty is that the set of availa= ble UAs
> =A0 =A0 =A0 > for a given destination URI changes unpredictably -- = elements
> =A0 =A0 =A0 > become inacessible (mobile phone out of range!), call= routing
> =A0 =A0 =A0 > changes due to time of day, etc. =A0Instead, SIP prov= ides a
> =A0 =A0 =A0 > remarkably effective system for selecting the best ta= rget of
> =A0 =A0 =A0 > a call *at the moment the call is initiated* -- the c= aller
> =A0 =A0 =A0 > declares his preferences, and the various intermediat= e
> =A0 =A0 =A0 > elements combine the caller's desires with the ro= uting
> =A0 =A0 =A0 > information that they possess to forward the call clo= ser to
> =A0 =A0 =A0 > the preferred destination.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > As a developer, I've had to wrestle with this. = =A0In order to
> =A0 =A0 =A0 > provide clean "Is extension 1234 busy?" inf= ormation, our "BLF
> =A0 =A0 =A0 > agent" maintains subscriptions to the "reg&= quot; event package for
> =A0 =A0 =A0 > the AOR "sip:1234@example.com
> <mailto:sip= %3A1234@example.com> ". =A0For each reported contact
> =A0 =A0 =A0 > for the AOR, it mai= ntains a dialog subscription to the
> =A0 =A0 =A0 > contact. =A0Only by tracking the "reg" even= ts can it keep track
> =A0 =A0 =A0 > of the UAs available for that AOR. =A0And even then, = it is at
> =A0 =A0 =A0 > the mercy of network failures.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Dale
> =A0 =A0 =A0 > _______________________________________________
> =A0 =A0 =A0 > sipcore mailing list
> =A0 =A0 =A0 > sipcore@ietf.org<= /a>
> =A0 =A0 =A0 > https://www.ietf.org/mailman/listinfo/sipcore > =A0 =A0 =A0 >
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 sipcore mailing list
> =A0 =A0 =A0 sipcore@ietf.org > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore
>
>
>
>

--00148531a91acb71940483a20ab4-- From gao.yang2@zte.com.cn Wed Apr 7 03:22:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26AD3A6882 for ; Wed, 7 Apr 2010 03:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeTNCKKBVOBp for ; Wed, 7 Apr 2010 03:22:15 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 713D63A6861 for ; Wed, 7 Apr 2010 03:22:13 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Wed, 7 Apr 2010 18:19:28 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.4786316380; Wed, 7 Apr 2010 18:22:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o37ALpTk064055; Wed, 7 Apr 2010 18:22:03 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org, Gonzalo.Camarillo@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Apr 2010 18:19:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-07 18:21:51, Serialize complete at 2010-04-07 18:21:51 Content-Type: multipart/alternative; boundary="=_alternative 0038E91C482576FE_=" X-MAIL: mse2.zte.com.cn o37ALpTk064055 Subject: [sipcore] About O/A rules in RFC3261: //Adding some description X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:22:17 -0000 This is a multipart message in MIME format. --=_alternative 0038E91C482576FE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 cGxlYXNlIHNlZSBpbmxpbmVzLg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUt NTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCi0tLS0tINeqt6LIyyBHYW9ZYW5nMTQwMTk3L3VzZXIvenRl X2x0ZCDKsbzkIDIwMTAtMDQtMDcgMTg6MDAgLS0tLS0NCg0KR2FvWWFuZzE0MDE5Ny91c2VyL3p0 ZV9sdGQg0LTT2iAyMDEwLTA0LTA3IDExOjM5OjE4Og0KDQo+IEhpLA0KPiANCj4gV2hpbGUgY29u c2lkZXJpbmcgb25lIHByb2JsZW0gaW4gb3VyIHByb2R1Y3Rpb25zJyBpbnRlcm9wZXJhYmlsaXR5 IA0KPiB0ZXN0aW5nLCBJIHJlLXJlYWQgc29tZSBwYXJ0cyBvZiBvZmZlcmFuc3dlciBkcmFmdCBh bmQgY29ycmVsYXRpdmUgDQo+IHBhcnQgb2YgUkZDMzI2MS4gQW5kIEkgZmluZCBhIHBvdGVudGlh bCBkZXNjcmlwdGlvbiBwcm9ibGVtIGluIA0KPiBSRkMzMjYxIGluY2lkZW50YWxseS4NCj4gDQo+ IC8vY29ycmVsYXRpdmUgcGFydCBvZiBSRkMzMjYxDQo+IG8gIElmIHRoZSBpbml0aWFsIG9mZmVy IGlzIGluIGFuIElOVklURSwgdGhlIGFuc3dlciBNVVNUIGJlIGluIGENCj4gICAgICAgICAgcmVs aWFibGUgbm9uLWZhaWx1cmUgbWVzc2FnZSBmcm9tIFVBUyBiYWNrIHRvIFVBQyB3aGljaCBpcw0K PiAgICAgICAgICBjb3JyZWxhdGVkIHRvIHRoYXQgSU5WSVRFLiAgRm9yIHRoaXMgc3BlY2lmaWNh dGlvbiwgdGhhdCBpcw0KPiAgICAgICAgICBvbmx5IHRoZSBmaW5hbCAyeHggcmVzcG9uc2UgdG8g dGhhdCBJTlZJVEUuICBUaGF0IHNhbWUgZXhhY3QNCj4gICAgICAgICAgYW5zd2VyIE1BWSBhbHNv IGJlIHBsYWNlZCBpbiBhbnkgcHJvdmlzaW9uYWwgcmVzcG9uc2VzIHNlbnQNCj4gICAgICAgICAg cHJpb3IgdG8gdGhlIGFuc3dlci4gIFRoZSBVQUMgTVVTVCB0cmVhdCB0aGUgZmlyc3Qgc2Vzc2lv bg0KPiAgICAgICAgICBkZXNjcmlwdGlvbiBpdCByZWNlaXZlcyBhcyB0aGUgYW5zd2VyLCBhbmQg TVVTVCBpZ25vcmUgYW55DQo+ICAgICAgICAgIHNlc3Npb24gZGVzY3JpcHRpb25zIGluIHN1YnNl cXVlbnQgcmVzcG9uc2VzIHRvIHRoZSBpbml0aWFsDQo+ICAgICAgICAgIElOVklURS4NCj4gDQo+ IEFzIHRoZSB0ZXh0IGFsbG93IFVBUyBzZW5kIFNEUCBiZWZvcmUgdGhlIGZpbmFsIGFuc3dlciwg dGhlIGZpcnN0IA0KPiBzZXNzaW9uIGRlc2NyaXB0aW9uIFVBQyByZWNlaXZlcyBjYW4gbm90IGJl IHRyZWF0ZWQgYXMgYW5zd2VyIGluIA0KPiBzdWNoIGNhc2VzLiBBbmQgdGhlIGN1cnJlbnQgdGV4 dCBkZWZpbmVzIHRoYXQgVUFDIE1VU1QgaWdub3JlIGFueSANCj4gU0RQIGluIHN1YnNlcXVlbnQg cmVzcG9uc2VzIHRvIHRoZSBpbml0aWFsIElOVklURS4gd2hpY2sgbWF5IG1ha2UgDQo+IHRoZSBV QUMgaWdub3JlIHRoZSByZWFsIGFuc3dlciBpbiBzb21lIGNhc2UuDQo+IA0KPiBJIHRoaW5rIHRo ZSBkZXNjcmlwdGlvbiBzaG91bGQgYmU6IA0KPiBUaGUgVUFDIE1VU1QgdHJlYXQgdGhlIGZpcnN0 IHNlc3Npb24gZGVzY3JpcHRpb24gd2hpY2ggaXMgaW4gYSANCj4gcmVsaWFibGUgbm9uLWZhaWx1 cmUgbWVzc2FnZSBpdCByZWNlaXZlcyBhcyB0aGUgYW5zd2VyLCBhbmQgTVVTVCANCj4gaWdub3Jl IGFueSBzZXNzaW9uIGRlc2NyaXB0aW9ucyBpbiBzdWJzZXF1ZW50IHJlc3BvbnNlcyB0byB0aGUg aW5pdGlhbCANCklOVklURS4NCg0KVGhpcyBzdWdnZXN0aW9uIGlzIGJhc2VkIG9uIG15IGFub3Ro ZXIgc3VnZ2VzdGlvbiBvbiBvZmZlcmFuc3dlciBkcmFmdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zaXBwaW5nL2N1cnJlbnQvbXNnMTc1MDQuaHRtbA0KDQpDb25zaWRl cmluZyBpbnRlZ3JhbGl0eSwgaWYgdGhlIHN1Z2dlc3Rpb24gb24gb2ZmZXJhbnN3ZXIgZHJhZnQg aXMgbm90IA0KcHJvcGVyLCB0aGUgY29ycmVjdGlvbiB0ZXh0IGZvciBSRkMzMjYxJ3MgcGFydCBz aG91bGQgaGF2ZSBhbm90aGVyIHZlcnNpb24gDQphczoNCg0KU0RQIHNhbWUgYXMgdGhlIGZpbmFs IGFuc3dlciBNQVkgYWxzbyBiZSBwbGFjZWQgaW4gYW55IHVucmVsaWFibGUgDQpwcm92aXNpb25h bCByZXNwb25zZXMgc2VudCBwcmlvciB0byB0aGUgYW5zd2VyLiAgSWYgdGhlIHRoZSBmaXJzdCBz ZXNzaW9uIA0KZGVzY3JpcHRpb24gdGhlIFVBQyByZWNlaXZlcyBpcyBub3QgYW5zd2VyLCB0aGUg VUFDIE1VU1QgdHJlYXQgdGhlIFNEUCBhcyANCmlmIHRoZSBhbnN3ZXIsIGFuZCBNVVNUIGlnbm9y ZSBhbnkgc2Vzc2lvbiBkZXNjcmlwdGlvbnMgaW4gc3Vic2VxdWVudCANCnJlc3BvbnNlcyB0byB0 aGUgaW5pdGlhbCBJTlZJVEUuDQoNClNvLCBJIHRoaW5rIHdlIHNob3VsZCBldmFsdWF0ZSB0aGUg bmVjZXNzaXR5IG9mIHRoZSBzYW1lbmVzcyBvZiB0aGUgYW5zd2VyIA0KYW5kIHRoZSBwcmV2aW91 cyBTRFBzLiANCg0KPiANCj4gQW5kIGlmIHRoZSBwcm9ibGVtIGlzIGV4aXN0LCB3aGVyZSBzaG91 bGQgYmUgdGhlIGNvcnJlY3Rpb24ncyBsb2NhdGlvbj8NCj4gSSB0aGluayBkcmFmdC1pZXRmLXNp cGNvcmUtcmVpbnZpdGUtMDMgaXMgbm90IHByb3BlciwgYXMgaXQgYWltcyBmb3INCj4gUmUtSU5W SVRFLiBBbmQgYSBuZXcgZHJhZnQgZm9yIHN1Y2ggdGlueSAqcG90ZW50aWFsKiBwcm9ibGVtIGlz IGFsc28NCj4gbm90IHByb3Blci4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IEdhbw0KPiANCj4gPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gIFppcCAgICA6IDIxMDAxMg0KPiAg VGVsICAgIDogODcyMTENCj4gIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQo+ICBlX21haWwg OiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtIHN5c3RlbS4NCg== --=_alternative 0038E91C482576FE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnBsZWFzZSBzZWUgaW5saW5lcy48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAw MTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2 KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsgR2FvWWFuZzE0 MDE5Ny91c2VyL3p0ZV9sdGQNCsqxvOQgMjAxMC0wNC0wNyAxODowMCAtLS0tLTwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkINC009og MjAxMC0wNC0wNyAxMTozOToxODo8YnI+DQo8YnI+DQomZ3Q7IEhpLDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFdoaWxlIGNvbnNpZGVyaW5nIG9uZSBw cm9ibGVtIGluIG91ciBwcm9kdWN0aW9ucycgaW50ZXJvcGVyYWJpbGl0eQ0KPGJyPg0KJmd0OyB0 ZXN0aW5nLCBJIHJlLXJlYWQgc29tZSBwYXJ0cyBvZiBvZmZlcmFuc3dlciBkcmFmdCBhbmQgY29y cmVsYXRpdmUNCjxicj4NCiZndDsgcGFydCBvZiBSRkMzMjYxLiBBbmQgSSBmaW5kIGEgcG90ZW50 aWFsIGRlc2NyaXB0aW9uIHByb2JsZW0gaW4gPGJyPg0KJmd0OyBSRkMzMjYxIGluY2lkZW50YWxs eS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAvL2Nv cnJlbGF0aXZlIHBhcnQgb2YgUkZDMzI2MTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBvICZuYnNwO0lmIHRoZSBpbml0aWFsIG9mZmVyIGlzIGluIGFuIElOVklURSwNCnRo ZSBhbnN3ZXIgTVVTVCBiZSBpbiBhPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWxpYWJsZSBub24tZmFpbHVy ZQ0KbWVzc2FnZSBmcm9tIFVBUyBiYWNrIHRvIFVBQyB3aGljaCBpczwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Y29ycmVsYXRlZA0KdG8gdGhhdCBJTlZJVEUuICZuYnNwO0ZvciB0aGlzIHNwZWNpZmljYXRpb24s IHRoYXQgaXM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29ubHkgdGhlIGZpbmFsDQoyeHggcmVzcG9uc2UgdG8g dGhhdCBJTlZJVEUuICZuYnNwO1RoYXQgc2FtZSBleGFjdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW5zd2Vy IE1BWQ0KYWxzbyBiZSBwbGFjZWQgaW4gYW55IHByb3Zpc2lvbmFsIHJlc3BvbnNlcyBzZW50PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtwcmlvciB0byB0aGUNCmFuc3dlci4gJm5ic3A7VGhlIFVBQyBNVVNUIHRy ZWF0IHRoZSBmaXJzdCBzZXNzaW9uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbg0KaXQgcmVj ZWl2ZXMgYXMgdGhlIGFuc3dlciwgYW5kIE1VU1QgaWdub3JlIGFueTwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 c2Vzc2lvbiBkZXNjcmlwdGlvbnMNCmluIHN1YnNlcXVlbnQgcmVzcG9uc2VzIHRvIHRoZSBpbml0 aWFsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtJTlZJVEUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgQXMgdGhlIHRleHQgYWxsb3cgVUFTIHNlbmQgU0RQIGJlZm9y ZSB0aGUgZmluYWwgYW5zd2VyLCB0aGUgZmlyc3QNCjxicj4NCiZndDsgc2Vzc2lvbiBkZXNjcmlw dGlvbiBVQUMgcmVjZWl2ZXMgY2FuIG5vdCBiZSB0cmVhdGVkIGFzIGFuc3dlciBpbiA8YnI+DQom Z3Q7IHN1Y2ggY2FzZXMuIEFuZCB0aGUgY3VycmVudCB0ZXh0IGRlZmluZXMgdGhhdCBVQUMgTVVT VCBpZ25vcmUgYW55DQo8YnI+DQomZ3Q7IFNEUCBpbiBzdWJzZXF1ZW50IHJlc3BvbnNlcyB0byB0 aGUgaW5pdGlhbCBJTlZJVEUuIHdoaWNrIG1heSBtYWtlDQo8YnI+DQomZ3Q7IHRoZSBVQUMgaWdu b3JlIHRoZSByZWFsIGFuc3dlciBpbiBzb21lIGNhc2UuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGUgZGVzY3JpcHRpb24gc2hvdWxk IGJlOiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhlIFVBQyBNVVNU IHRyZWF0IHRoZSBmaXJzdCBzZXNzaW9uIGRlc2NyaXB0aW9uDQp3aGljaCBpcyBpbiBhIDxicj4N CiZndDsgcmVsaWFibGUgbm9uLWZhaWx1cmUgbWVzc2FnZSBpdCByZWNlaXZlcyBhcyB0aGUgYW5z d2VyLCBhbmQgTVVTVCA8YnI+DQomZ3Q7IGlnbm9yZSBhbnkgc2Vzc2lvbiBkZXNjcmlwdGlvbnMg aW4gc3Vic2VxdWVudCByZXNwb25zZXMgdG8gdGhlIGluaXRpYWwNCklOVklURS48L2ZvbnQ+PC90 dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoaXMgc3VnZ2VzdGlvbiBpcyBiYXNlZCBv biBteSBhbm90aGVyIHN1Z2dlc3Rpb24NCm9uIG9mZmVyYW5zd2VyIGRyYWZ0Omh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBwaW5nL2N1cnJlbnQvbXNnMTc1MDQuaHRtbDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Q29uc2lkZXJpbmcgaW50ZWdy YWxpdHksIGlmIHRoZSBzdWdnZXN0aW9uIG9uIG9mZmVyYW5zd2VyDQpkcmFmdCBpcyBub3QgcHJv cGVyLCB0aGUgY29ycmVjdGlvbiB0ZXh0IGZvciBSRkMzMjYxJ3MgcGFydCBzaG91bGQgaGF2ZQ0K YW5vdGhlciB2ZXJzaW9uIGFzOjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+PGI+U0RQIHNhbWUgYXMgdGhlIGZpbmFsIGFuc3dlcjwvYj4gTUFZIGFsc28gYmUgcGxhY2Vk DQppbiBhbnkgdW5yZWxpYWJsZSBwcm92aXNpb25hbCByZXNwb25zZXMgc2VudCBwcmlvciB0byB0 aGUgYW5zd2VyLiAmbmJzcDs8Yj5JZg0KdGhlIHRoZSBmaXJzdCBzZXNzaW9uIGRlc2NyaXB0aW9u IHRoZSBVQUMgcmVjZWl2ZXMgaXMgbm90IGFuc3dlcjwvYj4sIHRoZQ0KVUFDIE1VU1QgdHJlYXQg dGhlIFNEUCA8Yj5hcyBpZjwvYj4gdGhlIGFuc3dlciwgYW5kIE1VU1QgaWdub3JlIGFueSBzZXNz aW9uDQpkZXNjcmlwdGlvbnMgaW4gc3Vic2VxdWVudCByZXNwb25zZXMgdG8gdGhlIGluaXRpYWwg SU5WSVRFLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+U28sIEkgdGhp bmsgd2Ugc2hvdWxkIGV2YWx1YXRlIHRoZSBuZWNlc3NpdHkgb2YgdGhlDQpzYW1lbmVzcyBvZiB0 aGUgYW5zd2VyIGFuZCB0aGUgcHJldmlvdXMgU0RQcy4gPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQW5kIGlmIHRoZSBwcm9ibGVtIGlzIGV4 aXN0LCB3aGVyZSBzaG91bGQgYmUgdGhlIGNvcnJlY3Rpb24ncyBsb2NhdGlvbj88L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSB0aGluayBkcmFmdC1pZXRmLXNpcGNvcmUt cmVpbnZpdGUtMDMgaXMgbm90DQpwcm9wZXIsIGFzIGl0IGFpbXMgZm9yPGJyPg0KJmd0OyBSZS1J TlZJVEUuIEFuZCBhIG5ldyBkcmFmdCBmb3Igc3VjaCB0aW55ICpwb3RlbnRpYWwqIHByb2JsZW0g aXMgYWxzbzxicj4NCiZndDsgbm90IHByb3Blci48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGFua3MsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgR2FvPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+DQomZ3Q7ICZuYnNwO1ppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7ICZuYnNw O1RlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgJm5ic3A7VGVsMiAmbmJzcDsgOigr ODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgJm5ic3A7ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY248YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250 PjwvdHQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0038E91C482576FE_=-- From christer.holmberg@ericsson.com Wed Apr 7 03:26:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5182F3A69C9 for ; Wed, 7 Apr 2010 03:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[AWL=1.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xebwtn9DSodO for ; Wed, 7 Apr 2010 03:26:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A82923A6861 for ; Wed, 7 Apr 2010 03:26:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1c-4bbc5ddf5b77 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 39.EB.23532.FDD5CBB4; Wed, 7 Apr 2010 12:26:39 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 12:26:37 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 7 Apr 2010 12:26:25 +0200 From: Christer Holmberg To: Hans Erik van Elburg , "Elwell, John" Date: Wed, 7 Apr 2010 12:26:25 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoA Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7C978ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:26:48 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7C978ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The forking proxy can also have policies what it returns in the 3xx, depend= ing on what the end-users actually represent. And, also with other mechanisms the returned data per end-user may depend o= n what type of end-point it represents. I don't think that is bound to a sp= ecific mechanism as such. Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Hans Erik van Elburg Sent: 7. huhtikuuta 2010 12:18 To: Elwell, John Cc: WORLEY, DALE R (DALE); sipcore@ietf.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? Of course you can implement all kind of policies, but that makes this AOR q= uite of a special user. I would argue that this is some kind of service AOR= and not a "normal" user AOR. The service AOR representing a group of diffe= rent and dynamically changing users... Demonstrating that this is not a "normal" user. I expect that in practice one would solve this differently... making the ca= se rather artificial. /Hans Erik van Elburg On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John > wrote: > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 07 April 2010 08:24 > To: Elwell, John > Cc: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > This is a special case. And the application you are talking > about is a B2BUA, right? [JRE] Not necessarily. A proxy can be scripted to cycle between multiple re= gistered contacts. This doesn't make it a B2BUA. John > > In this case the AOR addressed is an application address > without registered contacts. One can argue that the OPTIONS > request should return the general capabilities of the > application. No OPTIONS forking is happening in this case, no > registered contacts. No issue? > > In reality what the B2BUA will do with the OPTION request > (forward or answer) depends on the fantasy of the B2BUA developer. > > I dont think this scenario is actually usefull in discussing > whether or not to write a BCP on OPTIONS handling. Or maybe > it is as implication of B2BUA behaviours can be taken into account. > > /Hans Erik van Elburg > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > wrote: > > > I agree with Dale. What happens to an OPTIONS request > will not necessarily be reflected when an INVITE request is > sent shortly afterwards. As a further examples, in contact > centres, it is usual to distribute calls cyclically or > randomly between qualified and available agents. Sending an > INVITE request to a UA determined by responses to an OPTIONS > request would break that model - the issuer of the OPTIONS > and INVITE requests cannot be expected to obey the same > rotation rules as the domain proxy that routes INVITE > requests. Issuing an INVITE request to the AOR is unlikely to > result in it being delivered to the UA that might be expected > from analysis of responses to an OPTIONS request. > > I don't think we should work on trying to make OPTIONS > work for this purpose. If we really need to do anything with > OPTIONS, we should just issue warnings about its > unsuitability for purposes other than a simple ping. > > John > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org= ] On Behalf Of > WORLEY, DALE R (DALE) > > Sent: 06 April 2010 21:01 > > To: Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > ________________________________________ > > > From: sipcore-bounces@ietf.org [= sipcore-bounces@ietf.org] On > > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson.com] > > Sent: Thursday, April 01, 2010 3:36 AM > > > > A good mechanism to discovery UA capabilities is essential to > > provide meaningful service: > > So I am in favor of pursuing the work, > > in particular the possibility to use a single OPTIONS request > > to retrieve the capabilities from ALL UAS(s) behind a > forking proxy. > > _______________________________________ > > > > I think it is a misconception to use UA discovery to provide > > services. The difficulty is that the set of available UAs > > for a given destination URI changes unpredictably -- elements > > become inacessible (mobile phone out of range!), call routing > > changes due to time of day, etc. Instead, SIP provides a > > remarkably effective system for selecting the best target of > > a call *at the moment the call is initiated* -- the caller > > declares his preferences, and the various intermediate > > elements combine the caller's desires with the routing > > information that they possess to forward the call closer to > > the preferred destination. > > > > As a developer, I've had to wrestle with this. In order to > > provide clean "Is extension 1234 busy?" information, our "BLF > > agent" maintains subscriptions to the "reg" event package for > > the AOR "sip:1234@example.com > > ". For = each reported contact > > for the AOR, it maintains a dialog subscription to the > > contact. Only by tracking the "reg" events can it keep track > > of the UAs available for that AOR. And even then, it is at > > the mercy of network failures. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7C978ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
The forking proxy can also have policies what it= =20 returns in the 3xx, depending on what the end-users actually=20 represent.
 
And, also with other mechanisms the returned dat= a per=20 end-user may depend on what type of end-point it represents. I don't think = that=20 is bound to a specific mechanism as such.
 
Regards,
 
Christer
 
 
 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van=20 Elburg
Sent: 7. huhtikuuta 2010 12:18
To: Elwell,=20 John
Cc: WORLEY, DALE R (DALE); sipcore@ietf.org
Subject:= =20 Re: [sipcore] SIP OPTIONS: Shall we work on this?

Of course you can implement all kind of policies, but that mak= es=20 this AOR quite of a special user. I would argue that this is some kind of= =20 service AOR and not a "normal" user AOR. The service AOR representing a g= roup=20 of different and dynamically changing users...

Demonstrating that = this=20 is not a "normal" user.

I expect that in practice one would solve = this=20 differently... making the case rather artificial.

/Han= s Erik=20 van Elburg

On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John <john.elwell@siemens-en= terprise.com>=20 wrote:


> -----Original Message-----
> From: H= ans=20 Erik van Elburg [mailto:ietf.hanserik@gmail.com]>=20 Sent: 07 April 2010 08:24
> To: Elwell, John
> Cc: WORLEY, = DALE=20 R (DALE); Salvatore Loreto; sipcore@ietf.org
> Subject: = Re:=20 [sipcore] SIP OPTIONS: Shall we work on this?
>
> This is a special case. And the application you ar= e=20 talking
> about is a B2BUA, right?
[JRE] Not necessarily= . A=20 proxy can be scripted to cycle between multiple registered contacts. Th= is=20 doesn't make it a B2BUA.

John

>
> In this case the AOR addressed is an=20 application address
> without registered contacts. One can argue = that=20 the OPTIONS
> request should return the general capabilities of=20 the
> application. No OPTIONS forking is happening in this case,= =20 no
> registered contacts. No issue?
>
> In reality wh= at=20 the B2BUA will do with the OPTION request
> (forward or answer)=20 depends on the fantasy of the B2BUA developer.
>
> I dont t= hink=20 this scenario is actually usefull in discussing
> whether or not = to=20 write a BCP on OPTIONS handling. Or maybe
> it is as implication = of=20 B2BUA behaviours can be taken into account.
>
> /Hans Erik = van=20 Elburg
>
>
>
> On Wed, Apr 7, 2010 at 8:31 AM,= =20 Elwell, John
> <john.elwell@siemens-= enterprise.com>=20 wrote:
>
>
>       I agree with Dale. = What=20 happens to an OPTIONS request
> will not necessarily be reflected= when=20 an INVITE request is
> sent shortly afterwards. As a further exam= ples,=20 in contact
> centres, it is usual to distribute calls cyclically= =20 or
> randomly between qualified and available agents. Sending=20 an
> INVITE request to a UA determined by responses to an=20 OPTIONS
> request would break that model - the issuer of the=20 OPTIONS
> and INVITE requests cannot be expected to obey the=20 same
> rotation rules as the domain proxy that routes INVITE
&= gt;=20 requests. Issuing an INVITE request to the AOR is unlikely to
> r= esult=20 in it being delivered to the UA that might be expected
> from ana= lysis=20 of responses to an OPTIONS request.
>
>      = ; I=20 don't think we should work on trying to make OPTIONS
> work for t= his=20 purpose. If we really need to do anything with
> OPTIONS, we shou= ld=20 just issue warnings about its
> unsuitability for purposes other = than=20 a simple ping.
>
>      =20 John
>
>
>
>       > -----Ori= ginal=20 Message-----
>       > From: sipcore-bounces@ietf.org>
>=20       > [mailto:sipcore-bounces@ietf.org] = On=20 Behalf Of
> WORLEY, DALE R (DALE)
>       &g= t;=20 Sent: 06 April 2010 21:01
>       > To: Salvato= re=20 Loreto; sipcore@ietf.org
>= ;=20       > Subject: Re: [sipcore] SIP OPTIONS: Shall we = work=20 on this?
>       >
>      = >=20 ________________________________________
>
>    = =20   > From: sipcore-bounces@ietf.org [= sipcore-bounces@ietf.org]= =20 On
>       > Behalf Of Salvatore Loreto [salvatore.loreto@ericsson= .com]
>=20       > Sent: Thursday, April 01, 2010 3:36 AM
>= ;=20       >
>       > A good mech= anism=20 to discovery UA capabilities is essential to
>     &nbs= p;=20 > provide meaningful service:
>       > So I= am=20 in favor of pursuing the work,
>       > in=20 particular the possibility to use a single OPTIONS request
> &nbs= p;=20     > to retrieve the capabilities from ALL UAS(s) behind= =20 a
> forking proxy.
>       >=20 _______________________________________
>      =20 >
>       > I think it is a misconception to= use=20 UA discovery to provide
>       > services.=20  The difficulty is that the set of available UAs
>   &n= bsp;=20   > for a given destination URI changes unpredictably --=20 elements
>       > become inacessible (mobile p= hone=20 out of range!), call routing
>       > changes = due=20 to time of day, etc.  Instead, SIP provides a
>    = ;=20   > remarkably effective system for selecting the best target=20 of
>       > a call *at the moment the call is= =20 initiated* -- the caller
>       > declares his= =20 preferences, and the various intermediate
>       = >=20 elements combine the caller's desires with the routing
>   &= nbsp;=20   > information that they possess to forward the call closer=20 to
>       > the preferred destination.
>= =20       >
>       > As a develo= per,=20 I've had to wrestle with this.  In order to
>    = =20   > provide clean "Is extension 1234 busy?" information, our=20 "BLF
>       > agent" maintains subscriptions t= o the=20 "reg" event package for
>       > the AOR "sip:1234@example.com
>=20 <mailto:sip%3A1234@example.com>= ".=20  For each reported contact
>       > for the AOR, it maintain= s a=20 dialog subscription to the
>       > contact.=20  Only by tracking the "reg" events can it keep track
>  = ;=20     > of the UAs available for that AOR.  And even th= en,=20 it is at
>       > the mercy of network=20 failures.
>       >
>      = ;=20 > Dale
>       >=20 _______________________________________________
>     &= nbsp;=20 > sipcore mailing list
>       > sipcore@ietf.org
>   &n= bsp;=20   > https://www.ietf.org/mailman/listinfo/sipcore
&g= t;=20       >
>      =20 _______________________________________________
>     &= nbsp;=20 sipcore mailing list
>       sipcore@ietf.org
>   &n= bsp;=20   https://www.ietf.org/mailman/listinfo/sipcore
&g= t;
>
>
>=20

--_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7C978ESESSCMS0354e_-- From john.elwell@siemens-enterprise.com Wed Apr 7 04:04:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19AC3A6A1C for ; Wed, 7 Apr 2010 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH1k-tOgJJSb for ; Wed, 7 Apr 2010 04:04:15 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9986C3A68C7 for ; Wed, 7 Apr 2010 04:04:14 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1466664; Wed, 7 Apr 2010 13:04:10 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4AFF51EB82B6; Wed, 7 Apr 2010 13:04:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 7 Apr 2010 13:04:10 +0200 From: "Elwell, John" To: Christer Holmberg , Hans Erik van Elburg Date: Wed, 7 Apr 2010 13:04:09 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4A= Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 11:04:16 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 07 April 2010 11:26 > To: Hans Erik van Elburg; Elwell, John > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? >=20 > Hi, > =20 > The forking proxy can also have policies what it returns in=20 > the 3xx, depending on what the end-users actually represent. > =20 > And, also with other mechanisms the returned data per=20 > end-user may depend on what type of end-point it represents.=20 > I don't think that is bound to a specific mechanism as such. [JRE] Quite true. But Dale's point still holds - you might as well just sen= d the INVITE request and see what happens. John > =20 > Regards, > =20 > Christer > =20 > =20 > =20 >=20 >=20 > ________________________________ >=20 > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 7. huhtikuuta 2010 12:18 > To: Elwell, John > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > =09 > =09 > Of course you can implement all kind of policies, but=20 > that makes this AOR quite of a special user. I would argue=20 > that this is some kind of service AOR and not a "normal" user=20 > AOR. The service AOR representing a group of different and=20 > dynamically changing users... > =09 > Demonstrating that this is not a "normal" user. > =09 > I expect that in practice one would solve this=20 > differently... making the case rather artificial. > =09 > /Hans Erik van Elburg > =09 > =09 > On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John=20 > wrote: > =09 >=20 >=20 >=20 > > -----Original Message----- > > From: Hans Erik van Elburg=20 > [mailto:ietf.hanserik@gmail.com] > > Sent: 07 April 2010 08:24 > > To: Elwell, John > > Cc: WORLEY, DALE R (DALE); Salvatore Loreto;=20 > sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we=20 > work on this? > > > =09 > > This is a special case. And the application=20 > you are talking > > about is a B2BUA, right? > =09 > [JRE] Not necessarily. A proxy can be scripted=20 > to cycle between multiple registered contacts. This doesn't=20 > make it a B2BUA. > =09 > John > =09 >=20 > > > > In this case the AOR addressed is an=20 > application address > > without registered contacts. One can argue=20 > that the OPTIONS > > request should return the general capabilities of the > > application. No OPTIONS forking is happening=20 > in this case, no > > registered contacts. No issue? > > > > In reality what the B2BUA will do with the=20 > OPTION request > > (forward or answer) depends on the fantasy of=20 > the B2BUA developer. > > > > I dont think this scenario is actually=20 > usefull in discussing > > whether or not to write a BCP on OPTIONS=20 > handling. Or maybe > > it is as implication of B2BUA behaviours can=20 > be taken into account. > > > > /Hans Erik van Elburg > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > wrote: > > > > > > I agree with Dale. What happens to an=20 > OPTIONS request > > will not necessarily be reflected when an=20 > INVITE request is > > sent shortly afterwards. As a further=20 > examples, in contact > > centres, it is usual to distribute calls cyclically or > > randomly between qualified and available=20 > agents. Sending an > > INVITE request to a UA determined by=20 > responses to an OPTIONS > > request would break that model - the issuer=20 > of the OPTIONS > > and INVITE requests cannot be expected to=20 > obey the same > > rotation rules as the domain proxy that routes INVITE > > requests. Issuing an INVITE request to the=20 > AOR is unlikely to > > result in it being delivered to the UA that=20 > might be expected > > from analysis of responses to an OPTIONS request. > > > > I don't think we should work on trying=20 > to make OPTIONS > > work for this purpose. If we really need to=20 > do anything with > > OPTIONS, we should just issue warnings about its > > unsuitability for purposes other than a simple ping. > > > > John > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > WORLEY, DALE R (DALE) > > > Sent: 06 April 2010 21:01 > > > To: Salvatore Loreto; sipcore@ietf.org > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > Shall we work on this? > > > > > > ________________________________________ > > > > > From: sipcore-bounces@ietf.org=20 > [sipcore-bounces@ietf.org] On > > > Behalf Of Salvatore Loreto=20 > [salvatore.loreto@ericsson.com] > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > A good mechanism to discovery UA=20 > capabilities is essential to > > > provide meaningful service: > > > So I am in favor of pursuing the work, > > > in particular the possibility to use=20 > a single OPTIONS request > > > to retrieve the capabilities from ALL=20 > UAS(s) behind a > > forking proxy. > > > _______________________________________ > > > > > > I think it is a misconception to use=20 > UA discovery to provide > > > services. The difficulty is that the=20 > set of available UAs > > > for a given destination URI changes=20 > unpredictably -- elements > > > become inacessible (mobile phone out=20 > of range!), call routing > > > changes due to time of day, etc. =20 > Instead, SIP provides a > > > remarkably effective system for=20 > selecting the best target of > > > a call *at the moment the call is=20 > initiated* -- the caller > > > declares his preferences, and the=20 > various intermediate > > > elements combine the caller's desires=20 > with the routing > > > information that they possess to=20 > forward the call closer to > > > the preferred destination. > > > > > > As a developer, I've had to wrestle=20 > with this. In order to > > > provide clean "Is extension 1234=20 > busy?" information, our "BLF > > > agent" maintains subscriptions to the=20 > "reg" event package for > > > the AOR "sip:1234@example.com=20 > =20 > =09 > > > ". For each reported contact > =09 > > > for the AOR, it maintains a dialog=20 > subscription to the > > > contact. Only by tracking the "reg"=20 > events can it keep track > > > of the UAs available for that AOR. =20 > And even then, it is at > > > the mercy of network failures. > > > > > > Dale > > >=20 > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > >=20 >=20 >=20 > = From christer.holmberg@ericsson.com Wed Apr 7 04:08:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7348A3A68AF for ; Wed, 7 Apr 2010 04:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2V2JX1X36CH for ; Wed, 7 Apr 2010 04:08:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A17373A6881 for ; Wed, 7 Apr 2010 04:08:38 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-15-4bbc67b25ac0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A0.AF.23740.2B76CBB4; Wed, 7 Apr 2010 13:08:34 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 13:08:34 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 7 Apr 2010 13:08:33 +0200 From: Christer Holmberg To: "Elwell, John" , Hans Erik van Elburg Date: Wed, 7 Apr 2010 13:08:33 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQA== Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 11:08:40 -0000 Hi,=20 >>The forking proxy can also have policies what it returns in the 3xx,=20 >>depending on what the end-users actually represent. >> =20 >>And, also with other mechanisms the returned data per end-user may=20 >>depend on what type of end-point it represents. >>I don't think that is bound to a specific mechanism as such. >[JRE] Quite true. But Dale's point still holds - you might as well just se= nd the INVITE request and see what happens. Of course. But, as I said, that is really bad protocol design, and it may t= rigger unwanted resource reservation actions etc in the network. And, there could even be cases where the INVITE doesn't fail, but you don't= get the optimized user experience since the request may have looked differ= ent should you have known what the receiver supports. Regards, Christer > > ________________________________ > >=20 > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > > Sent: 7. huhtikuuta 2010 12:18 > > To: Elwell, John > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > =09 > > =09 > > Of course you can implement all kind of policies, but=20 > > that makes this AOR quite of a special user. I would argue=20 > > that this is some kind of service AOR and not a "normal" user=20 > > AOR. The service AOR representing a group of different and=20 > > dynamically changing users... > > =09 > > Demonstrating that this is not a "normal" user. > > =09 > > I expect that in practice one would solve this=20 > > differently... making the case rather artificial. > > =09 > > /Hans Erik van Elburg > > =09 > > =09 > > On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John=20 > > wrote: > > =09 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Hans Erik van Elburg=20 > > [mailto:ietf.hanserik@gmail.com] > > > Sent: 07 April 2010 08:24 > > > To: Elwell, John > > > Cc: WORLEY, DALE R (DALE); Salvatore Loreto;=20 > > sipcore@ietf.org > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we=20 > > work on this? > > > > > =09 > > > This is a special case. And the application=20 > > you are talking > > > about is a B2BUA, right? > > =09 > > [JRE] Not necessarily. A proxy can be scripted=20 > > to cycle between multiple registered contacts. This doesn't=20 > > make it a B2BUA. > > =09 > > John > > =09 > >=20 > > > > > > In this case the AOR addressed is an=20 > > application address > > > without registered contacts. One can argue=20 > > that the OPTIONS > > > request should return the general capabilities of the > > > application. No OPTIONS forking is happening=20 > > in this case, no > > > registered contacts. No issue? > > > > > > In reality what the B2BUA will do with the=20 > > OPTION request > > > (forward or answer) depends on the fantasy of=20 > > the B2BUA developer. > > > > > > I dont think this scenario is actually=20 > > usefull in discussing > > > whether or not to write a BCP on OPTIONS=20 > > handling. Or maybe > > > it is as implication of B2BUA behaviours can=20 > > be taken into account. > > > > > > /Hans Erik van Elburg > > > > > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > > wrote: > > > > > > > > > I agree with Dale. What happens to an=20 > > OPTIONS request > > > will not necessarily be reflected when an=20 > > INVITE request is > > > sent shortly afterwards. As a further=20 > > examples, in contact > > > centres, it is usual to distribute calls cyclically or > > > randomly between qualified and available=20 > > agents. Sending an > > > INVITE request to a UA determined by=20 > > responses to an OPTIONS > > > request would break that model - the issuer=20 > > of the OPTIONS > > > and INVITE requests cannot be expected to=20 > > obey the same > > > rotation rules as the domain proxy that routes INVITE > > > requests. Issuing an INVITE request to the=20 > > AOR is unlikely to > > > result in it being delivered to the UA that=20 > > might be expected > > > from analysis of responses to an OPTIONS request. > > > > > > I don't think we should work on trying=20 > > to make OPTIONS > > > work for this purpose. If we really need to=20 > > do anything with > > > OPTIONS, we should just issue warnings about its > > > unsuitability for purposes other than a simple ping. > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > WORLEY, DALE R (DALE) > > > > Sent: 06 April 2010 21:01 > > > > To: Salvatore Loreto; sipcore@ietf.org > > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > > Shall we work on this? > > > > > > > > ________________________________________ > > > > > > > From: sipcore-bounces@ietf.org=20 > > [sipcore-bounces@ietf.org] On > > > > Behalf Of Salvatore Loreto=20 > > [salvatore.loreto@ericsson.com] > > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > > > A good mechanism to discovery UA=20 > > capabilities is essential to > > > > provide meaningful service: > > > > So I am in favor of pursuing the work, > > > > in particular the possibility to use=20 > > a single OPTIONS request > > > > to retrieve the capabilities from ALL=20 > > UAS(s) behind a > > > forking proxy. > > > > _______________________________________ > > > > > > > > I think it is a misconception to use=20 > > UA discovery to provide > > > > services. The difficulty is that the=20 > > set of available UAs > > > > for a given destination URI changes=20 > > unpredictably -- elements > > > > become inacessible (mobile phone out=20 > > of range!), call routing > > > > changes due to time of day, etc. =20 > > Instead, SIP provides a > > > > remarkably effective system for=20 > > selecting the best target of > > > > a call *at the moment the call is=20 > > initiated* -- the caller > > > > declares his preferences, and the=20 > > various intermediate > > > > elements combine the caller's desires=20 > > with the routing > > > > information that they possess to=20 > > forward the call closer to > > > > the preferred destination. > > > > > > > > As a developer, I've had to wrestle=20 > > with this. In order to > > > > provide clean "Is extension 1234=20 > > busy?" information, our "BLF > > > > agent" maintains subscriptions to the=20 > > "reg" event package for > > > > the AOR "sip:1234@example.com=20 > > =20 > > =09 > > > > > ". For each reported contact > > =09 > > > > for the AOR, it maintains a dialog=20 > > subscription to the > > > > contact. Only by tracking the "reg"=20 > > events can it keep track > > > > of the UAs available for that AOR. =20 > > And even then, it is at > > > > the mercy of network failures. > > > > > > > > Dale > > > >=20 > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > >=20 > >=20 > >=20 > > = From peter.musgrave@magorcorp.com Wed Apr 7 04:30:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD55F3A6AA2 for ; Wed, 7 Apr 2010 04:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMw-p5uI6Fev for ; Wed, 7 Apr 2010 04:29:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 71DD33A694F for ; Wed, 7 Apr 2010 04:29:59 -0700 (PDT) Received: by gyh4 with SMTP id 4so530629gyh.31 for ; Wed, 07 Apr 2010 04:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.13 with HTTP; Wed, 7 Apr 2010 04:29:53 -0700 (PDT) In-Reply-To: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> Date: Wed, 7 Apr 2010 07:29:53 -0400 Received: by 10.101.175.39 with SMTP id c39mr18093663anp.164.1270639793772; Wed, 07 Apr 2010 04:29:53 -0700 (PDT) Message-ID: From: Peter Musgrave To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 11:30:01 -0000 Hi, So in the interests of good protocol design... Should we recap the different use cases we want this behaviour for? Some cases may fall into the 'just send an INVITE camp' and others which may be probing for support of event packages or specific media capabilities and sending an INVITE is not helpful. I had at first liked the idea but of using reg-events for some of this - but endpoints which disappear (and do not expire their registration) will not be reported absent until the next refresh cycle - which makes that approach not usable IMHO. Use cases I can (personally) see wanting: - basic fork to see IF there even are multiple UAs at the AOR (and get their gruus so a specific UA can subsequently be called, subscribed to etc.)) - gather event support and media capabilities of the UAs - others? Peter On Wed, Apr 7, 2010 at 7:08 AM, Christer Holmberg wrote: > > Hi, > >>>The forking proxy can also have policies what it returns in the 3xx, >>>depending on what the end-users actually represent. >>> >>>And, also with other mechanisms the returned data per end-user may >>>depend on what type of end-point it represents. >>>I don't think that is bound to a specific mechanism as such. >>[JRE] Quite true. But Dale's point still holds - you might as well just s= end the INVITE request and see what happens. > > Of course. But, as I said, that is really bad protocol design, and it may= trigger unwanted resource reservation actions etc in the network. > > And, there could even be cases where the INVITE doesn't fail, but you don= 't get the optimized user experience since the request may have looked diff= erent should you have known what the receiver supports. > > Regards, > > Christer > > > > > > > >> > ________________________________ >> > >> > =A0 =A0 From: sipcore-bounces@ietf.org >> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg >> > =A0 =A0 Sent: 7. huhtikuuta 2010 12:18 >> > =A0 =A0 To: Elwell, John >> > =A0 =A0 Cc: WORLEY, DALE R (DALE); sipcore@ietf.org >> > =A0 =A0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >> > >> > >> > =A0 =A0 Of course you can implement all kind of policies, but >> > that makes this AOR quite of a special user. I would argue >> > that this is some kind of service AOR and not a "normal" user >> > AOR. The service AOR representing a group of different and >> > dynamically changing users... >> > >> > =A0 =A0 Demonstrating that this is not a "normal" user. >> > >> > =A0 =A0 I expect that in practice one would solve this >> > differently... making the case rather artificial. >> > >> > =A0 =A0 /Hans Erik van Elburg >> > >> > >> > =A0 =A0 On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John >> > wrote: >> > >> > >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 > -----Original Message----- >> > =A0 =A0 =A0 =A0 =A0 =A0 > From: Hans Erik van Elburg >> > [mailto:ietf.hanserik@gmail.com] >> > =A0 =A0 =A0 =A0 =A0 =A0 > Sent: 07 April 2010 08:24 >> > =A0 =A0 =A0 =A0 =A0 =A0 > To: Elwell, John >> > =A0 =A0 =A0 =A0 =A0 =A0 > Cc: WORLEY, DALE R (DALE); Salvatore Loreto; >> > sipcore@ietf.org >> > =A0 =A0 =A0 =A0 =A0 =A0 > Subject: Re: [sipcore] SIP OPTIONS: Shall we >> > work on this? >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 > This is a special case. And the application >> > you are talking >> > =A0 =A0 =A0 =A0 =A0 =A0 > about is a B2BUA, right? >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 [JRE] Not necessarily. A proxy can be scripted >> > to cycle between multiple registered contacts. This doesn't >> > make it a B2BUA. >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 John >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > In this case the AOR addressed is an >> > application address >> > =A0 =A0 =A0 =A0 =A0 =A0 > without registered contacts. One can argue >> > that the OPTIONS >> > =A0 =A0 =A0 =A0 =A0 =A0 > request should return the general capabiliti= es of the >> > =A0 =A0 =A0 =A0 =A0 =A0 > application. No OPTIONS forking is happening >> > in this case, no >> > =A0 =A0 =A0 =A0 =A0 =A0 > registered contacts. No issue? >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > In reality what the B2BUA will do with the >> > OPTION request >> > =A0 =A0 =A0 =A0 =A0 =A0 > (forward or answer) depends on the fantasy o= f >> > the B2BUA developer. >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > I dont think this scenario is actually >> > usefull in discussing >> > =A0 =A0 =A0 =A0 =A0 =A0 > whether or not to write a BCP on OPTIONS >> > handling. Or maybe >> > =A0 =A0 =A0 =A0 =A0 =A0 > it is as implication of B2BUA behaviours can >> > be taken into account. >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > /Hans Erik van Elburg >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John >> > =A0 =A0 =A0 =A0 =A0 =A0 > wrote: >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 I agree with Dale. What happens = to an >> > OPTIONS request >> > =A0 =A0 =A0 =A0 =A0 =A0 > will not necessarily be reflected when an >> > INVITE request is >> > =A0 =A0 =A0 =A0 =A0 =A0 > sent shortly afterwards. As a further >> > examples, in contact >> > =A0 =A0 =A0 =A0 =A0 =A0 > centres, it is usual to distribute calls cyc= lically or >> > =A0 =A0 =A0 =A0 =A0 =A0 > randomly between qualified and available >> > agents. Sending an >> > =A0 =A0 =A0 =A0 =A0 =A0 > INVITE request to a UA determined by >> > responses to an OPTIONS >> > =A0 =A0 =A0 =A0 =A0 =A0 > request would break that model - the issuer >> > of the OPTIONS >> > =A0 =A0 =A0 =A0 =A0 =A0 > and INVITE requests cannot be expected to >> > obey the same >> > =A0 =A0 =A0 =A0 =A0 =A0 > rotation rules as the domain proxy that rout= es INVITE >> > =A0 =A0 =A0 =A0 =A0 =A0 > requests. Issuing an INVITE request to the >> > AOR is unlikely to >> > =A0 =A0 =A0 =A0 =A0 =A0 > result in it being delivered to the UA that >> > might be expected >> > =A0 =A0 =A0 =A0 =A0 =A0 > from analysis of responses to an OPTIONS req= uest. >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 I don't think we should work on = trying >> > to make OPTIONS >> > =A0 =A0 =A0 =A0 =A0 =A0 > work for this purpose. If we really need to >> > do anything with >> > =A0 =A0 =A0 =A0 =A0 =A0 > OPTIONS, we should just issue warnings about= its >> > =A0 =A0 =A0 =A0 =A0 =A0 > unsuitability for purposes other than a simp= le ping. >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 John >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Message----- >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > From: sipcore-bounces@ietf.org >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > [mailto:sipcore-bounces@ietf.o= rg] On Behalf Of >> > =A0 =A0 =A0 =A0 =A0 =A0 > WORLEY, DALE R (DALE) >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: 06 April 2010 21:01 >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > To: Salvatore Loreto; sipcore@= ietf.org >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [sipcore] SIP OPT= IONS: >> > Shall we work on this? >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > ______________________________= __________ >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > From: sipcore-bounces@ietf.org >> > [sipcore-bounces@ietf.org] On >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Behalf Of Salvatore Loreto >> > [salvatore.loreto@ericsson.com] >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Thursday, April 01, 2010= 3:36 AM >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > A good mechanism to discovery = UA >> > capabilities is essential to >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > provide meaningful service: >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > So I am in favor of pursuing t= he work, >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > in particular the possibility = to use >> > a single OPTIONS request >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > to retrieve the capabilities f= rom ALL >> > UAS(s) behind a >> > =A0 =A0 =A0 =A0 =A0 =A0 > forking proxy. >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > ______________________________= _________ >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > I think it is a misconception = to use >> > UA discovery to provide >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > services. =A0The difficulty is= that the >> > set of available UAs >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > for a given destination URI ch= anges >> > unpredictably -- elements >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > become inacessible (mobile pho= ne out >> > of range!), call routing >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > changes due to time of day, et= c. >> > Instead, SIP provides a >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > remarkably effective system fo= r >> > selecting the best target of >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > a call *at the moment the call= is >> > initiated* -- the caller >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > declares his preferences, and = the >> > various intermediate >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > elements combine the caller's = desires >> > with the routing >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > information that they possess = to >> > forward the call closer to >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the preferred destination. >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > As a developer, I've had to wr= estle >> > with this. =A0In order to >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > provide clean "Is extension 12= 34 >> > busy?" information, our "BLF >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > agent" maintains subscriptions= to the >> > "reg" event package for >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the AOR "sip:1234@example.com >> > >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > > > ". =A0For each reported contact >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > for the AOR, it maintains a di= alog >> > subscription to the >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > contact. =A0Only by tracking t= he "reg" >> > events can it keep track >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > of the UAs available for that = AOR. >> > And even then, it is at >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the mercy of network failures. >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Dale >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > _______________________________________________ >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > sipcore mailing list >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > sipcore@ietf.org >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > https://www.ietf.org/mailman/l= istinfo/sipcore >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 ________________________________= _______________ >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 sipcore mailing list >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 sipcore@ietf.org >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mailman/lis= tinfo/sipcore >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > >> > >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Apr 7 04:35:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3CF3A6A8D for ; Wed, 7 Apr 2010 04:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K1J-mzvxsUp for ; Wed, 7 Apr 2010 04:35:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2A68B3A694F for ; Wed, 7 Apr 2010 04:35:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-99-4bbc6e05101f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A4.A4.23532.50E6CBB4; Wed, 7 Apr 2010 13:35:33 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 7 Apr 2010 13:35:33 +0200 From: Christer Holmberg To: Peter Musgrave Date: Wed, 7 Apr 2010 13:35:33 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWRacYm7Uk4xfgQYyadYVqJsDQVgAAFTxA Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 11:35:41 -0000 Hi, The use-case to gather capabilities of an UAS is already there - I assume t= hat's the reason OPTIONS was added in the first place :) What we are discussing is simply to get the capabilities in the forking cas= e, when there are multiple UASs associated with the AOR. So, I am simply trying to make an existing capability usable for the the fo= rking case. Nothing more - nothing less :) If we don't like OPTIONS, let's deprecate it... Having methods and function= s, but at the same time saying that it doesn't work and we therefor shouldn= 't use it, is very confusing... Regards, Christer =20 > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 > Sent: 7. huhtikuuta 2010 14:30 > To: Christer Holmberg > Cc: Elwell, John; Hans Erik van Elburg; WORLEY, DALE R=20 > (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 > Hi, >=20 > So in the interests of good protocol design... >=20 > Should we recap the different use cases we want this behaviour for? >=20 > Some cases may fall into the 'just send an INVITE camp' and=20 > others which may be probing for support of event packages or=20 > specific media capabilities and sending an INVITE is not helpful. >=20 > I had at first liked the idea but of using reg-events for some of this > - but endpoints which disappear (and do not expire their=20 > registration) will not be reported absent until the next=20 > refresh cycle - which makes that approach not usable IMHO. >=20 > Use cases I can (personally) see wanting: > - basic fork to see IF there even are multiple UAs at the AOR=20 > (and get their gruus so a specific UA can subsequently be=20 > called, subscribed to > etc.)) > - gather event support and media capabilities of the UAs > - others? >=20 >=20 > Peter >=20 > On Wed, Apr 7, 2010 at 7:08 AM, Christer Holmberg=20 > wrote: > > > > Hi, > > > >>>The forking proxy can also have policies what it returns=20 > in the 3xx,=20 > >>>depending on what the end-users actually represent. > >>> > >>>And, also with other mechanisms the returned data per end-user may=20 > >>>depend on what type of end-point it represents. > >>>I don't think that is bound to a specific mechanism as such. > >>[JRE] Quite true. But Dale's point still holds - you might=20 > as well just send the INVITE request and see what happens. > > > > Of course. But, as I said, that is really bad protocol=20 > design, and it may trigger unwanted resource reservation=20 > actions etc in the network. > > > > And, there could even be cases where the INVITE doesn't=20 > fail, but you don't get the optimized user experience since=20 > the request may have looked different should you have known=20 > what the receiver supports. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > >> > ________________________________ > >> > > >> > =A0 =A0 From: sipcore-bounces@ietf.org > >> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik=20 > van Elburg > >> > =A0 =A0 Sent: 7. huhtikuuta 2010 12:18 > >> > =A0 =A0 To: Elwell, John > >> > =A0 =A0 Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > >> > =A0 =A0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > >> > > >> > > >> > =A0 =A0 Of course you can implement all kind of policies, but that=20 > >> > makes this AOR quite of a special user. I would argue=20 > that this is=20 > >> > some kind of service AOR and not a "normal" user AOR.=20 > The service=20 > >> > AOR representing a group of different and dynamically changing=20 > >> > users... > >> > > >> > =A0 =A0 Demonstrating that this is not a "normal" user. > >> > > >> > =A0 =A0 I expect that in practice one would solve this=20 > differently...=20 > >> > making the case rather artificial. > >> > > >> > =A0 =A0 /Hans Erik van Elburg > >> > > >> > > >> > =A0 =A0 On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John=20 > >> > wrote: > >> > > >> > > >> > > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > -----Original Message----- > >> > =A0 =A0 =A0 =A0 =A0 =A0 > From: Hans Erik van Elburg=20 > >> > [mailto:ietf.hanserik@gmail.com] > >> > =A0 =A0 =A0 =A0 =A0 =A0 > Sent: 07 April 2010 08:24 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > To: Elwell, John > >> > =A0 =A0 =A0 =A0 =A0 =A0 > Cc: WORLEY, DALE R (DALE); Salvatore Loret= o;=20 > >> > sipcore@ietf.org > >> > =A0 =A0 =A0 =A0 =A0 =A0 > Subject: Re: [sipcore] SIP OPTIONS: Shall= =20 > we work on=20 > >> > this? > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > This is a special case. And the=20 > application you are=20 > >> > talking > >> > =A0 =A0 =A0 =A0 =A0 =A0 > about is a B2BUA, right? > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 [JRE] Not necessarily. A proxy can be=20 > scripted to cycle=20 > >> > between multiple registered contacts. This doesn't make=20 > it a B2BUA. > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 John > >> > > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > In this case the AOR addressed is an appli= cation=20 > >> > address > >> > =A0 =A0 =A0 =A0 =A0 =A0 > without registered contacts. One can argue= =20 > that the=20 > >> > OPTIONS > >> > =A0 =A0 =A0 =A0 =A0 =A0 > request should return the general=20 > capabilities of the > >> > =A0 =A0 =A0 =A0 =A0 =A0 > application. No OPTIONS forking is=20 > happening in this=20 > >> > case, no > >> > =A0 =A0 =A0 =A0 =A0 =A0 > registered contacts. No issue? > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > In reality what the B2BUA will do with the= OPTION=20 > >> > request > >> > =A0 =A0 =A0 =A0 =A0 =A0 > (forward or answer) depends on the fantasy= of the=20 > >> > B2BUA developer. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > I dont think this scenario is actually use= full in=20 > >> > discussing > >> > =A0 =A0 =A0 =A0 =A0 =A0 > whether or not to write a BCP on OPTIONS=20 > handling. Or=20 > >> > maybe > >> > =A0 =A0 =A0 =A0 =A0 =A0 > it is as implication of B2BUA behaviours=20 > can be taken=20 > >> > into account. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > /Hans Erik van Elburg > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, Jo= hn > >> > =A0 =A0 =A0 =A0 =A0 =A0 > wrote= : > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 I agree with Dale. What happen= s to=20 > an OPTIONS=20 > >> > request > >> > =A0 =A0 =A0 =A0 =A0 =A0 > will not necessarily be reflected when an = INVITE=20 > >> > request is > >> > =A0 =A0 =A0 =A0 =A0 =A0 > sent shortly afterwards. As a further exam= ples, in=20 > >> > contact > >> > =A0 =A0 =A0 =A0 =A0 =A0 > centres, it is usual to distribute calls=20 > cyclically=20 > >> > or > >> > =A0 =A0 =A0 =A0 =A0 =A0 > randomly between qualified and available a= gents.=20 > >> > Sending an > >> > =A0 =A0 =A0 =A0 =A0 =A0 > INVITE request to a UA determined by=20 > responses to an=20 > >> > OPTIONS > >> > =A0 =A0 =A0 =A0 =A0 =A0 > request would break that model - the issue= r of the=20 > >> > OPTIONS > >> > =A0 =A0 =A0 =A0 =A0 =A0 > and INVITE requests cannot be expected to = obey the=20 > >> > same > >> > =A0 =A0 =A0 =A0 =A0 =A0 > rotation rules as the domain proxy that=20 > routes INVITE > >> > =A0 =A0 =A0 =A0 =A0 =A0 > requests. Issuing an INVITE request to the= AOR is=20 > >> > unlikely to > >> > =A0 =A0 =A0 =A0 =A0 =A0 > result in it being delivered to the UA=20 > that might be=20 > >> > expected > >> > =A0 =A0 =A0 =A0 =A0 =A0 > from analysis of responses to an OPTIONS r= equest. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 I don't think we should work o= n=20 > trying to make=20 > >> > OPTIONS > >> > =A0 =A0 =A0 =A0 =A0 =A0 > work for this purpose. If we really need t= o do=20 > >> > anything with > >> > =A0 =A0 =A0 =A0 =A0 =A0 > OPTIONS, we should just issue warnings abo= ut its > >> > =A0 =A0 =A0 =A0 =A0 =A0 > unsuitability for purposes other than a=20 > simple ping. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 John > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Message----- > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > From: sipcore-bounces@ietf.o= rg > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > [mailto:sipcore-bounces@ietf= .org]=20 > On Behalf=20 > >> > Of > >> > =A0 =A0 =A0 =A0 =A0 =A0 > WORLEY, DALE R (DALE) > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: 06 April 2010 21:01 > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > To: Salvatore Loreto; sipcor= e@ietf.org > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [sipcore] SIP O= PTIONS: > >> > Shall we work on this? > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > ____________________________= ____________ > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > From: sipcore-bounces@ietf.o= rg=20 > >> > [sipcore-bounces@ietf.org] On > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Behalf Of Salvatore Loreto=20 > >> > [salvatore.loreto@ericsson.com] > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Thursday, April 01, 20= 10 3:36 AM > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > A good mechanism to discover= y UA=20 > capabilities=20 > >> > is essential to > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > provide meaningful service: > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > So I am in favor of pursuing= the work, > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > in particular the possibilit= y to=20 > use a single=20 > >> > OPTIONS request > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > to retrieve the capabilities= from ALL > >> > UAS(s) behind a > >> > =A0 =A0 =A0 =A0 =A0 =A0 > forking proxy. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > ____________________________= ___________ > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > I think it is a misconceptio= n to use UA=20 > >> > discovery to provide > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > services. =A0The difficulty = is that=20 > the set of=20 > >> > available UAs > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > for a given destination URI = changes=20 > >> > unpredictably -- elements > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > become inacessible (mobile p= hone out of=20 > >> > range!), call routing > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > changes due to time of day, = etc. > >> > Instead, SIP provides a > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > remarkably effective system = for=20 > selecting the=20 > >> > best target of > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > a call *at the moment the ca= ll is > >> > initiated* -- the caller > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > declares his preferences, an= d the various=20 > >> > intermediate > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > elements combine the caller'= s desires with=20 > >> > the routing > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > information that they posses= s to=20 > forward the=20 > >> > call closer to > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the preferred destination. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > As a developer, I've had to = wrestle with=20 > >> > this. =A0In order to > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > provide clean "Is extension = 1234 busy?"=20 > >> > information, our "BLF > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > agent" maintains subscriptio= ns to=20 > the "reg"=20 > >> > event package for > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the AOR "sip:1234@example.co= m=20 > >> > > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > >> > > ". =A0For each reported contact > >> > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > for the AOR, it maintains a = dialog=20 > >> > subscription to the > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > contact. =A0Only by tracking= the "reg" > >> > events can it keep track > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > of the UAs available for tha= t AOR. > >> > And even then, it is at > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the mercy of network failure= s. > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Dale > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > _______________________________________________ > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > sipcore mailing list > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > sipcore@ietf.org > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >=20 > https://www.ietf.org/mailman/listinfo/sipcore > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0=20 > _______________________________________________ > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 sipcore mailing list > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 sipcore@ietf.org > >> > =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mailman/l= istinfo/sipcore > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 =A0 =A0 > > >> > > >> > > >> > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > = From brett@broadsoft.com Wed Apr 7 05:09:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1693A63C9 for ; Wed, 7 Apr 2010 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsSwiSoWJjkp for ; Wed, 7 Apr 2010 05:09:07 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D14E43A63EB for ; Wed, 7 Apr 2010 05:09:07 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 7 Apr 2010 05:09:05 -0700 From: Brett Tate To: Adam Roach , SIPCORE Date: Wed, 7 Apr 2010 05:08:16 -0700 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrV4gSIy+1BcczXQSGZNFoPbNFWkwAYVQCw Message-ID: <747A6506A991724FB09B129B79D5FEB61480C55EB5@EXMBXCLUS01.citservers.local> References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: <4BBBC58A.10407@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:09:09 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 06, 2010 7:37 PM > To: Brett Tate > Cc: Paul Kyzivat; SIPCORE > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes > Posted] >=20 > On 4/6/10 17:46, Apr 6, Brett Tate wrote: > >> Is there *any* problem here? This seems to be working about > >> as well as anyone might hope. > >> > > It works okay excluding the non backward compatibility with RFC 3265 > (concerning SUBSCRIBE's 2xx response impacts)... >=20 > I don't think it's accurate to characterize the change as > non-backwards-compatible. RFC 3265 section 3.3.4 indicates that 2xx "creates a new subscription and a= new dialog"; rfc3265bis does not allow such a thing. 3.3.4. Dialog creation and termination If an initial SUBSCRIBE request is not sent on a pre-existing dialog, the subscriber will wait for a response to the SUBSCRIBE request or a matching NOTIFY. Responses are matched to such SUBSCRIBE requests if they contain the same the same "Call-ID", the same "From" header "tag", and the same "CSeq". Rules for the comparison of these headers are described in SIP [1]. If a 200-class response matches such a SUBSCRIBE request, it creates a new subscription and a new dialog (unless they have already been created by a matching NOTIFY request; see below). > > The draft's Timer N (and lack of related NOTIFY) text is potentially > > worded in a way which does not require the tear down (and non > > creation) of subscription. >=20 > Tear-down of existing dialogs is still an open issue, sure. I don't get > where you see any wiggle room in what happens if Timer N fires for the > first SUBSCRIBE/NOTIFY exchange. That is the issue... as currently worded, there is no "wiggle room". Thus = a vendor that wants to implement rfc3265bis can't also remain compatible wi= th rfc3265 devices. And if a vendor wants to use a value other than 64*T1 = for Timer N, rfc3265bis doesn't appear to allow it. Timer N has its use. Depending upon the dialog package, some vendors imple= ment Timer N to be extremely low (such as 2-5 seconds). For other packages= , they apply Timer N (with value similar to rfc3265bis) only to dialogs bei= ng created by NOTIFY; they allow the SUBSCRIBE 2xx's Expires to be Timer N = value for the associated dialog. I actually don't have strong opinion concerning all of this. I raised the = issue mainly because the divergence from rfc3265 appears to work worse duri= ng overload situations and because frequent subscription creation/removal (= such as because Timer N expiration) can lead to or prolong overload.=20 From brett@broadsoft.com Wed Apr 7 05:27:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D853A6892 for ; Wed, 7 Apr 2010 05:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpbBuL1OrG6k for ; Wed, 7 Apr 2010 05:27:30 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 262A93A6920 for ; Wed, 7 Apr 2010 05:27:30 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 7 Apr 2010 05:27:27 -0700 From: Brett Tate To: Paul Kyzivat , SIPCORE Date: Wed, 7 Apr 2010 05:26:39 -0700 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrV38itrdre3IEVR5G5W6D2Rwy1tQAa8eHQ Message-ID: <747A6506A991724FB09B129B79D5FEB61480C55EC4@EXMBXCLUS01.citservers.local> References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC1CB.4050501@cisco.com> In-Reply-To: <4BBBC1CB.4050501@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 Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:27:31 -0000 > Then what would happen in a polling subscribe (Expires:0) if=20 > the 200 is received and the NOTIFY is not received? How long=20 > should you wait before giving up? ISTM you still need timer-N=20 > to tell you it failed, so you can give up waiting. I agree that you need a Timer N (or something like it); however Timer N sho= uld not be restricted to 64*T1. The rfc3265bis should accommodate other Ti= mer N values instead being restricted to 64*T1 for all event packages, depl= oyments, situations, etcetera. Concerning the polling/fetch (Expires: 0), it might actually be useful to c= ommunicate within SUBSCRIBE how long you are willing to wait for the NOTIFY= . For instance, there are some situation where I'm willing to wait 1-2 sec= onds; there are other situations where I'm will wait more than 64*T1 if rec= eived 2xx response. From john.elwell@siemens-enterprise.com Wed Apr 7 05:56:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1885C3A6ABA for ; Wed, 7 Apr 2010 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm20iSGaQFKU for ; Wed, 7 Apr 2010 05:56:43 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 58F7C3A6ABB for ; Wed, 7 Apr 2010 05:56:43 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1469390; Wed, 7 Apr 2010 14:56:39 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B91031EB82AB; Wed, 7 Apr 2010 14:56:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 7 Apr 2010 14:56:40 +0200 From: "Elwell, John" To: Christer Holmberg , Hans Erik van Elburg Date: Wed, 7 Apr 2010 14:56:38 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJg Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:56:45 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 07 April 2010 12:09 > To: Elwell, John; Hans Erik van Elburg > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > Hi,=20 >=20 > >>The forking proxy can also have policies what it returns in=20 > the 3xx,=20 > >>depending on what the end-users actually represent. > >> =20 > >>And, also with other mechanisms the returned data per end-user may=20 > >>depend on what type of end-point it represents. > >>I don't think that is bound to a specific mechanism as such. > >[JRE] Quite true. But Dale's point still holds - you might=20 > as well just send the INVITE request and see what happens. >=20 > Of course. But, as I said, that is really bad protocol=20 > design, [JRE] Why is it bad protocol design? > and it may trigger unwanted resource reservation=20 > actions etc in the network. [JRE] Concerning resource reservation, there are two ways of looking at it.= By doing resource reservation, you find out straight away if the resources= needed to reach the UA are not available, so resource reservation could be= considered a good thing. An OPTIONS transaction is never going to provide = this information. On the other hand, if you want to avoid resource reservat= ion, just send an offerless INVITE request. John >=20 > And, there could even be cases where the INVITE doesn't fail,=20 > but you don't get the optimized user experience since the=20 > request may have looked different should you have known what=20 > the receiver supports. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > > ________________________________ > > >=20 > > > From: sipcore-bounces@ietf.org=20 > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik=20 > van Elburg > > > Sent: 7. huhtikuuta 2010 12:18 > > > To: Elwell, John > > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > =09 > > > =09 > > > Of course you can implement all kind of policies, but=20 > > > that makes this AOR quite of a special user. I would argue=20 > > > that this is some kind of service AOR and not a "normal" user=20 > > > AOR. The service AOR representing a group of different and=20 > > > dynamically changing users... > > > =09 > > > Demonstrating that this is not a "normal" user. > > > =09 > > > I expect that in practice one would solve this=20 > > > differently... making the case rather artificial. > > > =09 > > > /Hans Erik van Elburg > > > =09 > > > =09 > > > On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John=20 > > > wrote: > > > =09 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Hans Erik van Elburg=20 > > > [mailto:ietf.hanserik@gmail.com] > > > > Sent: 07 April 2010 08:24 > > > > To: Elwell, John > > > > Cc: WORLEY, DALE R (DALE); Salvatore Loreto;=20 > > > sipcore@ietf.org > > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we=20 > > > work on this? > > > > > > > =09 > > > > This is a special case. And the application=20 > > > you are talking > > > > about is a B2BUA, right? > > > =09 > > > [JRE] Not necessarily. A proxy can be scripted=20 > > > to cycle between multiple registered contacts. This doesn't=20 > > > make it a B2BUA. > > > =09 > > > John > > > =09 > > >=20 > > > > > > > > In this case the AOR addressed is an=20 > > > application address > > > > without registered contacts. One can argue=20 > > > that the OPTIONS > > > > request should return the general capabilities of the > > > > application. No OPTIONS forking is happening=20 > > > in this case, no > > > > registered contacts. No issue? > > > > > > > > In reality what the B2BUA will do with the=20 > > > OPTION request > > > > (forward or answer) depends on the fantasy of=20 > > > the B2BUA developer. > > > > > > > > I dont think this scenario is actually=20 > > > usefull in discussing > > > > whether or not to write a BCP on OPTIONS=20 > > > handling. Or maybe > > > > it is as implication of B2BUA behaviours can=20 > > > be taken into account. > > > > > > > > /Hans Erik van Elburg > > > > > > > > > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > > > wrote: > > > > > > > > > > > > I agree with Dale. What happens to an=20 > > > OPTIONS request > > > > will not necessarily be reflected when an=20 > > > INVITE request is > > > > sent shortly afterwards. As a further=20 > > > examples, in contact > > > > centres, it is usual to distribute calls cyclically or > > > > randomly between qualified and available=20 > > > agents. Sending an > > > > INVITE request to a UA determined by=20 > > > responses to an OPTIONS > > > > request would break that model - the issuer=20 > > > of the OPTIONS > > > > and INVITE requests cannot be expected to=20 > > > obey the same > > > > rotation rules as the domain proxy that routes INVITE > > > > requests. Issuing an INVITE request to the=20 > > > AOR is unlikely to > > > > result in it being delivered to the UA that=20 > > > might be expected > > > > from analysis of responses to an OPTIONS request. > > > > > > > > I don't think we should work on trying=20 > > > to make OPTIONS > > > > work for this purpose. If we really need to=20 > > > do anything with > > > > OPTIONS, we should just issue warnings about its > > > > unsuitability for purposes other than a simple ping. > > > > > > > > John > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > WORLEY, DALE R (DALE) > > > > > Sent: 06 April 2010 21:01 > > > > > To: Salvatore Loreto; sipcore@ietf.org > > > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > > > Shall we work on this? > > > > > > > > > > ________________________________________ > > > > > > > > > From: sipcore-bounces@ietf.org=20 > > > [sipcore-bounces@ietf.org] On > > > > > Behalf Of Salvatore Loreto=20 > > > [salvatore.loreto@ericsson.com] > > > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > > > > > A good mechanism to discovery UA=20 > > > capabilities is essential to > > > > > provide meaningful service: > > > > > So I am in favor of pursuing the work, > > > > > in particular the possibility to use=20 > > > a single OPTIONS request > > > > > to retrieve the capabilities from ALL=20 > > > UAS(s) behind a > > > > forking proxy. > > > > > _______________________________________ > > > > > > > > > > I think it is a misconception to use=20 > > > UA discovery to provide > > > > > services. The difficulty is that the=20 > > > set of available UAs > > > > > for a given destination URI changes=20 > > > unpredictably -- elements > > > > > become inacessible (mobile phone out=20 > > > of range!), call routing > > > > > changes due to time of day, etc. =20 > > > Instead, SIP provides a > > > > > remarkably effective system for=20 > > > selecting the best target of > > > > > a call *at the moment the call is=20 > > > initiated* -- the caller > > > > > declares his preferences, and the=20 > > > various intermediate > > > > > elements combine the caller's desires=20 > > > with the routing > > > > > information that they possess to=20 > > > forward the call closer to > > > > > the preferred destination. > > > > > > > > > > As a developer, I've had to wrestle=20 > > > with this. In order to > > > > > provide clean "Is extension 1234=20 > > > busy?" information, our "BLF > > > > > agent" maintains subscriptions to the=20 > > > "reg" event package for > > > > > the AOR "sip:1234@example.com=20 > > > =20 > > > =09 > > > > > > > ". For each reported contact > > > =09 > > > > > for the AOR, it maintains a dialog=20 > > > subscription to the > > > > > contact. Only by tracking the "reg"=20 > > > events can it keep track > > > > > of the UAs available for that AOR. =20 > > > And even then, it is at > > > > > the mercy of network failures. > > > > > > > > > > Dale > > > > >=20 > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > >=20 > > >=20 > > >=20 > > > = From christer.holmberg@ericsson.com Wed Apr 7 05:59:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E14A3A68A2 for ; Wed, 7 Apr 2010 05:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.273 X-Spam-Level: X-Spam-Status: No, score=-5.273 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmkTXTOOrwZv for ; Wed, 7 Apr 2010 05:59:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2997B3A688A for ; Wed, 7 Apr 2010 05:59:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-59-4bbc81a804ef Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F2.3F.23532.8A18CBB4; Wed, 7 Apr 2010 14:59:21 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 7 Apr 2010 14:59:20 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Wed, 7 Apr 2010 14:59:20 +0200 Thread-Topic: draft-ietf-sipcore-subnot-etags: When to include SIP-Etag in NOTIFY? Thread-Index: AcrWUiOv5A1GPfg7RHuYv7tpmrzlKA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CB1EESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] draft-ietf-sipcore-subnot-etags: When to include SIP-Etag in NOTIFY? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:59:26 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CB1EESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When looking deeper into draft-ietf-sipcore-subnot-etags, we also found the= following issue/question: Figure1/Step 3 and Figure 3/Step 3 suggest that the subnot-etags compliant = notifier includes the SIP-Etag in the NOT request even if the associated SU= B request did not contain Suppress-If-Match. The overview text in section 3= also seems to indicate that SIP-Etag is inserted in every NOT, but that is= also informative text only. However, Section 6 only contains normative text about inclusion of the SIP-= Etag in the following situations: 1. The NOT request is generated upon SIP SUB with condition (section 6.2); = and 2. The NOT request is generated with state differential (section 6.4) So, the question is: is a subnot-etags compliant notifier required to inser= t the SIP-Etag in *every* NOT request, or only in the cases explicitly desc= ribed in Section 6? Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CB1EESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
When looking deeper into draft-ietf-sipcore-subnot-et= ags, we also found the following issue/question:
 
Figure1/Step 3 and Figure 3/Step 3 suggest that the s= ubnot-etags compliant notifier includes the SIP-Etag in the NOT request eve= n if the associated SUB request did not contain Suppress-If-Match. The over= view text in section 3 also seems to indicate that SIP-Etag is inserted in every NOT, but that is also inform= ative text only.
 
However, Section 6 only contains normative text about= inclusion of the SIP-Etag in the following situations:
 
1. The NOT request is generated upon SIP SUB with con= dition (section 6.2); and
 
2. The NOT request is generated with state differenti= al (section 6.4)
 
So, the question is: is a subnot-etags compliant noti= fier required to insert the SIP-Etag in *every* NOT request, or only in the= cases explicitly described in Section 6?
 
Regards,
 
Christer
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CB1EESESSCMS0354e_-- From ietf.hanserik@gmail.com Wed Apr 7 06:05:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1693A6837 for ; Wed, 7 Apr 2010 06:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNCYY9ej3LUb for ; Wed, 7 Apr 2010 06:05:36 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id E48C23A67D1 for ; Wed, 7 Apr 2010 06:05:35 -0700 (PDT) Received: by ewy24 with SMTP id 24so513525ewy.13 for ; Wed, 07 Apr 2010 06:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=HX6RPoM8BxJikSWNyFB2bAHrR1roXvu2HBbD3x2a+D0=; b=lBuNidqq08POWxPJuax6eSvxRMTmj4LqK3Zb3dnP8ucPQmPQRHxD4mtVvdVxX4D3y+ EOgCX6z7t8RYA1jviGMrvGdJu5YrR3PhXeNfghvt2dDm2rdU1H0p0f+4mKivsV4feq2T z6r6PeuX51IU0RRFw7GXQswvHj/r0Cr1H2juY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r/zBqHabjTFoQO61HxiUPrlcJnJqf2oubxNDHrkFGlreJllwaLuEkxn4r1XAmRCHkg aZM+YCT5jx2XsXs/UsDj7KArcsH/tdIf4yyHX1JCDuiVn+VmvI7Wyh2NG0BVY2uWajYI 0Bo5qo148503JG3GSSZpmF5Vzdx4pdqV3Fv2E= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 06:05:28 -0700 (PDT) In-Reply-To: References: <4BB24B81.1050006@nostrum.com> Date: Wed, 7 Apr 2010 15:05:28 +0200 Received: by 10.213.46.13 with SMTP id h13mr1855952ebf.83.1270645528755; Wed, 07 Apr 2010 06:05:28 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=001485326135607ee60483a53742 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:05:38 -0000 --001485326135607ee60483a53742 Content-Type: text/plain; charset=ISO-8859-1 John, You are illustrating the case that bad design leads to: You need to be aware of the side effects of one method, so that you can circumvent these to use it for other purposes then it was intended for. /Hans Erik van Elburg On Wed, Apr 7, 2010 at 2:56 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 07 April 2010 12:09 > > To: Elwell, John; Hans Erik van Elburg > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > > Hi, > > > > >>The forking proxy can also have policies what it returns in > > the 3xx, > > >>depending on what the end-users actually represent. > > >> > > >>And, also with other mechanisms the returned data per end-user may > > >>depend on what type of end-point it represents. > > >>I don't think that is bound to a specific mechanism as such. > > >[JRE] Quite true. But Dale's point still holds - you might > > as well just send the INVITE request and see what happens. > > > > Of course. But, as I said, that is really bad protocol > > design, > [JRE] Why is it bad protocol design? > > > and it may trigger unwanted resource reservation > > actions etc in the network. > [JRE] Concerning resource reservation, there are two ways of looking at it. > By doing resource reservation, you find out straight away if the resources > needed to reach the UA are not available, so resource reservation could be > considered a good thing. An OPTIONS transaction is never going to provide > this information. On the other hand, if you want to avoid resource > reservation, just send an offerless INVITE request. > > John > > > > > > And, there could even be cases where the INVITE doesn't fail, > > but you don't get the optimized user experience since the > > request may have looked different should you have known what > > the receiver supports. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik > > van Elburg > > > > Sent: 7. huhtikuuta 2010 12:18 > > > > To: Elwell, John > > > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > > > > > > > > Of course you can implement all kind of policies, but > > > > that makes this AOR quite of a special user. I would argue > > > > that this is some kind of service AOR and not a "normal" user > > > > AOR. The service AOR representing a group of different and > > > > dynamically changing users... > > > > > > > > Demonstrating that this is not a "normal" user. > > > > > > > > I expect that in practice one would solve this > > > > differently... making the case rather artificial. > > > > > > > > /Hans Erik van Elburg > > > > > > > > > > > > On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John > > > > wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hans Erik van Elburg > > > > [mailto:ietf.hanserik@gmail.com] > > > > > Sent: 07 April 2010 08:24 > > > > > To: Elwell, John > > > > > Cc: WORLEY, DALE R (DALE); Salvatore Loreto; > > > > sipcore@ietf.org > > > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we > > > > work on this? > > > > > > > > > > > > > > This is a special case. And the application > > > > you are talking > > > > > about is a B2BUA, right? > > > > > > > > [JRE] Not necessarily. A proxy can be scripted > > > > to cycle between multiple registered contacts. This doesn't > > > > make it a B2BUA. > > > > > > > > John > > > > > > > > > > > > > > > > > > In this case the AOR addressed is an > > > > application address > > > > > without registered contacts. One can argue > > > > that the OPTIONS > > > > > request should return the general capabilities of the > > > > > application. No OPTIONS forking is happening > > > > in this case, no > > > > > registered contacts. No issue? > > > > > > > > > > In reality what the B2BUA will do with the > > > > OPTION request > > > > > (forward or answer) depends on the fantasy of > > > > the B2BUA developer. > > > > > > > > > > I dont think this scenario is actually > > > > usefull in discussing > > > > > whether or not to write a BCP on OPTIONS > > > > handling. Or maybe > > > > > it is as implication of B2BUA behaviours can > > > > be taken into account. > > > > > > > > > > /Hans Erik van Elburg > > > > > > > > > > > > > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > > > > wrote: > > > > > > > > > > > > > > > I agree with Dale. What happens to an > > > > OPTIONS request > > > > > will not necessarily be reflected when an > > > > INVITE request is > > > > > sent shortly afterwards. As a further > > > > examples, in contact > > > > > centres, it is usual to distribute calls cyclically or > > > > > randomly between qualified and available > > > > agents. Sending an > > > > > INVITE request to a UA determined by > > > > responses to an OPTIONS > > > > > request would break that model - the issuer > > > > of the OPTIONS > > > > > and INVITE requests cannot be expected to > > > > obey the same > > > > > rotation rules as the domain proxy that routes INVITE > > > > > requests. Issuing an INVITE request to the > > > > AOR is unlikely to > > > > > result in it being delivered to the UA that > > > > might be expected > > > > > from analysis of responses to an OPTIONS request. > > > > > > > > > > I don't think we should work on trying > > > > to make OPTIONS > > > > > work for this purpose. If we really need to > > > > do anything with > > > > > OPTIONS, we should just issue warnings about its > > > > > unsuitability for purposes other than a simple ping. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > > WORLEY, DALE R (DALE) > > > > > > Sent: 06 April 2010 21:01 > > > > > > To: Salvatore Loreto; sipcore@ietf.org > > > > > > Subject: Re: [sipcore] SIP OPTIONS: > > > > Shall we work on this? > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > From: sipcore-bounces@ietf.org > > > > [sipcore-bounces@ietf.org] On > > > > > > Behalf Of Salvatore Loreto > > > > [salvatore.loreto@ericsson.com] > > > > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > > > > > > > A good mechanism to discovery UA > > > > capabilities is essential to > > > > > > provide meaningful service: > > > > > > So I am in favor of pursuing the work, > > > > > > in particular the possibility to use > > > > a single OPTIONS request > > > > > > to retrieve the capabilities from ALL > > > > UAS(s) behind a > > > > > forking proxy. > > > > > > _______________________________________ > > > > > > > > > > > > I think it is a misconception to use > > > > UA discovery to provide > > > > > > services. The difficulty is that the > > > > set of available UAs > > > > > > for a given destination URI changes > > > > unpredictably -- elements > > > > > > become inacessible (mobile phone out > > > > of range!), call routing > > > > > > changes due to time of day, etc. > > > > Instead, SIP provides a > > > > > > remarkably effective system for > > > > selecting the best target of > > > > > > a call *at the moment the call is > > > > initiated* -- the caller > > > > > > declares his preferences, and the > > > > various intermediate > > > > > > elements combine the caller's desires > > > > with the routing > > > > > > information that they possess to > > > > forward the call closer to > > > > > > the preferred destination. > > > > > > > > > > > > As a developer, I've had to wrestle > > > > with this. In order to > > > > > > provide clean "Is extension 1234 > > > > busy?" information, our "BLF > > > > > > agent" maintains subscriptions to the > > > > "reg" event package for > > > > > > the AOR "sip:1234@example.com > > > > > > > > > > > > > > > > > > > > ". > For each reported contact > > > > > > > > > > for the AOR, it maintains a dialog > > > > subscription to the > > > > > > contact. Only by tracking the "reg" > > > > events can it keep track > > > > > > of the UAs available for that AOR. > > > > And even then, it is at > > > > > > the mercy of network failures. > > > > > > > > > > > > Dale > > > > > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --001485326135607ee60483a53742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,

You are illustrating the case that bad design leads to: You ne= ed to be aware of the side effects of one method, so that you can circumven= t these to use it for other purposes then it was intended for.

/Hans Erik van Elburg


On Wed, Apr 7, 2010 at 2:56 PM, Elwell, = John <john.elwell@siemens-enterprise.com> wrote:


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: 07 April 2010 12:09
> To: Elwell, John; Hans Erik van Elburg
> Cc: WORLEY, DALE R (DALE); sipcore= @ietf.org
> Subject: RE: [sipcore] SIP OPTIONS: Shall we w= ork on this?
>
>
> Hi,
>
> >>The forking proxy can also have policies what it returns in > the 3xx,
> >>depending on what the end-users actually represent.
> >>
> >>And, also with other mechanisms the returned data per end-user= may
> >>depend on what type of end-point it represents.
> >>I don't think that is bound to a specific mechanism as suc= h.
> >[JRE] Quite true. But Dale's point still holds - you might
> as well just send the INVITE request and see what happens.
>
> Of course. But, as I said, that is really bad protocol
> design,
[JRE] Why is it bad protocol design?

> and it may trigger unwanted resource reservation
> actions etc in the network.
[JRE] Concerning resource reservation, there are two ways of looking = at it. By doing resource reservation, you find out straight away if the res= ources needed to reach the UA are not available, so resource reservation co= uld be considered a good thing. An OPTIONS transaction is never going to pr= ovide this information. On the other hand, if you want to avoid resource re= servation, just send an offerless INVITE request.

John


>
> And, there could even be cases where the INVITE doesn't fail,
> but you don't get the optimized user experience since the
> request may have looked different should you have known what
> the receiver supports.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
> > > ________________________________
> > >
> > > =A0 From: sipcor= e-bounces@ietf.org
> > > [mailto:sipcore-= bounces@ietf.org] On Behalf Of Hans Erik
> van Elburg
> > > =A0 Sent: 7. huhtikuuta 2010 12:18
> > > =A0 To: Elwell, John
> > > =A0 Cc: WORLEY, DALE R (DALE); sipcore@ietf.org
> > > =A0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on thi= s?
> > >
> > >
> > > =A0 Of course you can implement all kind of policies, but > > > that makes this AOR quite of a special user. I would argue > > > that this is some kind of service AOR and not a "normal= " user
> > > AOR. The service AOR representing a group of different and > > > dynamically changing users...
> > >
> > > =A0 Demonstrating that this is not a "normal" user= .
> > >
> > > =A0 I expect that in practice one would solve this
> > > differently... making the case rather artificial.
> > >
> > > =A0 /Hans Erik van Elburg
> > >
> > >
> > > =A0 On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John
> > > <jo= hn.elwell@siemens-enterprise.com> wrote:
> > >
> > >
> > >
> > >
> > > =A0 =A0 =A0 =A0 =A0 > -----Original Message-----
> > > =A0 =A0 =A0 =A0 =A0 > From: Hans Erik van Elburg
> > > [mailto:ietf.hans= erik@gmail.com]
> > > =A0 =A0 =A0 =A0 =A0 > Sent: 07 April 2010 08:24
> > > =A0 =A0 =A0 =A0 =A0 > To: Elwell, John
> > > =A0 =A0 =A0 =A0 =A0 > Cc: WORLEY, DALE R (DALE); Salvator= e Loreto;
> > > sipcore@ietf.org
> > > =A0 =A0 =A0 =A0 =A0 > Subject: Re: [sipcore] SIP OPTIONS:= Shall we
> > > work on this?
> > > =A0 =A0 =A0 =A0 =A0 >
> > >
> > > =A0 =A0 =A0 =A0 =A0 > This is a special case. And the app= lication
> > > you are talking
> > > =A0 =A0 =A0 =A0 =A0 > about is a B2BUA, right?
> > >
> > > =A0 =A0 =A0 =A0 =A0 [JRE] Not necessarily. A proxy can be sc= ripted
> > > to cycle between multiple registered contacts. This doesn= 9;t
> > > make it a B2BUA.
> > >
> > > =A0 =A0 =A0 =A0 =A0 John
> > >
> > >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > In this case the AOR addressed is a= n
> > > application address
> > > =A0 =A0 =A0 =A0 =A0 > without registered contacts. One ca= n argue
> > > that the OPTIONS
> > > =A0 =A0 =A0 =A0 =A0 > request should return the general c= apabilities of the
> > > =A0 =A0 =A0 =A0 =A0 > application. No OPTIONS forking is = happening
> > > in this case, no
> > > =A0 =A0 =A0 =A0 =A0 > registered contacts. No issue?
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > In reality what the B2BUA will do w= ith the
> > > OPTION request
> > > =A0 =A0 =A0 =A0 =A0 > (forward or answer) depends on the = fantasy of
> > > the B2BUA developer.
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > I dont think this scenario is actua= lly
> > > usefull in discussing
> > > =A0 =A0 =A0 =A0 =A0 > whether or not to write a BCP on OP= TIONS
> > > handling. Or maybe
> > > =A0 =A0 =A0 =A0 =A0 > it is as implication of B2BUA behav= iours can
> > > be taken into account.
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > /Hans Erik van Elburg
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > On Wed, Apr 7, 2010 at 8:31 AM, Elw= ell, John
> > > =A0 =A0 =A0 =A0 =A0 > <john.elwell@siemens-enterprise.com> wrote: > > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 I agree with Dale. What= happens to an
> > > OPTIONS request
> > > =A0 =A0 =A0 =A0 =A0 > will not necessarily be reflected w= hen an
> > > INVITE request is
> > > =A0 =A0 =A0 =A0 =A0 > sent shortly afterwards. As a furth= er
> > > examples, in contact
> > > =A0 =A0 =A0 =A0 =A0 > centres, it is usual to distribute = calls cyclically or
> > > =A0 =A0 =A0 =A0 =A0 > randomly between qualified and avai= lable
> > > agents. Sending an
> > > =A0 =A0 =A0 =A0 =A0 > INVITE request to a UA determined b= y
> > > responses to an OPTIONS
> > > =A0 =A0 =A0 =A0 =A0 > request would break that model - th= e issuer
> > > of the OPTIONS
> > > =A0 =A0 =A0 =A0 =A0 > and INVITE requests cannot be expec= ted to
> > > obey the same
> > > =A0 =A0 =A0 =A0 =A0 > rotation rules as the domain proxy = that routes INVITE
> > > =A0 =A0 =A0 =A0 =A0 > requests. Issuing an INVITE request= to the
> > > AOR is unlikely to
> > > =A0 =A0 =A0 =A0 =A0 > result in it being delivered to the= UA that
> > > might be expected
> > > =A0 =A0 =A0 =A0 =A0 > from analysis of responses to an OP= TIONS request.
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 I don't think we sh= ould work on trying
> > > to make OPTIONS
> > > =A0 =A0 =A0 =A0 =A0 > work for this purpose. If we really= need to
> > > do anything with
> > > =A0 =A0 =A0 =A0 =A0 > OPTIONS, we should just issue warni= ngs about its
> > > =A0 =A0 =A0 =A0 =A0 > unsuitability for purposes other th= an a simple ping.
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 John
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Mess= age-----
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > From: sipcore-bounces@ietf.org
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > [mailto:sipcore-bounces@ietf.org] On Behalf O= f
> > > =A0 =A0 =A0 =A0 =A0 > WORLEY, DALE R (DALE)
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: 06 April 201= 0 21:01
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > To: Salvatore Lore= to; sipcore@ietf.org
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [sipc= ore] SIP OPTIONS:
> > > Shall we work on this?
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > __________________= ______________________
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > From: sipcore-bounces@ietf.org
> > > [sipcore-bounces= @ietf.org] On
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Behalf Of Salvator= e Loreto
> > > [salvatore.= loreto@ericsson.com]
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Thursday, Ap= ril 01, 2010 3:36 AM
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > A good mechanism t= o discovery UA
> > > capabilities is essential to
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > provide meaningful= service:
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > So I am in favor o= f pursuing the work,
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > in particular the = possibility to use
> > > a single OPTIONS request
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > to retrieve the ca= pabilities from ALL
> > > UAS(s) behind a
> > > =A0 =A0 =A0 =A0 =A0 > forking proxy.
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > __________________= _____________________
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > I think it is a mi= sconception to use
> > > UA discovery to provide
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > services. =A0The d= ifficulty is that the
> > > set of available UAs
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > for a given destin= ation URI changes
> > > unpredictably -- elements
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > become inacessible= (mobile phone out
> > > of range!), call routing
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > changes due to tim= e of day, etc.
> > > Instead, SIP provides a
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > remarkably effecti= ve system for
> > > selecting the best target of
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > a call *at the mom= ent the call is
> > > initiated* -- the caller
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > declares his prefe= rences, and the
> > > various intermediate
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > elements combine t= he caller's desires
> > > with the routing
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > information that t= hey possess to
> > > forward the call closer to
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the preferred dest= ination.
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > As a developer, I&= #39;ve had to wrestle
> > > with this. =A0In order to
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > provide clean &quo= t;Is extension 1234
> > > busy?" information, our "BLF
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > agent" mainta= ins subscriptions to the
> > > "reg" event package for
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the AOR "sip:1234@example.com
> > > <mailto:sip%3= A1234@example.com>
> > >
> > > =A0 =A0 =A0 =A0 =A0 > <mailto:sip%3A1234@example.com
> > > <mailto:sip= %253A1234@example.com> > ". =A0For each reported contact
> > >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > for the AOR, it ma= intains a dialog
> > > subscription to the
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > contact. =A0Only b= y tracking the "reg"
> > > events can it keep track
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > of the UAs availab= le for that AOR.
> > > And even then, it is at
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > the mercy of netwo= rk failures.
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > Dale
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > _______________________________________________
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > sipcore mailing li= st
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > sipcore@ietf.org
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > https://www.ietf.= org/mailman/listinfo/sipcore
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 _______________________= ________________________
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 sipcore mailing list > > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 sipcore@ietf.org
> > > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/m= ailman/listinfo/sipcore
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > > =A0 =A0 =A0 =A0 =A0 >
> > >
> > >
> > >

--001485326135607ee60483a53742-- From christer.holmberg@ericsson.com Wed Apr 7 06:05:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E873A68A2 for ; Wed, 7 Apr 2010 06:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrYEG6fy6Daf for ; Wed, 7 Apr 2010 06:05:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 638FC3A67D1 for ; Wed, 7 Apr 2010 06:05:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-a5-4bbc832dcc2e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B0.CE.23740.D238CBB4; Wed, 7 Apr 2010 15:05:49 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 7 Apr 2010 15:05:49 +0200 From: Christer Holmberg To: "Elwell, John" , Hans Erik van Elburg Date: Wed, 7 Apr 2010 15:05:49 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5A= Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:05:55 -0000 Hi,=20 >>>>The forking proxy can also have policies what it returns in >>>>the 3xx, depending on what the end-users actually represent. >>>> =20 >>>>And, also with other mechanisms the returned data per end-user may=20 >>>>depend on what type of end-point it represents. >>>>I don't think that is bound to a specific mechanism as such. >>>[JRE] Quite true. But Dale's point still holds - you might >>as well just send the INVITE request and see what happens. >>=20 >>Of course. But, as I said, that is really bad protocol design, >[JRE] Why is it bad protocol design? Since we have a mechanism where we can query users, I think is nicer to use= . Now, I am not saying that you need to send OPTIONS prior to every call. My = main use-case is where the INVITE itself may look different depending on th= e capabilities. So, again, an INVITE may not even fail, but you may not get= exactly what you would have wanted. >>and it may trigger unwanted resource reservation actions etc in the=20 >>network. >[JRE] Concerning resource reservation, there are two ways of=20 >looking at it. By doing resource reservation, you find out=20 >straight away if the resources needed to reach the UA are not=20 >available, so resource reservation could be considered a good=20 >thing. You will most likely not figure out whether the resources are available, in= case there is no provisional response etc. >An OPTIONS transaction is never going to provide this information. On the = other hand, if you want to avoid resource=20 >reservation, just send an offerless INVITE request. That is going to bring other issues, if the SDP is part of the service info= rmation etc. In addition, the resources do not necessarily be related to the SDP and the= media plane. Regards, Christer > > And, there could even be cases where the INVITE doesn't=20 > fail, but you=20 > > don't get the optimized user experience since the request may have=20 > > looked different should you have known what the receiver supports. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > > ________________________________ > > > >=20 > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik > > van Elburg > > > > Sent: 7. huhtikuuta 2010 12:18 > > > > To: Elwell, John > > > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we=20 > work on this? > > > > =09 > > > > =09 > > > > Of course you can implement all kind of=20 > policies, but that makes=20 > > > > this AOR quite of a special user. I would argue that=20 > this is some=20 > > > > kind of service AOR and not a "normal" user AOR. The=20 > service AOR=20 > > > > representing a group of different and dynamically changing=20 > > > > users... > > > > =09 > > > > Demonstrating that this is not a "normal" user. > > > > =09 > > > > I expect that in practice one would solve this=20 > differently...=20 > > > > making the case rather artificial. > > > > =09 > > > > /Hans Erik van Elburg > > > > =09 > > > > =09 > > > > On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John=20 > > > > wrote: > > > > =09 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Hans Erik van Elburg > > > > [mailto:ietf.hanserik@gmail.com] > > > > > Sent: 07 April 2010 08:24 > > > > > To: Elwell, John > > > > > Cc: WORLEY, DALE R (DALE); Salvatore=20 > Loreto; sipcore@ietf.org > > > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > Shall we work on this? > > > > > > > > > =09 > > > > > This is a special case. And the=20 > application you are talking > > > > > about is a B2BUA, right? > > > > =09 > > > > [JRE] Not necessarily. A proxy can be=20 > scripted to cycle between=20 > > > > multiple registered contacts. This doesn't make it a B2BUA. > > > > =09 > > > > John > > > > =09 > > > >=20 > > > > > > > > > > In this case the AOR addressed is an=20 > application address > > > > > without registered contacts. One can=20 > argue that the OPTIONS > > > > > request should return the general=20 > capabilities of the > > > > > application. No OPTIONS forking is=20 > happening in this case, no > > > > > registered contacts. No issue? > > > > > > > > > > In reality what the B2BUA will do=20 > with the OPTION request > > > > > (forward or answer) depends on the=20 > fantasy of the B2BUA=20 > > > > developer. > > > > > > > > > > I dont think this scenario is=20 > actually usefull in discussing > > > > > whether or not to write a BCP on=20 > OPTIONS handling. Or maybe > > > > > it is as implication of B2BUA=20 > behaviours can be taken into=20 > > > > account. > > > > > > > > > > /Hans Erik van Elburg > > > > > > > > > > > > > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > > > > wrote: > > > > > > > > > > > > > > > I agree with Dale. What happens to an=20 > > > > OPTIONS request > > > > > will not necessarily be reflected=20 > when an INVITE request is > > > > > sent shortly afterwards. As a further=20 > examples, in contact > > > > > centres, it is usual to distribute=20 > calls cyclically or > > > > > randomly between qualified and=20 > available agents. Sending an > > > > > INVITE request to a UA determined by=20 > responses to an OPTIONS > > > > > request would break that model - the=20 > issuer of the OPTIONS > > > > > and INVITE requests cannot be=20 > expected to obey the same > > > > > rotation rules as the domain proxy=20 > that routes INVITE > > > > > requests. Issuing an INVITE request=20 > to the AOR is unlikely to > > > > > result in it being delivered to the=20 > UA that might be expected > > > > > from analysis of responses to an=20 > OPTIONS request. > > > > > > > > > > I don't think we should work on trying=20 > > > > to make OPTIONS > > > > > work for this purpose. If we really=20 > need to do anything with > > > > > OPTIONS, we should just issue=20 > warnings about its > > > > > unsuitability for purposes other than=20 > a simple ping. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > > > > > >=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > > WORLEY, DALE R (DALE) > > > > > > Sent: 06 April 2010 21:01 > > > > > > To: Salvatore Loreto; sipcore@ietf.org > > > > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > > > > Shall we work on this? > > > > > > > > > > > >=20 > ________________________________________ > > > > > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > [sipcore-bounces@ietf.org] On > > > > > > Behalf Of Salvatore Loreto=20 > > > > [salvatore.loreto@ericsson.com] > > > > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > > > > > > > A good mechanism to discovery UA=20 > > > > capabilities is essential to > > > > > > provide meaningful service: > > > > > > So I am in favor of pursuing the work, > > > > > > in particular the possibility to use=20 > > > > a single OPTIONS request > > > > > > to retrieve the capabilities from ALL=20 > > > > UAS(s) behind a > > > > > forking proxy. > > > > > >=20 > _______________________________________ > > > > > > > > > > > > I think it is a misconception to use=20 > > > > UA discovery to provide > > > > > > services. The difficulty is that the=20 > > > > set of available UAs > > > > > > for a given destination URI changes=20 > > > > unpredictably -- elements > > > > > > become inacessible (mobile phone out=20 > > > > of range!), call routing > > > > > > changes due to time of day, etc. =20 > > > > Instead, SIP provides a > > > > > > remarkably effective system for=20 > > > > selecting the best target of > > > > > > a call *at the moment the call is=20 > > > > initiated* -- the caller > > > > > > declares his preferences, and the=20 > > > > various intermediate > > > > > > elements combine the caller's desires=20 > > > > with the routing > > > > > > information that they possess to=20 > > > > forward the call closer to > > > > > > the preferred destination. > > > > > > > > > > > > As a developer, I've had to wrestle=20 > > > > with this. In order to > > > > > > provide clean "Is extension 1234=20 > > > > busy?" information, our "BLF > > > > > > agent" maintains subscriptions to the=20 > > > > "reg" event package for > > > > > > the AOR "sip:1234@example.com=20 > > > > > > > > =09 > > > > > > > > > ". For each=20 > reported contact > > > > =09 > > > > > > for the AOR, it maintains a dialog=20 > > > > subscription to the > > > > > > contact. Only by tracking the "reg"=20 > > > > events can it keep track > > > > > > of the UAs available for that AOR. =20 > > > > And even then, it is at > > > > > > the mercy of network failures. > > > > > > > > > > > > Dale > > > > > >=20 > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > >=20 > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > =20 > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > =20 > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > > = From john.elwell@siemens-enterprise.com Wed Apr 7 06:30:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7DC3A68EE for ; Wed, 7 Apr 2010 06:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbtuSVoIrvdQ for ; Wed, 7 Apr 2010 06:30:09 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 47CB33A67AB for ; Wed, 7 Apr 2010 06:30:07 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1469309; Wed, 7 Apr 2010 15:30:04 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id B01FB23F0278; Wed, 7 Apr 2010 15:30:04 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 7 Apr 2010 15:30:04 +0200 From: "Elwell, John" To: Christer Holmberg , Hans Erik van Elburg Date: Wed, 7 Apr 2010 15:30:03 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5AAAL6EcA== Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:30:10 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 07 April 2010 14:06 > To: Elwell, John; Hans Erik van Elburg > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > Hi,=20 >=20 > >>>>The forking proxy can also have policies what it returns in > >>>>the 3xx, depending on what the end-users actually represent. > >>>> =20 > >>>>And, also with other mechanisms the returned data per=20 > end-user may=20 > >>>>depend on what type of end-point it represents. > >>>>I don't think that is bound to a specific mechanism as such. > >>>[JRE] Quite true. But Dale's point still holds - you might > >>as well just send the INVITE request and see what happens. > >>=20 > >>Of course. But, as I said, that is really bad protocol design, > >[JRE] Why is it bad protocol design? >=20 > Since we have a mechanism where we can query users, I think=20 > is nicer to use. [JRE] But even if you then target the INVITE request at the GRUU of the pre= ferred user, there is no guarantee it will succeed (e.g., no media resource= s, UA has become busy in the meantime), and because it is targeted directly= , you lose the opportunity to take alternative action, e.g., forwarding to = voicemail or to another UA with similar capabilities. It is a case of the c= alling user trying to override policies associated with the called user, wh= ich I think is a bad thing. The result of the OPTIONS request can only ever= act as a guideline - it is effectively no better than presence. It would be helpful to have a concrete example of something that could go i= nto an INVITE request targeted at a particular UA known to have a particula= r capability, that could not go into an INVITE request targeted at the AOR = and with caller preferences RECOMMENDING selection of a UA with that partic= ular capability. Apologies if such an example has already been given earlie= r in the discussion. John >=20 > Now, I am not saying that you need to send OPTIONS prior to=20 > every call. My main use-case is where the INVITE itself may=20 > look different depending on the capabilities. So, again, an=20 > INVITE may not even fail, but you may not get exactly what=20 > you would have wanted. >=20 > >>and it may trigger unwanted resource reservation actions etc in the=20 > >>network. > >[JRE] Concerning resource reservation, there are two ways of=20 > >looking at it. By doing resource reservation, you find out=20 > >straight away if the resources needed to reach the UA are not=20 > >available, so resource reservation could be considered a good=20 > >thing. >=20 > You will most likely not figure out whether the resources are=20 > available, in case there is no provisional response etc. >=20 > >An OPTIONS transaction is never going to provide this=20 > information. On the other hand, if you want to avoid resource=20 > >reservation, just send an offerless INVITE request. >=20 > That is going to bring other issues, if the SDP is part of=20 > the service information etc. >=20 > In addition, the resources do not necessarily be related to=20 > the SDP and the media plane. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > > And, there could even be cases where the INVITE doesn't=20 > > fail, but you=20 > > > don't get the optimized user experience since the request=20 > may have=20 > > > looked different should you have known what the receiver supports. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > > ________________________________ > > > > >=20 > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik > > > van Elburg > > > > > Sent: 7. huhtikuuta 2010 12:18 > > > > > To: Elwell, John > > > > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we=20 > > work on this? > > > > > =09 > > > > > =09 > > > > > Of course you can implement all kind of=20 > > policies, but that makes=20 > > > > > this AOR quite of a special user. I would argue that=20 > > this is some=20 > > > > > kind of service AOR and not a "normal" user AOR. The=20 > > service AOR=20 > > > > > representing a group of different and dynamically changing=20 > > > > > users... > > > > > =09 > > > > > Demonstrating that this is not a "normal" user. > > > > > =09 > > > > > I expect that in practice one would solve this=20 > > differently...=20 > > > > > making the case rather artificial. > > > > > =09 > > > > > /Hans Erik van Elburg > > > > > =09 > > > > > =09 > > > > > On Wed, Apr 7, 2010 at 10:41 AM, Elwell, John=20 > > > > > wrote: > > > > > =09 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Hans Erik van Elburg > > > > > [mailto:ietf.hanserik@gmail.com] > > > > > > Sent: 07 April 2010 08:24 > > > > > > To: Elwell, John > > > > > > Cc: WORLEY, DALE R (DALE); Salvatore=20 > > Loreto; sipcore@ietf.org > > > > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > > Shall we work on this? > > > > > > > > > > > =09 > > > > > > This is a special case. And the=20 > > application you are talking > > > > > > about is a B2BUA, right? > > > > > =09 > > > > > [JRE] Not necessarily. A proxy can be=20 > > scripted to cycle between=20 > > > > > multiple registered contacts. This doesn't make it a B2BUA. > > > > > =09 > > > > > John > > > > > =09 > > > > >=20 > > > > > > > > > > > > In this case the AOR addressed is an=20 > > application address > > > > > > without registered contacts. One can=20 > > argue that the OPTIONS > > > > > > request should return the general=20 > > capabilities of the > > > > > > application. No OPTIONS forking is=20 > > happening in this case, no > > > > > > registered contacts. No issue? > > > > > > > > > > > > In reality what the B2BUA will do=20 > > with the OPTION request > > > > > > (forward or answer) depends on the=20 > > fantasy of the B2BUA=20 > > > > > developer. > > > > > > > > > > > > I dont think this scenario is=20 > > actually usefull in discussing > > > > > > whether or not to write a BCP on=20 > > OPTIONS handling. Or maybe > > > > > > it is as implication of B2BUA=20 > > behaviours can be taken into=20 > > > > > account. > > > > > > > > > > > > /Hans Erik van Elburg > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 7, 2010 at 8:31 AM, Elwell, John > > > > > > wrote: > > > > > > > > > > > > > > > > > > I agree with Dale. What happens to an=20 > > > > > OPTIONS request > > > > > > will not necessarily be reflected=20 > > when an INVITE request is > > > > > > sent shortly afterwards. As a further=20 > > examples, in contact > > > > > > centres, it is usual to distribute=20 > > calls cyclically or > > > > > > randomly between qualified and=20 > > available agents. Sending an > > > > > > INVITE request to a UA determined by=20 > > responses to an OPTIONS > > > > > > request would break that model - the=20 > > issuer of the OPTIONS > > > > > > and INVITE requests cannot be=20 > > expected to obey the same > > > > > > rotation rules as the domain proxy=20 > > that routes INVITE > > > > > > requests. Issuing an INVITE request=20 > > to the AOR is unlikely to > > > > > > result in it being delivered to the=20 > > UA that might be expected > > > > > > from analysis of responses to an=20 > > OPTIONS request. > > > > > > > > > > > > I don't think we should work on trying=20 > > > > > to make OPTIONS > > > > > > work for this purpose. If we really=20 > > need to do anything with > > > > > > OPTIONS, we should just issue=20 > > warnings about its > > > > > > unsuitability for purposes other than=20 > > a simple ping. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: sipcore-bounces@ietf.org > > > > > > > > > > > > >=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > > > WORLEY, DALE R (DALE) > > > > > > > Sent: 06 April 2010 21:01 > > > > > > > To: Salvatore Loreto; sipcore@ietf.org > > > > > > > Subject: Re: [sipcore] SIP OPTIONS:=20 > > > > > Shall we work on this? > > > > > > > > > > > > > >=20 > > ________________________________________ > > > > > > > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > [sipcore-bounces@ietf.org] On > > > > > > > Behalf Of Salvatore Loreto=20 > > > > > [salvatore.loreto@ericsson.com] > > > > > > > Sent: Thursday, April 01, 2010 3:36 AM > > > > > > > > > > > > > > A good mechanism to discovery UA=20 > > > > > capabilities is essential to > > > > > > > provide meaningful service: > > > > > > > So I am in favor of pursuing the work, > > > > > > > in particular the possibility to use=20 > > > > > a single OPTIONS request > > > > > > > to retrieve the capabilities from ALL=20 > > > > > UAS(s) behind a > > > > > > forking proxy. > > > > > > >=20 > > _______________________________________ > > > > > > > > > > > > > > I think it is a misconception to use=20 > > > > > UA discovery to provide > > > > > > > services. The difficulty is that the=20 > > > > > set of available UAs > > > > > > > for a given destination URI changes=20 > > > > > unpredictably -- elements > > > > > > > become inacessible (mobile phone out=20 > > > > > of range!), call routing > > > > > > > changes due to time of day, etc. =20 > > > > > Instead, SIP provides a > > > > > > > remarkably effective system for=20 > > > > > selecting the best target of > > > > > > > a call *at the moment the call is=20 > > > > > initiated* -- the caller > > > > > > > declares his preferences, and the=20 > > > > > various intermediate > > > > > > > elements combine the caller's desires=20 > > > > > with the routing > > > > > > > information that they possess to=20 > > > > > forward the call closer to > > > > > > > the preferred destination. > > > > > > > > > > > > > > As a developer, I've had to wrestle=20 > > > > > with this. In order to > > > > > > > provide clean "Is extension 1234=20 > > > > > busy?" information, our "BLF > > > > > > > agent" maintains subscriptions to the=20 > > > > > "reg" event package for > > > > > > > the AOR "sip:1234@example.com=20 > > > > > > > > > > =09 > > > > > > > > > > > ". For each=20 > > reported contact > > > > > =09 > > > > > > > for the AOR, it maintains a dialog=20 > > > > > subscription to the > > > > > > > contact. Only by tracking the "reg"=20 > > > > > events can it keep track > > > > > > > of the UAs available for that AOR. =20 > > > > > And even then, it is at > > > > > > > the mercy of network failures. > > > > > > > > > > > > > > Dale > > > > > > >=20 > > > > > _______________________________________________ > > > > > > > sipcore mailing list > > > > > > > sipcore@ietf.org > > > > > > >=20 > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > =20 > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > =20 > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > >=20 > > > > > = From HKaplan@acmepacket.com Wed Apr 7 06:53:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA46B3A6810 for ; Wed, 7 Apr 2010 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHoogaHu0sui for ; Wed, 7 Apr 2010 06:53:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5A2B83A6823 for ; Wed, 7 Apr 2010 06:53:16 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 09:53:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 7 Apr 2010 09:53:12 -0400 From: Hadriel Kaplan To: Christer Holmberg , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 09:53:12 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAJP+7AA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:53:17 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Tuesday, April 06, 2010 4:08 PM > To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 > Hi Dale, >=20 > From my perspective, the main use-case is not to discover services, but t= o > discover capabilities in order to determine what services can be applied. >=20 > The idea is also that the OPTIONS request would be sent prior to the > INVITE, to try to make sure that the returned contacts are actually > available. But you know that would never work in practice/the-real-world. Think about= all the routing rules people have for INVITEs - in some cases *only* for I= NVITEs. And even if they route OPTIONS identically in the SIP domain, for = any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a H.323-g= ateway, or an MGCP call-agent, or an IP-PBX, or a foobar-protocol-gateway, = or a vmail server, or an announcement server, or an app server, etc. Just = because the OPTIONS reaches the end of the SIP domain, means nothing about = whether an INVITE to the higher-layer target (which in practice is a E.164 = number, that crosses from SIP into many other protocol domains) is actually= available to receive a call. -hadriel From HKaplan@acmepacket.com Wed Apr 7 07:01:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0683A68D5 for ; Wed, 7 Apr 2010 07:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUu2AxL65+LW for ; Wed, 7 Apr 2010 07:01:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6BEF33A67A6 for ; Wed, 7 Apr 2010 07:01:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 10:01:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 7 Apr 2010 10:01:09 -0400 From: Hadriel Kaplan To: Christer Holmberg , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Wed, 7 Apr 2010 10:01:08 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAACPuvQABgDy5ACORmbA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CFD1@mail> References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:01:14 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Tuesday, April 06, 2010 4:55 PM > > > > Dale Worley said: > > Why not just send the INVITE and see if it fails? In the most common > > case (success), that saves one round-trip. >=20 > Because that is crappy protocol design. And, the INVITE might trigger > different resources etc to be reserved, so you don't want to keep sending > those. What's so crappy about using an INVITE to say you want to start a session? = A failure of an INVITE request isn't a protocol failure or error condition= (unless the response code is an error condition type). =20 What's next, we need an OPTIONS before the OPTIONS to make sure the second = OPTIONS won't fail?? ;) Sure the INVITE might trigger resources reservation - that's GOOD, because = it verifies the resources are available - if those resources aren't availab= le the request will fail, whereas for an OPTIONS it wouldn't have. -hadriel From ietf.hanserik@gmail.com Wed Apr 7 07:05:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8EC3A67AF for ; Wed, 7 Apr 2010 07:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haDkLPIxJldY for ; Wed, 7 Apr 2010 07:05:19 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 539963A67A6 for ; Wed, 7 Apr 2010 07:05:18 -0700 (PDT) Received: by ewy24 with SMTP id 24so548644ewy.13 for ; Wed, 07 Apr 2010 07:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=i3SQVs0KVtfVTHif/qceDHAEsBzzIPsz9+4ASJ7/HlA=; b=eTYuWTgtiy2sNuYeQJtXWC1d2OZ6XXo6vOY8f9oD8ESaxb0FMO1QdZp6Oy5lv9NpTU chNN/IfpkDe/2yL64YUvf3b6vqlFolLJQgRiSESXO/c30hXqL4Mb3wuA4RjqcW4lxQcO tVgesjsvW0vMNXnmO97m3vFMDqH1lEN+Q7RRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N5cgOrcl3vnOlBn7JOCtWmwBfp4z9Vnxbx9P0gstkL0T48DyjjIxNWBw6tnmIFb9SV 5nshSUHPaYsN4sWD1rXMRtJp76CL9rcLkg22+WgOIzE2rCdpxi5l3O/HkOwoxE+cISmR fn/6f4121LDY5bis++zVhzsuIECExd7co6flY= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 07:05:11 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> Date: Wed, 7 Apr 2010 16:05:11 +0200 Received: by 10.213.25.78 with SMTP id y14mr5460309ebb.75.1270649111533; Wed, 07 Apr 2010 07:05:11 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00151744790eed59f10483a60c76 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:05:24 -0000 --00151744790eed59f10483a60c76 Content-Type: text/plain; charset=ISO-8859-1 In such cases you will get the capabilities of the gateway where the SIP domain is left. Why isn't that info useful? /Hans Erik van Elburg On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > > Of Christer Holmberg > > Sent: Tuesday, April 06, 2010 4:08 PM > > To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > Hi Dale, > > > > From my perspective, the main use-case is not to discover services, but > to > > discover capabilities in order to determine what services can be applied. > > > > The idea is also that the OPTIONS request would be sent prior to the > > INVITE, to try to make sure that the returned contacts are actually > > available. > > But you know that would never work in practice/the-real-world. Think about > all the routing rules people have for INVITEs - in some cases *only* for > INVITEs. And even if they route OPTIONS identically in the SIP domain, for > any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a > H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a > foobar-protocol-gateway, or a vmail server, or an announcement server, or an > app server, etc. Just because the OPTIONS reaches the end of the SIP > domain, means nothing about whether an INVITE to the higher-layer target > (which in practice is a E.164 number, that crosses from SIP into many other > protocol domains) is actually available to receive a call. > > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00151744790eed59f10483a60c76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In such cases you will get the capabilities of the gateway where the SIP do= main is left. Why isn't that info useful?

/Hans Er= ik van Elburg

On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kapl= an <HKaplan@= acmepacket.com> wrote:


> -----Original Message-----
> From: sipcore-bounces@ietf= .org [mailto:sipcore-bounce= s@ietf.org] On Behalf
> Of Christer Holmberg
> Sent: Tuesday, April 06, 2010 4:08 PM
> To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
> Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?
>
> Hi Dale,
>
> From my perspective, the main use-case is not to discover services, bu= t to
> discover capabilities in order to determine what services can be appli= ed.
>
> The idea is also that the OPTIONS request would be sent prior to the > INVITE, to try to make sure that the returned contacts are actually > available.

But you know that would never work in practice/the-real-world. =A0Thi= nk about all the routing rules people have for INVITEs - in some cases *onl= y* for INVITEs. =A0And even if they route OPTIONS identically in the SIP do= main, for any given AoR it'll go to any of: a SIP UA, or a PSTN gateway= , or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a foobar-prot= ocol-gateway, or a vmail server, or an announcement server, or an app serve= r, etc. =A0Just because the OPTIONS reaches the end of the SIP domain, mean= s nothing about whether an INVITE to the higher-layer target (which in prac= tice is a E.164 number, that crosses from SIP into many other protocol doma= ins) is actually available to receive a call.

-hadriel
__________________________________= _____________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--00151744790eed59f10483a60c76-- From HKaplan@acmepacket.com Wed Apr 7 07:32:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DF03A6870 for ; Wed, 7 Apr 2010 07:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD8RXAYeUMeP for ; Wed, 7 Apr 2010 07:32:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A581D3A6855 for ; Wed, 7 Apr 2010 07:32:05 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 10:32:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 7 Apr 2010 10:32:01 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Wed, 7 Apr 2010 10:31:59 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWW2NiVK+bgGA4R2WrLvq7F2IKDgAAMfqw Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79F3CFE9mail_" MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:32:12 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79F3CFE9mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Because it means nothing about the capabilities for the INVITE, because the= INVITE session's capabilities is dictated by the far-end beyond that gatew= ay. For example, I don't know what types of capabilities you guys are thinking = of, but let's say it was for getting the codecs. So you send an OPTIONS, a= nd it gets to an H.323 gateway. The gateway supports lots of codecs, so it= gives you some nice big SDP. Then you send an INVITE, thinking it can do = some new-fangled codec. But that INVITE makes an H.323 call get setup, whe= re the H.245 from the far-end only did G.711, so the call fails. Then there are 3PCC call scenarios, and middlebox transcoders, and codec-ba= sed routing, etc. Different things happen with INVITES, at different times= , due to different policies - none of which apply to OPTIONS. The reality of the INVITE world is ugly. :( -hadriel ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Wednesday, April 07, 2010 10:05 AM To: Hadriel Kaplan Cc: Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@iet= f.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? In such cases you will get the capabilities of the gateway where the SIP do= main is left. Why isn't that info useful? /Hans Erik van Elburg On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan > wrote: > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:s= ipcore-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Tuesday, April 06, 2010 4:08 PM > To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > Hi Dale, > > From my perspective, the main use-case is not to discover services, but t= o > discover capabilities in order to determine what services can be applied. > > The idea is also that the OPTIONS request would be sent prior to the > INVITE, to try to make sure that the returned contacts are actually > available. But you know that would never work in practice/the-real-world. Think about= all the routing rules people have for INVITEs - in some cases *only* for I= NVITEs. And even if they route OPTIONS identically in the SIP domain, for = any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a H.323-g= ateway, or an MGCP call-agent, or an IP-PBX, or a foobar-protocol-gateway, = or a vmail server, or an announcement server, or an app server, etc. Just = because the OPTIONS reaches the end of the SIP domain, means nothing about = whether an INVITE to the higher-layer target (which in practice is a E.164 = number, that crosses from SIP into many other protocol domains) is actually= available to receive a call. -hadriel _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_430FC6BDED356B4C8498F634416644A91A79F3CFE9mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Because it means nothing about the capabilities for the INVITE, because the INVITE session’s capabilitie= s is dictated by the far-end beyond that gateway.  

 

For example, I don’t know what t= ypes of capabilities you guys are thinking of, but let’s say it was for getting the codecs.  So you send an OPTIONS, and it gets to an H.323 gateway.  The gateway supports lots of codecs, so it gives you some ni= ce big SDP.  Then you send an INVITE, thinking it can do some new-fangled codec.  But that INVITE makes an H.323 call get setup, where the H.245 from the far-end only did G.711, so the call fails.

 

Then there are 3PCC call scenarios, an= d middlebox transcoders, and codec-based routing, etc.  Different things happen with INVITES, at different times, due to different policies – = none of which apply to OPTIONS.

The reality of the INVITE world is ugl= y. L<= /font>

 

-hadriel

 

From: Hans Eri= k van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, April 07, 2= 010 10:05 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; WORLE= Y, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

 

In such cases you= will get the capabilities of the gateway where the SIP domain is left. Why isn't that info useful?

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote= :



> -----Original Message-----
> From: sipcore-bounces@ietf= .org [mailto:sipcore-bounces@ietf.or= g] On Behalf
> Of Christer Holmberg
> Sent: Tuesday, April 06, 2010 4:08 PM
> To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
> Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?
>

> Hi Dale,
>
> From my perspective, the main use-case is not to discover services, bu= t to
> discover capabilities in order to determine what services can be appli= ed.
>
> The idea is also that the OPTIONS request would be sent prior to the > INVITE, to try to make sure that the returned contacts are actually > available.

But you know that would never work in practice/the-real-world.  Think about all the routing rules people have for INVITEs - in some c= ases *only* for INVITEs.  And even if they route OPTIONS identically in the= SIP domain, for any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, = or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a foobar-protocol-gateway, or a vmail server, or an announcement server, or a= n app server, etc.  Just because the OPTIONS reaches the end of the SIP domain, means nothing about whether an INVITE to the higher-layer target (w= hich in practice is a E.164 number, that crosses from SIP into many other protoc= ol domains) is actually available to receive a call.

-hadriel

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

 

--_000_430FC6BDED356B4C8498F634416644A91A79F3CFE9mail_-- From keith.drage@alcatel-lucent.com Wed Apr 7 07:44:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D813A67D1 for ; Wed, 7 Apr 2010 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pbemVGb-jKi for ; Wed, 7 Apr 2010 07:44:21 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id A22D53A6949 for ; Wed, 7 Apr 2010 07:44:17 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o37EgCwO011889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Apr 2010 16:44:07 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 7 Apr 2010 16:43:23 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , SIPCORE Date: Wed, 7 Apr 2010 16:43:21 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAI9U2h9bTvlTTWR2RGyrmXE4gGJHj7A Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: <4BB24B81.1050006@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE211CCD821FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:44:22 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE211CCD821FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the moment, my view is "Do nothing". The amount of resource needed for t= his discussion does not justify the problem. If someone wants to submit an author draft on a specific issue and fix, the= n fine, I'll reconsider. regards Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Tuesday, March 30, 2010 8:06 PM To: SIPCORE Subject: [sipcore] SIP OPTIONS: Shall we work on this? [as chair] One of the topics of discussion at the recent face-to-face meeting in Anahe= im was the SIP OPTIONS method. We have had significant discussion of some s= pecific technical topics on the SIPCORE mailing list, such that all partici= pants should have a reasonable overview of the scope that any related work = may entail. Participants may also benefit from reading through the minutes = of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTI= ONS%20Method Rather than continue discussion of the specific technical topics related to= OPTIONS, the chairs would encourage the working group to engage in a discu= ssion around whether we should, as a group, work on addressing some of the = issues that have been identified. In particular, we would direct the group to consider the nature of such wor= k: * Are we proposing to introduce new features, or fix existing bugs? * If we are adding new features: is OPTIONS the best way to introduce th= ese features, or would other mechanisms (presence, callee-caps) produce sup= erior results? * If we are fixing bugs: are the bugs theoretical, or can we cite actual= interoperability issues in the field? * If there are identified interoperability issues: is the level of effor= t involved in fixing them commensurate with the impact of the problems? Finally, keep in mind that work does not happen unless participants are wil= ling to invest time. If you speak out in favor of pursuing this work, pleas= e indicate the level of time commitment that you will personally invest in = bringing such work to a successful conclusion (e.g., will author drafts; wi= ll perform dedicated reviews; etc). Thanks. /a --_000_EDC0A1AE77C57744B664A310A0B23AE211CCD821FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At the moment, my view is "Do nothing". The amount= of=20 resource needed for this discussion does not justify the=20 problem.
 
If someone wants to submit an author draft on a sp= ecific=20 issue and fix, then fine, I'll reconsider.
 
regards
 
Keith

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: Tuesday, March 30, 2010 8:06 PM
To:=20 SIPCORE
Subject: [sipcore] SIP OPTIONS: Shall we work on=20 this?

[as chair]

One of the topics of discussion at the recen= t=20 face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had=20 significant discussion of some specific technical topics on the SIPCORE=20 mailing list, such that all participants should have a reasonable overvie= w of=20 the scope that any related work may entail. Participants may also benefit= from=20 reading through the minutes of the corresponding conversation in=20 Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipco= re.html#The%20SIP%20OPTIONS%20Method

Rather=20 than continue discussion of the specific technical topics related to OPTI= ONS,=20 the chairs would encourage the working group to engage in a discussion ar= ound=20 whether we should, as a group, work on addressing some of the issues that= have=20 been identified.

In particular, we would direct the group to consi= der=20 the nature of such work:
  • Are we proposing to introduce new features, or fix existing bugs?=20
  • If we are adding new features: is OPTIONS the best way to introduce= =20 these features, or would other mechanisms (presence, callee-caps) produ= ce=20 superior results?
  • If we are fixing bugs: are the bugs theoretical, or can we cite act= ual=20 interoperability issues in the field?=20
  • If there are identified interoperability issues: is the level of ef= fort=20 involved in fixing them commensurate with the impact of the problems?=20
Finally, keep in mind that work does not happen unless particip= ants=20 are willing to invest time. If you speak out in favor of pursuing this wo= rk,=20 please indicate the level of time commitment that you will personally inv= est=20 in bringing such work to a successful conclusion (e.g., will author draft= s;=20 will perform dedicated reviews;=20 etc).

Thanks.

/a
--_000_EDC0A1AE77C57744B664A310A0B23AE211CCD821FRMRSSXCHMBSC3d_-- From adam@nostrum.com Wed Apr 7 07:49:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BD83A68B3 for ; Wed, 7 Apr 2010 07:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Foe3rthz8Tz for ; Wed, 7 Apr 2010 07:49:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 219833A67F3 for ; Wed, 7 Apr 2010 07:49:27 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o37EnImF054409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 09:49:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBC9B6E.6000809@nostrum.com> Date: Wed, 07 Apr 2010 09:49:18 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> Content-Type: multipart/alternative; boundary="------------030909020002090300030707" Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:49:36 -0000 This is a multi-part message in MIME format. --------------030909020002090300030707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as an individual] I think Hadriel is right. The more I read through this thread, the more it looks like we're running around with a hammer, desperately looking for nails to hit. Barring nails, we'll settle for screws. Or bolts. Or maybe kittens, if it comes to that. If you're trying to accomplish something, I would strongly recommend starting from the other end. Instead of saying "I have a tool, let's make a problem for it to solve," let's concentrate on clearly defining existing problems. Once we agree on the problems, we can talk about what tools make sense to solve them. /a On 4/7/10 9:31 AM, Hadriel Kaplan wrote: > > Because it means nothing about the capabilities for the INVITE, > because the INVITE session's capabilities is dictated by the far-end > beyond that gateway. > > For example, I don't know what types of capabilities you guys are > thinking of, but let's say it was for getting the codecs. So you send > an OPTIONS, and it gets to an H.323 gateway. The gateway supports > lots of codecs, so it gives you some nice big SDP. Then you send an > INVITE, thinking it can do some new-fangled codec. But that INVITE > makes an H.323 call get setup, where the H.245 from the far-end only > did G.711, so the call fails. > > Then there are 3PCC call scenarios, and middlebox transcoders, and > codec-based routing, etc. Different things happen with INVITES, at > different times, due to different policies -- none of which apply to > OPTIONS. > > The reality of the INVITE world is ugly. L > > -hadriel > > ------------------------------------------------------------------------ > > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Wednesday, April 07, 2010 10:05 AM > *To:* Hadriel Kaplan > *Cc:* Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; > sipcore@ietf.org > *Subject:* Re: [sipcore] SIP OPTIONS: Shall we work on this? > > In such cases you will get the capabilities of the gateway where the > SIP domain is left. Why isn't that info useful? > > /Hans Erik van Elburg > > On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan > wrote: > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org ] On > Behalf > > Of Christer Holmberg > > Sent: Tuesday, April 06, 2010 4:08 PM > > To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > Hi Dale, > > > > From my perspective, the main use-case is not to discover services, > but to > > discover capabilities in order to determine what services can be applied. > > > > The idea is also that the OPTIONS request would be sent prior to the > > INVITE, to try to make sure that the returned contacts are actually > > available. > > But you know that would never work in practice/the-real-world. Think > about all the routing rules people have for INVITEs - in some cases > *only* for INVITEs. And even if they route OPTIONS identically in the > SIP domain, for any given AoR it'll go to any of: a SIP UA, or a PSTN > gateway, or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a > foobar-protocol-gateway, or a vmail server, or an announcement server, > or an app server, etc. Just because the OPTIONS reaches the end of > the SIP domain, means nothing about whether an INVITE to the > higher-layer target (which in practice is a E.164 number, that crosses > from SIP into many other protocol domains) is actually available to > receive a call. > > -hadriel > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------030909020002090300030707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as an individual]

I think Hadriel is right.

The more I read through this thread, the more it looks like we're running around with a hammer, desperately looking for nails to hit. Barring nails, we'll settle for screws. Or bolts. Or maybe kittens, if it comes to that.

If you're trying to accomplish something, I would strongly recommend starting from the other end. Instead of saying "I have a tool, let's make a problem for it to solve," let's concentrate on clearly defining existing problems. Once we agree on the problems, we can talk about what tools make sense to solve them.

/a

On 4/7/10 9:31 AM, Hadriel Kaplan wrote:

Because it means nothing about the capabilities for the INVITE, because the INVITE session’s capabilities is dictated by the far-end beyond that gateway.  

 

For example, I don’t know what types of capabilities you guys are thinking of, but let’s say it was for getting the codecs.  So you send an OPTIONS, and it gets to an H.323 gateway.  The gateway supports lots of codecs, so it gives you some nice big SDP.  Then you send an INVITE, thinking it can do some new-fangled codec.  But that INVITE makes an H.323 call get setup, where the H.245 from the far-end only did G.711, so the call fails.

 

Then there are 3PCC call scenarios, and middlebox transcoders, and codec-based routing, etc.  Different things happen with INVITES, at different times, due to different policies – none of which apply to OPTIONS.

The reality of the INVITE world is ugly. L

 

-hadriel

 

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, April 07, 2010 10:05 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

 

In such cases you will get the capabilities of the gateway where the SIP domain is left. Why isn't that info useful?

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:



> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> Sent: Tuesday, April 06, 2010 4:08 PM
> To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
> Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?
>

> Hi Dale,
>
> From my perspective, the main use-case is not to discover services, but to
> discover capabilities in order to determine what services can be applied.
>
> The idea is also that the OPTIONS request would be sent prior to the
> INVITE, to try to make sure that the returned contacts are actually
> available.

But you know that would never work in practice/the-real-world.  Think about all the routing rules people have for INVITEs - in some cases *only* for INVITEs.  And even if they route OPTIONS identically in the SIP domain, for any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a foobar-protocol-gateway, or a vmail server, or an announcement server, or an app server, etc.  Just because the OPTIONS reaches the end of the SIP domain, means nothing about whether an INVITE to the higher-layer target (which in practice is a E.164 number, that crosses from SIP into many other protocol domains) is actually available to receive a call.

-hadriel

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

 


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

--------------030909020002090300030707-- From dworley@avaya.com Wed Apr 7 07:50:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CD23A67F3 for ; Wed, 7 Apr 2010 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYcDod8-aqij for ; Wed, 7 Apr 2010 07:50:33 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 888B83A6918 for ; Wed, 7 Apr 2010 07:50:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,378,1267419600"; d="scan'208";a="10612345" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 07 Apr 2010 10:50:25 -0400 X-IronPort-AV: E=Sophos;i="4.51,378,1267419600"; d="scan'208";a="449471172" Received: from unknown (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Apr 2010 10:49:54 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Wed, 7 Apr 2010 10:49:54 -0400 From: "WORLEY, DALE R (DALE)" To: Christer Holmberg , "Elwell, John" , Hans Erik van Elburg Date: Wed, 7 Apr 2010 10:46:01 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5AAA7P1UA== Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:50:34 -0000 ________________________________________ From: Christer Holmberg [christer.holmberg@ericsson.com] Now, I am not saying that you need to send OPTIONS prior to every call. My = main use-case is where the INVITE itself may look different depending on th= e capabilities. So, again, an INVITE may not even fail, but you may not get= exactly what you would have wanted. ________________________________________ If the UAC would send different INVITEs based on its idea of what facilitie= s are present in the potential UASs, that is a severe failure of the archit= ecture of the SIP system. In proper use of SIP, the UAC specifies what it = prefers in the INVITE, and the intermediate and destination elements determ= ine how those preferences are to be satisfied based on the destination reso= urces available at the moment of the INVITE. If you have a use-case where the UAC cannot specify its needs in a way that= conforms to the SIP architecture, there is a need for enhancement of how S= IP allows the UAC to express its preferences. Dale From adam@nostrum.com Wed Apr 7 07:53:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96633A689F for ; Wed, 7 Apr 2010 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRG6+w0K4Pw0 for ; Wed, 7 Apr 2010 07:53:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C28493A6A43 for ; Wed, 7 Apr 2010 07:52:52 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o37Eqeq7054729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 09:52:40 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBC9C38.5000703@nostrum.com> Date: Wed, 07 Apr 2010 09:52:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010800010807050609070801" Cc: SIPCORE Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:53:00 -0000 This is a multi-part message in MIME format. --------------010800010807050609070801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as an individual] On 4/7/10 9:43 AM, DRAGE, Keith (Keith) wrote: > At the moment, my view is "Do nothing". The amount of resource needed > for this discussion does not justify the problem. I'm inclined to agree. > If someone wants to submit an author draft on a specific issue and > fix, then fine, I'll reconsider. To be fair, someone has. http://www.ietf.org/id/draft-jones-sip-options-ping-00.txt I'm not saying I support this document (nor do I necessarily oppose it), but there *is* a concrete proposal on the table. /a --------------010800010807050609070801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as an individual]

On 4/7/10 9:43 AM, DRAGE, Keith (Keith) wrote:
At the moment, my view is "Do nothing". The amount of resource needed for this discussion does not justify the problem.

I'm inclined to agree.

If someone wants to submit an author draft on a specific issue and fix, then fine, I'll reconsider.

To be fair, someone has.

http://www.ietf.org/id/draft-jones-sip-options-ping-00.txt

I'm not saying I support this document (nor do I necessarily oppose it), but there *is* a concrete proposal on the table.

/a
--------------010800010807050609070801-- From dworley@avaya.com Wed Apr 7 07:55:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE993A6858 for ; Wed, 7 Apr 2010 07:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6o8A8-Anlyn for ; Wed, 7 Apr 2010 07:55:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 091BA3A67F6 for ; Wed, 7 Apr 2010 07:55:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,378,1267419600"; d="scan'208";a="183331718" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Apr 2010 10:55:41 -0400 X-IronPort-AV: E=Sophos;i="4.51,378,1267419600"; d="scan'208";a="449473570" Received: from unknown (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Apr 2010 10:55:40 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 7 Apr 2010 10:55:40 -0400 From: "WORLEY, DALE R (DALE)" To: Adam Roach , Hadriel Kaplan Date: Wed, 7 Apr 2010 10:55:39 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWYYOh0zMyItviRnajhw1gKuwb6wAACSck Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail>, <4BBC9B6E.6000809@nostrum.com> In-Reply-To: <4BBC9B6E.6000809@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:55:47 -0000 ________________________________________ From: Adam Roach [adam@nostrum.com] [as an individual] If you're trying to accomplish something, I would strongly recommend starti= ng from the other end. Instead of saying "I have a tool, let's make a probl= em for it to solve," let's concentrate on clearly defining existing problem= s. Once we agree on the problems, we can talk about what tools make sense t= o solve them. ________________________________ I think that Christer has a definite use situation in mind but hash't been = very clear about exactly what it is. IMHO, we need to consider several questions: 1. Is the proposed mechanism well-built? 2. Is the proposed mechanism a good way to achieve the desired functionalit= y? 3. Is the desired functionality an architecturally sound way to satisfy the= users' need? Now, I think that clarifying how OPTIONS works is in general a good thing, = even if the answer to questions 2 and 3 are No. But to take this up as rea= l WG work, we need to verify that questions 2 and 3 are Yes, before we star= t worrying about the details of the proposal. So the first task is to lay out the users' needs that we are trying to addr= ess, and see if this sort of usage of OPTIONs is a reasonable solution to t= hem. Dale From dworley@avaya.com Wed Apr 7 08:19:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E573528C126 for ; Wed, 7 Apr 2010 08:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiId-1gqft-e for ; Wed, 7 Apr 2010 08:19:40 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B939128C139 for ; Wed, 7 Apr 2010 08:17:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,378,1267419600"; d="scan'208";a="183335969" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Apr 2010 11:17:24 -0400 X-IronPort-AV: E=Sophos;i="4.51,378,1267419600"; d="scan'208";a="462375841" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Apr 2010 11:17:23 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 7 Apr 2010 11:17:23 -0400 From: "WORLEY, DALE R (DALE)" To: Hans Erik van Elburg , "Elwell, John" Date: Wed, 7 Apr 2010 11:17:22 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0LLs1qEjkT6S0mIIkvpEV3q7wAMQhlM Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 15:19:42 -0000 ________________________________________ From: Hans Erik van Elburg [ietf.hanserik@gmail.com] Of course you can implement all kind of policies, but that makes this AOR q= uite of a special user. I would argue that this is some kind of service AOR= and not a "normal" user AOR. The service AOR representing a group of diffe= rent and dynamically changing users... ________________________________________ But a lot of AORs actually are service AORs and not "normal" users (that re= present a small set of UAs that is fixed over long periods of time). Worse= , "service" AORs account for a much larger fraction of the traffic than the= ir numbers indicate. Consider "my company's IT helpdesk number". You don'= t want to invent a mechanism that works for 90% of the AORs but only 10% of= the calls made. But also consider any sort of "intelligent network services". Even moderat= ely sophisticated call forwarding for a private household can eradicate the= concept that an AOR is the front-end for a definite set of UAs. If you want to get a call to the "right" destination, send the INVITE to th= e AOR. Processing incoming INVITEs in a sensible manner is the one SIP fun= ctionality every intermediate element is likely to get right, because other= wise users would notice and complain. And the only alternative is for the = UAC to attempt to second-guess all the routing processing of every intermed= iate element, and every UAS, of every AOR. Dale From pkyzivat@cisco.com Wed Apr 7 08:19:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B774628C134 for ; Wed, 7 Apr 2010 08:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.304 X-Spam-Level: X-Spam-Status: No, score=-10.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w18ALy8IMlVJ for ; Wed, 7 Apr 2010 08:19:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B2D6C28C0FF for ; Wed, 7 Apr 2010 08:17:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEI/vEtAZnwM/2dsb2JhbACbPHGjApkghQkE X-IronPort-AV: E=Sophos;i="4.51,378,1267401600"; d="scan'208";a="99580013" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2010 15:17:33 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o37FHXuF023462; Wed, 7 Apr 2010 15:17:33 GMT Message-ID: <4BBCA20B.5040601@cisco.com> Date: Wed, 07 Apr 2010 11:17:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 15:19:44 -0000 [as individual] Christer Holmberg wrote: > Hi, > >>>> Is there *any* problem here? This seems to be working about as well >>>> as anyone might hope. >>>> >>> It works okay excluding the non backward compatibility with RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)... >> I don't think it's accurate to characterize the change as >> non-backwards-compatible. The only wire-visible behavior that >> one could conceivable observe is that a subscriber might make >> a different decision about which subscription to accept if >> the SUBSCRIBE forks and the subscriber wants only one subscription. >> >> What we *do* gain is a simplification for implementors. >> Because the behavior of establishing the dialog when a NOTIFY >> shows up (instead of "the first of a 2xx or a NOTIFY) is much >> easier to code, people will make fewer mistakes, and have >> fewer bugs. But you'd be hard pressed to see a difference on the wire. > > I agree with Adam. > > Of course, for resubscriptions we don't have the forking issue, but I still think we should have the same behavior, ie the NOTIFY acknowledges the resub. > > ...and, again, that is why I have an issue with allowing the suppression of NOTIFYs. It's not a problem for endpoints, but for stateful intermediaries (proxies ARE allowed to Record-Route SUB requests, so) I think you just explained why NOTIFY should *not* ack the resub. The response to the reSUBSCRIBE is important, to the transaction, and to the subscribe usage status. Timer-N *could* still apply to the resulting NOTIFY, if one is expected, and the subscriber would then need to consider the usage broken if it isn't received. But in that case I think it would need to send another reSUBSCRIBE with Expires:0 to terminate the subscription - which would satisfy any intermediaries that were otherwise confused. Whether applying timer-N to resubscribes is a *good* thing is not immediately clear to me. If the resubscribe is just intended as a refresh, then having to time it is an inconvenience. OTOH, if the resubscribe is a poll, or a way to change the filter in effect, then the immediate notify is probably desired. One think I noted when checking the bis on this is that the state diagram doesn't mention 408 responses. I think it should initiate a teardown of the usage. Thanks, Paul >>> The draft's Timer N (and lack of related NOTIFY) text is potentially >>> worded in a way which does not require the tear down (and non >>> creation) of subscription. >> Tear-down of existing dialogs is still an open issue, sure. I >> don't get where you see any wiggle room in what happens if >> Timer N fires for the first SUBSCRIBE/NOTIFY exchange. > > For the initial SUB/NOT, I think that tearing down the dialog is the only thing you can do. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ietf.hanserik@gmail.com Wed Apr 7 08:30:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F683A6967 for ; Wed, 7 Apr 2010 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jga49F3nCyKr for ; Wed, 7 Apr 2010 08:30:35 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 0D10C3A698A for ; Wed, 7 Apr 2010 08:29:01 -0700 (PDT) Received: by ewy24 with SMTP id 24so609001ewy.13 for ; Wed, 07 Apr 2010 08:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Ql2HL6Se94vYO5QiQfS7qcvJZ6TwLDquaTGY7L0MSxs=; b=CT87bYUKGZQuqGzhZrK5ug5jpoJrKBh+Qq99fLIxizrMSGGOWt+rPCgoIkd5pdL9rj +juEZqKOWgzPRb/DHlIwER4nzxxQ94qd1HH70/eEAuKIwlcrAEvQbh3PWj8KnnQ/r2qc /9pz9tsuixrMV3ypbMS4NlFe69VEvWmVZm4og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YggrJK37/jhI1RmNAznV/7Fk8T3+J4I54JGESQS4XmG8+aCPQ89zVZphbJ6mox+0yb sDbL86SZTbxHKIuf8kY10BUQGGOx4HqE7qZJnQJ/Ck9yawprf2KRQSCNtjZEUJMUgNFY on0GghRV5zdRYTu2SZhde4rfItyFCg6Y9gJr0= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 08:28:52 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> Date: Wed, 7 Apr 2010 17:28:52 +0200 Received: by 10.213.47.83 with SMTP id m19mr2028113ebf.92.1270654132964; Wed, 07 Apr 2010 08:28:52 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001485ea7dca3a4ec10483a73834 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 15:30:37 -0000 --001485ea7dca3a4ec10483a73834 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Your real world scenario breaks any SIP specific feature... ;-) Not sure if that was your point. Still unclear what use case we are discussing here... but OPTIONS does not necessarily need be used in combination with INVITE. Just speculating: It could be used by application servers to detect the capabilities devices a user has registered and do something with that. In those scenarios maybe a presence server is to much of a burden and there is no dark interworking nightmare that needs to be taken into account. 3xx could well be used in this scenario to get all the capabilities of all the registered devices. /Hans Erik van Elburg On Wed, Apr 7, 2010 at 4:31 PM, Hadriel Kaplan wrot= e: > Because it means nothing about the capabilities for the INVITE, because > the INVITE session=92s capabilities is dictated by the far-end beyond tha= t > gateway. > > > > For example, I don=92t know what types of capabilities you guys are think= ing > of, but let=92s say it was for getting the codecs. So you send an OPTION= S, > and it gets to an H.323 gateway. The gateway supports lots of codecs, so= it > gives you some nice big SDP. Then you send an INVITE, thinking it can do > some new-fangled codec. But that INVITE makes an H.323 call get setup, > where the H.245 from the far-end only did G.711, so the call fails. > > > > Then there are 3PCC call scenarios, and middlebox transcoders, and > codec-based routing, etc. Different things happen with INVITES, at > different times, due to different policies =96 none of which apply to OPT= IONS. > > The reality of the INVITE world is ugly. L > > > > -hadriel > > > ------------------------------ > > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Wednesday, April 07, 2010 10:05 AM > *To:* Hadriel Kaplan > *Cc:* Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; > sipcore@ietf.org > > *Subject:* Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > In such cases you will get the capabilities of the gateway where the SIP > domain is left. Why isn't that info useful? > > /Hans Erik van Elburg > > On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan > wrote: > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > > Of Christer Holmberg > > Sent: Tuesday, April 06, 2010 4:08 PM > > To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org > > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > Hi Dale, > > > > From my perspective, the main use-case is not to discover services, but > to > > discover capabilities in order to determine what services can be applie= d. > > > > The idea is also that the OPTIONS request would be sent prior to the > > INVITE, to try to make sure that the returned contacts are actually > > available. > > But you know that would never work in practice/the-real-world. Think abo= ut > all the routing rules people have for INVITEs - in some cases *only* for > INVITEs. And even if they route OPTIONS identically in the SIP domain, f= or > any given AoR it'll go to any of: a SIP UA, or a PSTN gateway, or a > H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a > foobar-protocol-gateway, or a vmail server, or an announcement server, or= an > app server, etc. Just because the OPTIONS reaches the end of the SIP > domain, means nothing about whether an INVITE to the higher-layer target > (which in practice is a E.164 number, that crosses from SIP into many oth= er > protocol domains) is actually available to receive a call. > > -hadriel > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --001485ea7dca3a4ec10483a73834 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Your real=A0 world scenario breaks any SIP specific feature... ;-)
Not s= ure if that was your point.

Still unclear what use case we are discu= ssing here... but OPTIONS does not necessarily need be used in combination = with INVITE.

Just speculating: It could be used by application servers to detect the= capabilities devices a user has registered and do something with that. In = those scenarios maybe a presence server is to much of a burden and there is= no dark interworking nightmare that needs to be taken into account. 3xx co= uld well be used in this scenario to get all the capabilities of all the re= gistered devices.

/Hans Erik van Elburg


On Wed, Apr 7, 2010 at 4:31 PM, Hadriel = Kaplan <HKap= lan@acmepacket.com> wrote:

Because it mea= ns nothing about the capabilities for the INVITE, because the INVITE session=92s capabilities is dictated by the far-end beyond that gateway. =A0

=A0

For example, I= don=92t know what types of capabilities you guys are thinking of, but let=92s say it was for getting the codecs.=A0 So you send an OPTIONS, and it gets to an H.323 gateway. =A0The gateway supports lots of codecs, so it gives you some nice big SDP. =A0Then you send an INVITE, thinking it can do some new-fangled codec.=A0 But that INVITE makes an H.323 call get setup, where the H.245 from the far-end only did G.711, so the call fails.

=A0

Then there are= 3PCC call scenarios, and middlebox transcoders, and codec-based routing, etc.=A0 Different things happen with INVITES, at different times, due to different policies =96 none of which apply to OPTIONS.

The reality of= the INVITE world is ugly. L<= span style=3D"font-size: 10pt; font-family: Arial; color: navy;">

=A0

-hadriel

=A0

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, April 07,= 2010 10:05 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; WOR= LEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org


Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

=A0

In such cases you wil= l get the capabilities of the gateway where the SIP domain is left. Why isn&#= 39;t that info useful?

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 3:53 PM, Hadriel Kaplan <<= a href=3D"mailto:HKaplan@acmepacket.com" target=3D"_blank">HKaplan@acmepack= et.com> wrote:



> -----Original Message-----
> From: si= pcore-bounces@ietf.org [mailto:sipco= re-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> Sent: Tuesday, April 06, 2010 4:08 PM
> To: WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
> Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?
>

> Hi Dale,
>
> From my perspective, the main use-case is not to discover services, bu= t to
> discover capabilities in order to determine what services can be appli= ed.
>
> The idea is also that the OPTIONS request would be sent prior to the > INVITE, to try to make sure that the returned contacts are actually > available.

But you know that would never work in practice/the-r= eal-world. =A0Think about all the routing rules people have for INVITEs - in some case= s *only* for INVITEs. =A0And even if they route OPTIONS identically in the SI= P domain, for any given AoR it'll go to any of: a SIP UA, or a PSTN gatew= ay, or a H.323-gateway, or an MGCP call-agent, or an IP-PBX, or a foobar-protocol-gateway, or a vmail server, or an announcement server, or a= n app server, etc. =A0Just because the OPTIONS reaches the end of the SIP domain, means nothing about whether an INVITE to the higher-layer target (w= hich in practice is a E.164 number, that crosses from SIP into many other protoc= ol domains) is actually available to receive a call.

-hadriel

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

=A0


--001485ea7dca3a4ec10483a73834-- From dworley@avaya.com Wed Apr 7 08:37:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1683A3A6993 for ; Wed, 7 Apr 2010 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpd-eWBTdx8y for ; Wed, 7 Apr 2010 08:37:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 77A2C3A695C for ; Wed, 7 Apr 2010 08:37:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,379,1267419600"; d="scan'208";a="183339438" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Apr 2010 11:37:26 -0400 X-IronPort-AV: E=Sophos;i="4.51,379,1267419600"; d="scan'208";a="449494711" Received: from unknown (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Apr 2010 11:37:25 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 7 Apr 2010 11:37:25 -0400 From: "WORLEY, DALE R (DALE)" To: Christer Holmberg , Adam Roach , Brett Tate Date: Wed, 7 Apr 2010 11:34:36 -0400 Thread-Topic: [sipcore] rfc3265bis Thread-Index: AQHK1mg412SpQXMxfUKywAmd7vTkkQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 15:37:33 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Of course, for resubscriptions we don't have the forking issue, but I still= think we should have the same behavior, ie the NOTIFY acknowledges the res= ub. _______________________________________________ rfc3265bis isn't particularly clear on the point, but it looks like the 200= response to the re-SUBSCRIBE extends the subscription expiration time know= n by the subscriber. So an intermediate element that tracks the subscriptio= n has to be watching for such responses, too. Given that, the fact that su= b-not suppresses the NOTIFY is not a problem. Dale From christer.holmberg@ericsson.com Wed Apr 7 10:22:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B803A6957 for ; Wed, 7 Apr 2010 10:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu9oRZs48IXc for ; Wed, 7 Apr 2010 10:22:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 68B4F3A690C for ; Wed, 7 Apr 2010 10:21:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-56-4bbcbf29f7fe Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 3D.78.23532.92FBCBB4; Wed, 7 Apr 2010 19:21:45 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 7 Apr 2010 19:21:45 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 7 Apr 2010 19:21:44 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrWZXRzkIDWcZb9QMqJn/hAGEV/lQAEEFKA Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> , <4BBCA20B.5040601@cisco.com> In-Reply-To: <4BBCA20B.5040601@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: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:22:45 -0000 Hi, >>>>> Is there *any* problem here? This seems to be working about as well >>>>> as anyone might hope. >>>>> >>>> It works okay excluding the non backward compatibility with RFC 3265 (= concerning SUBSCRIBE's 2xx response impacts)... >>> I don't think it's accurate to characterize the change as >>> non-backwards-compatible. The only wire-visible behavior that >>> one could conceivable observe is that a subscriber might make >>> a different decision about which subscription to accept if >>> the SUBSCRIBE forks and the subscriber wants only one subscription. >>> >>> What we *do* gain is a simplification for implementors. >>> Because the behavior of establishing the dialog when a NOTIFY >>> shows up (instead of "the first of a 2xx or a NOTIFY) is much >>> easier to code, people will make fewer mistakes, and have >>> fewer bugs. But you'd be hard pressed to see a difference on the wire. >> >> I agree with Adam. >> >> Of course, for resubscriptions we don't have the forking issue, but I st= ill think we should have the same behavior, ie the NOTIFY acknowledges the = resub. >> >> ...and, again, that is why I have an issue with allowing the suppression= of NOTIFYs. It's not a problem for endpoints, but for stateful intermediar= ies (proxies ARE allowed to Record-Route SUB requests, so) > >I think you just explained why NOTIFY should *not* ack the resub. Sure, if the SUB 200 response acks the resub, there should be no problem. I just assumed that the NOT request (or response) would ack also resubs, to= make the state machine consistant with initial subs. But, if that is not t= he case, we need to make it VERY clear in 3265bis. >The response to the reSUBSCRIBE is important, to the transaction, and to t= he subscribe usage status. > >Timer-N *could* still apply to the resulting NOTIFY, if one is expected, >and the subscriber would then need to consider the usage broken if it >isn't received. But in that case I think it would need to send another >reSUBSCRIBE with Expires:0 to terminate the subscription - which would >satisfy any intermediaries that were otherwise confused. That could work. >Whether applying timer-N to resubscribes is a *good* thing is not >immediately clear to me. If the resubscribe is just intended as a >refresh, then having to time it is an inconvenience. OTOH, if the >resubscribe is a poll, or a way to change the filter in effect, then the >immediate notify is probably desired. I guess it would be good to be able to indicate whether an immediate notify= is required, in such indicator could start timer-N. But, all entities woul= d of course have to understand such indicator. Regards, Christer One think I noted when checking the bis on this is that the state diagram doesn't mention 408 responses. I think it should initiate a teardown of the usage. Thanks, Paul >>> The draft's Timer N (and lack of related NOTIFY) text is potentially >>> worded in a way which does not require the tear down (and non >>> creation) of subscription. >> Tear-down of existing dialogs is still an open issue, sure. I >> don't get where you see any wiggle room in what happens if >> Timer N fires for the first SUBSCRIBE/NOTIFY exchange. > > For the initial SUB/NOT, I think that tearing down the dialog is the only= thing you can do. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >= From christer.holmberg@ericsson.com Wed Apr 7 10:24:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D4B3A6870 for ; Wed, 7 Apr 2010 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.308 X-Spam-Level: X-Spam-Status: No, score=-3.308 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIxM0hCXpOXK for ; Wed, 7 Apr 2010 10:24:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 64E443A6979 for ; Wed, 7 Apr 2010 10:24:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9c-4bbcbfe14444 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D4.D6.23740.1EFBCBB4; Wed, 7 Apr 2010 19:24:49 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 7 Apr 2010 19:24:49 +0200 From: Christer Holmberg To: "WORLEY, DALE R (DALE)" , Adam Roach , Brett Tate Date: Wed, 7 Apr 2010 19:23:20 +0200 Thread-Topic: [sipcore] rfc3265bis Thread-Index: AQHK1mg412SpQXMxfUKywAmd7vTkkZIXQTi9 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:24:57 -0000 Hi, >>Of course, for resubscriptions we don't have the forking issue, but I sti= ll think we should have the same >>behavior, ie the NOTIFY acknowledges the= resub. >> >rfc3265bis isn't particularly clear on the point, but it looks like the 20= 0 response to the re-SUBSCRIBE >extends the subscription expiration time kn= own by the subscriber. So an intermediate element that tracks the >subscrip= tion has to be watching for such responses, too. Given that, the fact that= sub-not suppresses the >NOTIFY is not a problem. Agree. So, if we choose that way forward, we need to make sure it is explicitly in= dicated in 3265bis, or I am sure we will sooner or later end up with implem= entation issues. Regards, Christer= From adam@nostrum.com Wed Apr 7 11:13:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198D83A693C for ; Wed, 7 Apr 2010 11:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geq34-thJCfG for ; Wed, 7 Apr 2010 11:13:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F300028C0DC for ; Wed, 7 Apr 2010 11:13:47 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o37IDcKa070183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 13:13:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBCCB52.7080302@nostrum.com> Date: Wed, 07 Apr 2010 13:13:38 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> In-Reply-To: <4BBCA20B.5040601@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:13:58 -0000 [as individual] Paul Kyzivat wrote: > One think I noted when checking the bis on this is that the state > diagram doesn't mention 408 responses. I think it should initiate a > teardown of the usage. 408 responses aren't allowed for non-invite transactions. /a From pkyzivat@cisco.com Wed Apr 7 11:29:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9DA3A6964 for ; Wed, 7 Apr 2010 11:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLq47idTgToh for ; Wed, 7 Apr 2010 11:29:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0E2733A699C for ; Wed, 7 Apr 2010 11:29:05 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMprvEtAZnwN/2dsb2JhbACbInGjKJkdhQkE X-IronPort-AV: E=Sophos;i="4.52,164,1270425600"; d="scan'208";a="99636538" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2010 18:29:02 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o37IT2CF000243; Wed, 7 Apr 2010 18:29:02 GMT Message-ID: <4BBCCEEE.1050909@cisco.com> Date: Wed, 07 Apr 2010 14:29:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> In-Reply-To: <4BBCCB52.7080302@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:29:26 -0000 [as individual] Adam Roach wrote: > [as individual] > > Paul Kyzivat wrote: >> One think I noted when checking the bis on this is that the state >> diagram doesn't mention 408 responses. I think it should initiate a >> teardown of the usage. > > 408 responses aren't allowed for non-invite transactions. Huh??? Of course they are. Any request can time out. Thanks, Paul From brett@broadsoft.com Wed Apr 7 11:34:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FAB3A688C for ; Wed, 7 Apr 2010 11:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPef-x-3H5pk for ; Wed, 7 Apr 2010 11:34:27 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id E07323A697A for ; Wed, 7 Apr 2010 11:33:50 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 7 Apr 2010 11:33:47 -0700 From: Brett Tate To: Paul Kyzivat , Adam Roach , SIPCORE Date: Wed, 7 Apr 2010 11:32:58 -0700 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrWgDWTGYv3VegjQQqrUJ8MYsXTBAAADkAw Message-ID: <747A6506A991724FB09B129B79D5FEB61480C5626B@EXMBXCLUS01.citservers.local> References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> <4BBCCEEE.1050909@cisco.com> In-Reply-To: <4BBCCEEE.1050909@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 Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:34:28 -0000 I assume that Adam is referring to RFC 4320. However as discussed within t= he following thread, the 408's can still be received. https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-April/024774.= html=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, April 07, 2010 2:29 PM > To: Adam Roach > Cc: Christer Holmberg; Brett Tate; SIPCORE > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes > Posted] >=20 > [as individual] >=20 > Adam Roach wrote: > > [as individual] > > > > Paul Kyzivat wrote: > >> One think I noted when checking the bis on this is that the state > >> diagram doesn't mention 408 responses. I think it should initiate a > >> teardown of the usage. > > > > 408 responses aren't allowed for non-invite transactions. >=20 > Huh??? >=20 > Of course they are. Any request can time out. >=20 > Thanks, > Paul From adam@nostrum.com Wed Apr 7 11:37:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A1B3A693C for ; Wed, 7 Apr 2010 11:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecuIEvYCxChH for ; Wed, 7 Apr 2010 11:36:59 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1D6773A6947 for ; Wed, 7 Apr 2010 11:36:22 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o37IaEr6071887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 13:36:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBCD09E.8020403@nostrum.com> Date: Wed, 07 Apr 2010 13:36:14 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> <4BBCCEEE.1050909@cisco.com> In-Reply-To: <4BBCCEEE.1050909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:37:00 -0000 On 4/7/10 1:29 PM, Paul Kyzivat wrote: > [as individual] > > Adam Roach wrote: >> [as individual] >> >> Paul Kyzivat wrote: >>> One think I noted when checking the bis on this is that the state >>> diagram doesn't mention 408 responses. I think it should initiate a >>> teardown of the usage. >> >> 408 responses aren't allowed for non-invite transactions. > > Huh??? > > Of course they are. Any request can time out. RFC 4320, section 4.2: "A transaction-stateful SIP element MUST NOT send a response with Status-Code of 408 to a non-INVITE request." The rationale for this normative update to 3261 is given in section 1.4 of RFC 4321. /a From pkyzivat@cisco.com Wed Apr 7 11:52:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33633A6955 for ; Wed, 7 Apr 2010 11:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFP2IvgsR+Sa for ; Wed, 7 Apr 2010 11:52:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 846FD3A67B2 for ; Wed, 7 Apr 2010 11:52:18 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKZxvEtAZnwN/2dsb2JhbACbInGjC5kehQkE X-IronPort-AV: E=Sophos;i="4.52,164,1270425600"; d="scan'208";a="99644998" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2010 18:52:15 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o37IqFYp008945; Wed, 7 Apr 2010 18:52:15 GMT Message-ID: <4BBCD45F.6040405@cisco.com> Date: Wed, 07 Apr 2010 14:52:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> <4BBCCEEE.1050909@cisco.com> <4BBCD09E.8020403@nostrum.com> In-Reply-To: <4BBCD09E.8020403@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:52:19 -0000 [as individual] Sorry. Perhaps I was being imprecise. I'm used to talking about receiving a 408 as synonymous with "receiving a 408 or having the transaction time out". Some stacks will return a 408 as a result of timeout even though one was never received. The point remains - if some transaction in the usage times out, and the presumption is that the usage is then dead, I think its expected that there will still be signaling to indicate its being torn down, isn't there? Assuming this happens to the subscriber, shouldn't it send a reSUBSCRIBE with Expires:0 to explicitly terminate it. (Just as a BYE would be sent if this happened within an INVITE usage.) Thanks, Paul Adam Roach wrote: > On 4/7/10 1:29 PM, Paul Kyzivat wrote: >> [as individual] >> >> Adam Roach wrote: >>> [as individual] >>> >>> Paul Kyzivat wrote: >>>> One think I noted when checking the bis on this is that the state >>>> diagram doesn't mention 408 responses. I think it should initiate a >>>> teardown of the usage. >>> >>> 408 responses aren't allowed for non-invite transactions. >> >> Huh??? >> >> Of course they are. Any request can time out. > > RFC 4320, section 4.2: "A transaction-stateful SIP element MUST NOT send > a response with Status-Code of 408 to a non-INVITE request." The > rationale for this normative update to 3261 is given in section 1.4 of > RFC 4321. > > /a > From dean.willis@softarmor.com Wed Apr 7 14:19:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716373A68F9 for ; Wed, 7 Apr 2010 14:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlUb3ut1ShWl for ; Wed, 7 Apr 2010 14:19:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1EF953A6956 for ; Wed, 7 Apr 2010 14:19:25 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o37LJGRa023147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Apr 2010 16:19:18 -0500 Message-Id: <871B0DB3-20AC-4ADB-8639-4E237F6FB9A7@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 16:19:11 -0500 References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:19:28 -0000 On Apr 7, 2010, at 6:35 AM, Christer Holmberg wrote: > > If we don't like OPTIONS, let's deprecate it... Having methods and > functions, but at the same time saying that it doesn't work and we > therefor shouldn't use it, is very confusing... > As I'm no longer the SIP chair, I think I can say that I feel the same way about forking. If we deprecate that, we fix the forking OPTIONS problem at the same time. Seriously, OPTIONS+forking is a bad combination. If we don't formally deprecate forking, at least we can recommend it not be used for OPTIONS requests. Or we could amend 3261 to say "proxies MUST NOT fork OPTIONS request messages". Or we could add an options tag, and say "Proxies that support this extension MUST NOT fork OPTIONS". Or we could go back to our comfortable head-in-sand positions. I'm OK with that; I just pull mine out occasionally to laugh at the other ostrich-bottoms on display. -- Dean From dean.willis@softarmor.com Wed Apr 7 14:21:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C1A3A6998 for ; Wed, 7 Apr 2010 14:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XUiWjoa2uW3 for ; Wed, 7 Apr 2010 14:21:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0427B3A6990 for ; Wed, 7 Apr 2010 14:21:48 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o37LLg54023187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Apr 2010 16:21:43 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 16:21:36 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-subnot-etags: When to include SIP-Etag in NOTIFY? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:21:52 -0000 On Apr 7, 2010, at 7:59 AM, Christer Holmberg wrote: > > > So, the question is: is a subnot-etags compliant notifier required > to insert the SIP-Etag in *every* NOT request, or only in the cases > explicitly described in Section 6? I believe the answer is "always". I also believe I just saw an Auth 48 request come out on this draft. Anybody else got a bug to fix? -- Dean From dean.willis@softarmor.com Wed Apr 7 14:24:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED003A68F9 for ; Wed, 7 Apr 2010 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDNnttxV0Njt for ; Wed, 7 Apr 2010 14:23:59 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 71F203A688D for ; Wed, 7 Apr 2010 14:23:58 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o37LNk8c023241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Apr 2010 16:23:48 -0500 Message-Id: <03034827-7D27-45A1-A67B-08810986B929@softarmor.com> From: Dean Willis To: Dean Willis In-Reply-To: <871B0DB3-20AC-4ADB-8639-4E237F6FB9A7@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 16:23:41 -0500 References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <871B0DB3-20AC-4ADB-8639-4E237F6FB9A7@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:24:00 -0000 On Apr 7, 2010, at 4:19 PM, Dean Willis wrote: > > Seriously, OPTIONS+forking is a bad combination. If we don't > formally deprecate forking, at least we can recommend it not be used > for OPTIONS requests. Or we could amend 3261 to say "proxies MUST > NOT fork OPTIONS request messages". Or we could add an options tag, > and say "Proxies that support this extension MUST NOT fork OPTIONS". > I left out OR we require that a proxy that would ordinarily fork the request instead act as a B2BUA and return an aggregate response. -- Dean From christer.holmberg@ericsson.com Wed Apr 7 14:31:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432A13A691F for ; Wed, 7 Apr 2010 14:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA53weRJ4JWh for ; Wed, 7 Apr 2010 14:31:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CBA403A677E for ; Wed, 7 Apr 2010 14:31:03 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9a-4bbcf993b8a1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 53.AF.23740.399FCBB4; Wed, 7 Apr 2010 23:30:59 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 7 Apr 2010 23:30:59 +0200 From: Christer Holmberg To: Dean Willis Date: Wed, 7 Apr 2010 23:26:11 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWmKF+FVJpoI9nThSNedwRxvQpQAAAFB4c Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <871B0DB3-20AC-4ADB-8639-4E237F6FB9A7@softarmor.com>, <03034827-7D27-45A1-A67B-08810986B929@softarmor.com> In-Reply-To: <03034827-7D27-45A1-A67B-08810986B929@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:31:07 -0000 Hi, >Seriously, OPTIONS+forking is a bad combination. If we don't >formally deprecate forking, at least we can recommend it not be used >for OPTIONS requests. Or we could amend 3261 to say "proxies MUST >NOT fork OPTIONS request messages". Or we could add an options tag, >and say "Proxies that support this extension MUST NOT fork OPTIONS". Using the O-3xx (I'm getting tired of writing OPTIONS 3xx :) mechanism the = OPTIONS request isn't forked. >I left out OR we require that a proxy that would ordinarily fork the reque= st instead act as a B2BUA and=20 >return an aggregate response. That is of course one alternative, but the "beauty" of O-3xx is that you do= n't need to standardize anything. The tools are available (yes, I know we c= an't be 100% sure that it will always work), so the question is whether we = somehow want to document how we can solve the forking problem by combining = those tools. Regards, Christer= From christer.holmberg@ericsson.com Wed Apr 7 14:33:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0603A6956 for ; Wed, 7 Apr 2010 14:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.305 X-Spam-Level: X-Spam-Status: No, score=-3.305 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy4JZbxEPYz9 for ; Wed, 7 Apr 2010 14:33:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4DDFF3A68EF for ; Wed, 7 Apr 2010 14:33:32 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-38-4bbcfa281a69 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A6.BF.23740.82AFCBB4; Wed, 7 Apr 2010 23:33:28 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 7 Apr 2010 23:33:28 +0200 From: Christer Holmberg To: Dean Willis Date: Wed, 7 Apr 2010 23:31:46 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-subnot-etags: When to include SIP-Etag in NOTIFY? Thread-Index: AcrWmFVsOZpzRExQSBO+RnWw2pkuVQAAWReB Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-subnot-etags: When to include SIP-Etag in NOTIFY? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:33:33 -0000 Hi, >> So, the question is: is a subnot-etags compliant notifier required >> to insert the SIP-Etag in *every* NOT request, or only in the cases >> explicitly described in Section 6? > > >I believe the answer is "always". > >I also believe I just saw an Auth 48 request come out on this draft. >Anybody else got a bug to fix? In 3265bis we are aiming at getting rid of the 202 response. The subnot dra= ft defines another one, 204, but I guess it doesn't matter since only endpo= ints supporting the draft are going to send and receive it. Regards, Christer= From adam@nostrum.com Wed Apr 7 14:40:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A0E3A6968 for ; Wed, 7 Apr 2010 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb-sSvWGV4o4 for ; Wed, 7 Apr 2010 14:40:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C31BF3A688D for ; Wed, 7 Apr 2010 14:40:33 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o37LePjj086845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 16:40:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBCFBC9.1070204@nostrum.com> Date: Wed, 07 Apr 2010 16:40:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-subnot-etags: When to include SIP-Etag in NOTIFY? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:40:34 -0000 On 4/7/10 4:31 PM, Christer Holmberg wrote: > Hi, > > >>> So, the question is: is a subnot-etags compliant notifier required >>> to insert the SIP-Etag in *every* NOT request, or only in the cases >>> explicitly described in Section 6? >>> >> >> I believe the answer is "always". >> >> I also believe I just saw an Auth 48 request come out on this draft. >> Anybody else got a bug to fix? >> > In 3265bis we are aiming at getting rid of the 202 response. The subnot draft defines another one, 204, but I guess it doesn't matter since only endpoints supporting the draft are going to send and receive it. > We're getting rid of 202 because it is vestigial, meaningless, and often implemented incorrectly. subnot-etag's use of 204 is critical for proper functioning of its mechanism. /a From HKaplan@acmepacket.com Wed Apr 7 15:20:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2965C3A6975 for ; Wed, 7 Apr 2010 15:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEXeunqJ550g for ; Wed, 7 Apr 2010 15:20:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E4DF83A67D7 for ; Wed, 7 Apr 2010 15:20:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Apr 2010 18:20:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 7 Apr 2010 18:20:40 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Wed, 7 Apr 2010 18:20:39 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWZxWBO59ihGpqQMmL+z5e6xP6FAAN7mGA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D16B@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79F3D16Bmail_" MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 22:20:55 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79F3D16Bmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Wednesday, April 07, 2010 11:29 AM To: Hadriel Kaplan Cc: Christer Holmberg; WORLEY, DALE R (DALE); Salvatore Loreto; sipcore@iet= f.org Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? Your real world scenario breaks any SIP specific feature... ;-) [hsk] Yup, and that's the real world of inter-domain routing right now. :( Still unclear what use case we are discussing here... but OPTIONS does not = necessarily need be used in combination with INVITE. [hsk] we're only discussing that because it was one example Christer descri= bed for using he OPTIONS fork/3xx need. Just speculating: It could be used by application servers to detect the cap= abilities devices a user has registered and do something with that. In thos= e scenarios maybe a presence server is to much of a burden and there is no = dark interworking nightmare that needs to be taken into account. 3xx could = well be used in this scenario to get all the capabilities of all the regist= ered devices. [hsk] That was the exact question I asked previously on this topic - whethe= r that App-server was the use-case in mind, because for that the problem is= much simpler, and putting a new options-tag in a proxy-require is not only= likely to work, but also reasonably easy to deploy. As long as you constr= ain the use-case to be within the local domain, then doing things like prox= y-require or even manual configuration and such is all reasonable, imho. I= f you're talking about using it across domains instead, between any UAC to = any UAS in the World/Internet, this thing is about as likely to fail as Tig= er Woods' marriage. /Hans Erik van Elburg --_000_430FC6BDED356B4C8498F634416644A91A79F3D16Bmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Hans Eri= k van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, April 07, 2= 010 11:29 AM
To: Hadriel Kaplan
Cc: Christer Holmberg; WORLE= Y, DALE R (DALE); Salvatore Loreto; sipcore@ietf.org
Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this?

 

Your real  w= orld scenario breaks any SIP specific feature... ;-)

= [hsk] Yup, and that’s the real world of inter-domain routing right now. <= /font>L<= /font>

Still unclear wha= t use case we are discussing here... but OPTIONS does not necessarily need be use= d in combination with INVITE.

= [hsk] we’re only discussing that because it was one example Christer described for usin= g he OPTIONS fork/3xx need.


Just speculating: It could be used by application servers to detect the capabilities devices a user has registered and do something with that. In t= hose scenarios maybe a presence server is to much of a burden and there is no da= rk interworking nightmare that needs to be taken into account. 3xx could well = be used in this scenario to get all the capabilities of all the registered devices.

= [hsk] That was the exact question I asked previously on this topic – whethe= r that App-server was the use-case in mind, because for that the problem is much simpler, and putting a new options-tag in a proxy-require is not only likel= y to work, but also reasonably easy to deploy.  As long as you constrain th= e use-case to be within the local domain, then doing things like proxy-requir= e or even manual configuration and such is all reasonable, imho.  If you= 217;re talking about using it across domains instead, between any UAC to any UAS i= n the World/Internet, this thing is about as likely to fail as Tiger Woods= 217; marriage.


/Hans Erik van Elburg

 

--_000_430FC6BDED356B4C8498F634416644A91A79F3D16Bmail_-- From dean.willis@softarmor.com Wed Apr 7 17:25:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD563A681C for ; Wed, 7 Apr 2010 17:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwCEjPShMpJX for ; Wed, 7 Apr 2010 17:25:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 16E563A67E1 for ; Wed, 7 Apr 2010 17:25:16 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o380P7O1024159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Apr 2010 19:25:08 -0500 Message-Id: <7FDD7185-24DE-43D9-BD3F-065AC3F1E6C9@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 19:25:01 -0500 References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <871B0DB3-20AC-4ADB-8639-4E237F6FB9A7@softarmor.com>, <03034827-7D27-45A1-A67B-08810986B929@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 00:25:19 -0000 On Apr 7, 2010, at 4:26 PM, Christer Holmberg wrote: > Hi, > >> Seriously, OPTIONS+forking is a bad combination. If we don't >> formally deprecate forking, at least we can recommend it not be used >> for OPTIONS requests. Or we could amend 3261 to say "proxies MUST >> NOT fork OPTIONS request messages". Or we could add an options tag, >> and say "Proxies that support this extension MUST NOT fork OPTIONS". > > Using the O-3xx (I'm getting tired of writing OPTIONS 3xx :) > mechanism the OPTIONS request isn't forked. Right. Saying proxies MUST NOT fork OPTIONS does not preclude sending a 302 response. Or a new error code saying "Can't do that, too many targets", or anything else. > >> I left out OR we require that a proxy that would ordinarily fork >> the request instead act as a B2BUA and >> return an aggregate response. > > That is of course one alternative, but the "beauty" of O-3xx is that > you don't need to standardize anything. The tools are available > (yes, I know we can't be 100% sure that it will always work), so the > question is whether we somehow want to document how we can solve the > forking problem by combining those tools. Assuming your application doesn't have to be absolutely sure that the OPTIONS isn't forking, then you're right; this could be done entirely on an informational basis. Might even be reasonable as an individual informational: "An Alternative to Forking for OPTIONS Requests to Enable the Discovery of User-Agent-Server Capabilities in the Session Initiation Protocol." Sounds like a good thesis project for a telecom student or senior project for an undergrad. Probably doesn't need to be a working-group effort. -- Dean From keith.drage@alcatel-lucent.com Wed Apr 7 18:17:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4FF3A68D1 for ; Wed, 7 Apr 2010 18:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TI9tsuCAcpV for ; Wed, 7 Apr 2010 18:17:45 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 08EE23A68F8 for ; Wed, 7 Apr 2010 18:16:24 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o381GHMb008123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Apr 2010 03:16:17 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 8 Apr 2010 03:16:17 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Adam Roach Date: Thu, 8 Apr 2010 03:16:16 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrWg3WgLJG2pyCqSJSXa6XLsmvy8wAMilGg Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> <4BBCCEEE.1050909@cisco.com> <4BBCD09E.8020403@nostrum.com> <4BBCD45F.6040405@cisco.com> In-Reply-To: <4BBCD45F.6040405@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 01:17:47 -0000 While I accept that RFC 4320 is mandatory for all current implementations c= alling themselves SIP, we do need to deal with compatibility issues with de= ployments made before it was thought of and became an RFC. Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any ot= her implementation needs to be able to receive it. Unless of course you can argue that any entity sending it in the first plac= e had to be so broken that it is otherwise inoperable.=20 regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, April 07, 2010 7:52 PM > To: Adam Roach > Cc: SIPCORE > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was=20 > Minutes Posted] >=20 > [as individual] >=20 > Sorry. Perhaps I was being imprecise. I'm used to talking=20 > about receiving a 408 as synonymous with "receiving a 408 or=20 > having the transaction time out". Some stacks will return a=20 > 408 as a result of timeout even though one was never received. >=20 > The point remains - if some transaction in the usage times=20 > out, and the presumption is that the usage is then dead, I=20 > think its expected that there will still be signaling to=20 > indicate its being torn down, isn't there? Assuming this=20 > happens to the subscriber, shouldn't it send a reSUBSCRIBE=20 > with Expires:0 to explicitly terminate it. (Just as a BYE=20 > would be sent if this happened within an INVITE usage.) >=20 > Thanks, > Paul >=20 > Adam Roach wrote: > > On 4/7/10 1:29 PM, Paul Kyzivat wrote: > >> [as individual] > >> > >> Adam Roach wrote: > >>> [as individual] > >>> > >>> Paul Kyzivat wrote: > >>>> One think I noted when checking the bis on this is that=20 > the state=20 > >>>> diagram doesn't mention 408 responses. I think it should=20 > initiate a=20 > >>>> teardown of the usage. > >>> > >>> 408 responses aren't allowed for non-invite transactions. > >> > >> Huh??? > >> > >> Of course they are. Any request can time out. > >=20 > > RFC 4320, section 4.2: "A transaction-stateful SIP element MUST NOT=20 > > send a response with Status-Code of 408 to a non-INVITE=20 > request." The=20 > > rationale for this normative update to 3261 is given in=20 > section 1.4 of=20 > > RFC 4321. > >=20 > > /a > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From adam@nostrum.com Wed Apr 7 20:36:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E233A68D1 for ; Wed, 7 Apr 2010 20:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uHjVwmOd2F4 for ; Wed, 7 Apr 2010 20:36:51 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E31AA3A682F for ; Wed, 7 Apr 2010 20:36:50 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o383agLY011844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 22:36:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBD4F4A.7000009@nostrum.com> Date: Wed, 07 Apr 2010 22:36:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> <4BBCCEEE.1050909@cisco.com> <4BBCD09E.8020403@nostrum.com> <4BBCD45F.6040405@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030803050608080403080101" Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 03:36:52 -0000 This is a multi-part message in MIME format. --------------030803050608080403080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/7/10 20:16, Apr 7, DRAGE, Keith (Keith) wrote: > While I accept that RFC 4320 is mandatory for all current implementations calling themselves SIP, we do need to deal with compatibility issues with deployments made before it was thought of and became an RFC. > > Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any other implementation needs to be able to receive it. > Be able to receive it, yes. But, as RFC 4321 explains, the local transaction timer will have already expired. The 408 will be treated as a stray response. A well-designed SIP stack will discard it before it even reaches the TU. Even a poorly-designed but 3261-compliant application will ignore a 408 for a non-INVITE, because the transaction is already gone. In other words, by the time the 408 arrives, it is thoroughly irrelevant. We don't need to talk about it in 3265bis, because something else will have gone wrong first. And that situation is already covered: If the NOTIFY request fails due to expiration of SIP Timer F (transaction timeout), the notifier SHOULD remove the subscription. /a --------------030803050608080403080101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/7/10 20:16, Apr 7, DRAGE, Keith (Keith) wrote: 
While I accept that RFC 4320 is mandatory for all current implementations calling themselves SIP, we do need to deal with compatibility issues with deployments made before it was thought of and became an RFC.

Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any other implementation needs to be able to receive it.

Be able to receive it, yes. But, as RFC 4321 explains, the local transaction timer will have already expired. The 408 will be treated as a stray response. A well-designed SIP stack will discard it before it even reaches the TU. Even a poorly-designed but 3261-compliant application will ignore a 408 for a non-INVITE, because the transaction is already gone.

In other words, by the time the 408 arrives, it is thoroughly irrelevant. We don't need to talk about it in 3265bis, because something else will have gone wrong first.

And that situation is already covered:
   If the NOTIFY request fails due to expiration of SIP Timer F
   (transaction timeout), the notifier SHOULD remove the subscription.

/a
--------------030803050608080403080101-- From naveen.shivanna@motorola.com Wed Apr 7 21:47:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F130328C0D9 for ; Wed, 7 Apr 2010 21:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2QLVUowJrgO for ; Wed, 7 Apr 2010 21:47:37 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id ADE4B3A687C for ; Wed, 7 Apr 2010 21:47:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: naveen.shivanna@motorola.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1270702048!17222545!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 28479 invoked from network); 8 Apr 2010 04:47:29 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-8.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2010 04:47:29 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o384lSg4002537 for ; Wed, 7 Apr 2010 21:47:28 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o384lSwE015122 for ; Wed, 7 Apr 2010 23:47:28 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o384lQQD015118 for ; Wed, 7 Apr 2010 23:47:27 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CAD6D6.893DDE47"; type="multipart/alternative" Date: Thu, 8 Apr 2010 12:47:04 +0800 Message-ID: <0B28F3C8F2581D419709A71814CA59D703533CC5@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: thread-topic: Need Clarification on UAS behaviour thread-index: AcrWTNWsseUH0j4iTXOnPDLNqMW6owAiaaNw From: "NAVEEN S-RHVG46" To: X-CFilter-Loop: Reflected Subject: [sipcore] Need Clarification on UAS behaviour X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 04:50:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD6D6.893DDE47 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD6D6.893DDE47" ------_=_NextPart_002_01CAD6D6.893DDE47 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In Section 14.2 UAS Behaviour, we have requirement stating as below =20 A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. =20 Above requirement is valid when we receive INVITE, before sending 2xx response... we are responding with 500 in our implementation... =20 =20 What's the UAS behaviour ? =20 If we receive INVITE, after sending final response, before getting ACK.=20 =20 =20 =20 =20 =20 Regards, Naveen =20 ------_=_NextPart_002_01CAD6D6.893DDE47 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In = Section 14.2 UAS=20 Behaviour, we have requirement stating as below
 
  =20 A UAS that receives a second INVITE before it sends the = final
  =20 response to a first INVITE with a lower CSeq sequence number on=20 the
   same dialog MUST return a 500 (Server Internal = Error)=20 response to the
   second INVITE and MUST include a = Retry-After=20 header field with a
   randomly chosen value of between 0 = and 10=20 seconds.
 
Above = requirement is=20 valid when we receive INVITE, before sending 2xx response... we are = responding=20 with 500 in our implementation...
 
 
What's = the UAS=20 behaviour ?
 
If we=20 receive INVITE, after sending final response, before getting ACK.=20
 
 
 
 
Regards,
Naveen
 
------_=_NextPart_002_01CAD6D6.893DDE47-- ------_=_NextPart_001_01CAD6D6.893DDE47 Content-Type: image/jpeg; name="Outlook.jpg" Content-Transfer-Encoding: base64 Content-ID: <725454211@07042010-3500> Content-Description: Outlook.jpg Content-Location: Outlook.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCADNAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD134d+ CPDOpeBtEvb/AESxuLue1SSWaSMMzsRySe5rov8AhXfhD/oXNN/78ij4Vf8AJOPDn/XlH/KuqoA5 X/hXfhD/AKFzTf8AvyKP+Fd+EP8AoXNN/wC/IrqqKAOV/wCFd+EP+hc03/vyKP8AhXfhD/oXNN/7 8it7VNUs9LW2a/m8oXNwlrEdpO6RzhV4HGT3PFRXWt6fatqS3FyEOnW4urrKt+7iIchunPEb9Mni gDG/4V34Q/6FzTf+/Io/4V34Q/6FzTf+/IrSn8S6VDo1lqrXLNZ3oQ2xjheR5iy7lCRqC7NtBO0D IAORwataPqtnrFobiwlZ0VzG6vG0bxuOqujgMrdDggHBB7igDD/4V34Q/wChc03/AL8ij/hXfhD/ AKFzTf8AvyK6qigDlf8AhXfhD/oXNN/78ij/AIV34Q/6FzTf+/IrqqKAOW+FTFvhn4VZiWY6Zb5J OSf3a11Ncr8KP+SZeFf+wZb/APota6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKzPFOrroHhnV9Zki MyadZzXbRK20uI0L7Qe2cYoA06K5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK P7V8X/8AQr6b/wCDg/8AxigDqqK5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK o654o8T6Jo17ql94XsfslnC88vl6sWbYoycDyRk4HrQB3FFFFABRRRQAUUUUAFFFFAHK/Cr/AJJx 4c/68o/5V1Vcr8Kv+SceHP8Aryj/AJV1VABRRRQBzXj7S7nU9KsnsYWuLiw1C2v1gVlUyiOQMygs QMld2MkDOMkVzOo6NrviDU72cafJplnqctnDKLpopHSC382UsyI5BDuyR7QxO0sTivS6KAPMbTw/ r+jaxaXJtX1O00q+uZYEt2jiM0N0m59qM+A0cu4AEj5G4PGK7rQJr64ju7jUdOXTjJOTFCWVpSgV VDSlCV3Eg9CcLtGc5rUooAKKKKACiiigDlfhR/yTLwr/ANgy3/8ARa11Vcr8KP8AkmXhX/sGW/8A 6LWuqoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACuV+LH/JLPGX/YFvf/RD11Vcr8WP+SWeMv8AsC3v/oh6 AOqooooAKKKKACiuQ8dyxWOseEdTvZo7ewtNRk8+eQ7UiD2s6KWPQDcyrk92FcXqU8Xii81rR9Nj fUtP1jVjdStayqoltYLS1RikhIH+vCLkdQr46UAex0V4rqOoWmtWukS+JLnRItVsbeayurXxDGDZ yXEbhZGjkyAkvyhsgMdkgwOpr0/wROLnwho8qwT26m1jAjnlMrgAYGXIBbOM7iASDnA6UAbdFFFA BXK/Ff8A5Jl4q/7Blx/6Lauqrlfiv/yTLxV/2DLj/wBFtQB1VFFFABRRRQAUUUUAFFFFAHnfgvV9 T0HwppelXnhLX3uLOBYZGiW3ZCRxlT5oyK2v+Etu/wDoUPEn/fu3/wDj1dVRQByv/CW3f/QoeJP+ /dv/APHqP+Etu/8AoUPEn/fu3/8Aj1dVRQByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t/ /j1dVRQByv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PVd8Canc6z4N0fUb5la6ubZ JJCq4BYjnjtW7QByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t//j1dVRQByv8Awlt3/wBC h4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PV1VFAHPfDuwudL8BeHbC/hMF3bWEEU0RIJRwgBGRkc H0roaKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigArlfix/ySzxl/2Bb3/0Q9dVXP8AxEsLnVfh/wCJtOsI jNeXel3VvBGCBvd4mVRk8DJI60AdBRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/AH7t/wD4 9QB1VFcr/wAJbd/9Ch4k/wC/dv8A/HqP+Etu/wDoUPEn/fu3/wDj1AHVEAggjIPagAAAAYA7Vyv/ AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ8Sf9+7f/AOPUAdUQGGCAR15orlf+Etu/+hQ8Sf8Afu3/ APj1H/CW3f8A0KHiT/v3b/8Ax6gDqqK5X/hLbv8A6FDxJ/37t/8A49R/wlt3/wBCh4k/792//wAe oA6quV+K/wDyTLxV/wBgy4/9FtR/wlt3/wBCh4k/792//wAerE8bavqeveD9a0my8JeIFub6zlt4 mlW3VAzqQCx87gZNAHotFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCV dVXmHw28T3Vv4C0GFfC2vzqloiiWJICj8dRmUHH1Arpf+Etu/wDoUPEn/fu3/wDj1AHVUVyv/CW3 f/QoeJP+/dv/APHqP+Etu/8AoUPEn/fu3/8Aj1AHVUVyv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6F DxJ/37t//j1AHVUVyv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PUAdVRXK/8ACW3f /QoeJP8Av3b/APx6j/hLbv8A6FDxJ/37t/8A49QB1VFcr/wlt3/0KHiT/v3b/wDx6j/hLbv/AKFD xJ/37t//AI9QB1VFcr/wlt3/ANCh4k/792//AMeo/wCEtu/+hQ8Sf9+7f/49QB1VFcr/AMJbd/8A QoeJP+/dv/8AHqP+Etu/+hQ8Sf8Afu3/APj1AHVUVyv/AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ 8Sf9+7f/AOPUAdVRXK/8Jbd/9Ch4k/792/8A8eo/4S27/wChQ8Sf9+7f/wCPUAdVRXK/8Jbd/wDQ oeJP+/dv/wDHqP8AhLbv/oUPEn/fu3/+PUAdVRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/ AH7t/wD49QB1VFeeeNPFV5J4O15B4Z8Q2pbT7gCeRYAsX7tvmJWUkAdeATXK+Jb/AFLR9O8fauLi 4m0ySP7FcRhiTbMdOtzFOnoN8hV8f3lb+E0Ae20V5hdS3NvPceFUlm3a7LDcW8m85jgkUm7AJ6Ee VI2R0M6Vn6xpVnf+GbS8ukke5Pid7PzPNdT5LavIpTg9NrEfSgD1+ivEX06xi8f+KLJrPR5rS1e1 SFNR1qW0MSm3QkIoR9wzzkkc16Ve+Jrm2u5oU8Ma/cpGxUTQpAUceq5lBx9QKAOkorlf+Etu/wDo UPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k /wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ /wB+7f8A+PUf8Jbd/wDQoeJP+/dv/wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v 3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUP En/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ/wB+7f8A+PUf8Jbd/wDQoeJP+/dv /wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/3 7t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A 8eoA6qo7mCK6t5be4jWWCVCkiMMhlIwQR6EV4J8ePi/4j8G2+hXWi6Pd6f5s0izR6rBE0c4ABAGy QsCOehHWt74QfF3WPHQhS+8D6tao/H9oQYNqffdJtwPZS5/OgDufhW7y/DDwfJIzO7aPZszMckkw Jkk11Fcr8J/+SWeDf+wLZf8AohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDlfhV/yTjw5/15R/yrqq5X4Vf8k48Of9eUf8q6qgAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKCQOpxQA2WNJY3jlRXjcFWVhkMD1BFMNvAUmQwxlZv9aCow/AX5vXg Ac9hUm4btuRuxnHfFLQAwwxmVJTGhkQFVcqMqDjIB7A4H5Cm/ZoPL8vyYtm/zNuwY37t27Hru5z6 81LRQBQutG0u7naa702ynmbGZJYFZjjjkkVfHA4oooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigCjqWj6Zqk1tLqWn2l5JasWgaeFZDEx6lcjg8dRV6iigDlfhP/yS zwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigD53vPE/xR0b4b6EvgrwpaXlkLKPF7HKbmbp1EHykH8HFQfs7eNPiDr0vih9Ztm1 a7hmhVo766+x/Zsh+FjERAz34HQda9l+FX/JOPDn/XlH/Kup2jcWwNxGCe/+eaAOW/tXxf8A9Cvp v/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A 8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xi j+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+2vFK8P4SjZh1MeqRlfwJUH9BXV UUAcr/bfif8A6FH/AMqcX+FH9t+J/wDoUf8Aypxf4V1VFAHK/wBt+J/+hR/8qcX+FH9t+J/+hR/8 qcX+FdVRQByv9t+J/wDoUf8Aypxf4Uf234n/AOhR/wDKnF/hXVUUAcr/AG34n/6FH/ypxf4Uf234 n/6FH/ypxf4V1VFAHK/234n/AOhR/wDKnF/hR/bfif8A6FH/AMqcX+FdVRQByv8Abfif/oUf/KnF /hWT4qGo6ppdhc6rp9xpklpq+nGOGO8EiTZvIAWcL12jOAeOc9QCPQKKAPFdZWX/AITu+u7Brb+2 k1NlhsxEPtzJ9j8tZBIT/wAe+SG2bcZH3s/LXQfDF7A6tENAeBrQ6NbNf+QwP+lFm5k7+aRv3Z+b pu7V6VRQB4B4M0yS10/w3qNxZaTY2M2ryb9Wt7c/bAwuZAkcr8YSQ/u93IwwGOcjf8Ha5rdxpNlN Hfpb29qdJj+yR2saxutwyJID8uRgNldpGD1yOB7BRQB4jqni3U7m3hSTVoLuWexluNQ0t7WJhYTL cQKsZG3I272XD5JK544rZk8SeI7fTH1Jb77R541BRA1shW3ENyI0kXaAx2puZgSc9sV3umeHNP02 /wDtluLlpljeGPzrmSVYkZgzKgYkKCVXp/dA6AVo39pDf2c1rcqzQyqUYK5Q49mBBB9wQRQBwXh/ xLqr6hrcentP4ssbeWFLee3e2j2ho9zZfKI/Jx8vTp1zW1/wkWv/APQlal/4G2n/AMdra0bR7XSF uPsvnPJcyedNLPM0ryNtCglmJPCqoA6DFaFAHK/8JFr/AP0JWpf+Btp/8do/4SLX/wDoStS/8DbT /wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf/wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWp f+Btp/8AHaP+El1tP9Z4H1t89PJurFsfXdcL+ma6qigDlf8AhKNX/wChE8Sf9/8ATv8A5Ko/4SjV /wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9/wDTv/kquqoo A5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKNX/wChE8Sf9/8A Tv8A5Ko/4SjV/wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9 /wDTv/kquqooA5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKtT XmXwR4kjX132L/olyT+lH/CW3f8A0KHiT/v3b/8Ax6uqooA5X/hLbv8A6FDxJ/37t/8A49Tk8V3b uq/8Ij4jXJxlkt8D6/vq6iigDlfhP/ySzwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiimTGQQuYVR5QDtV22gnsCQDge+DQBzHwq/ 5Jx4c/68o/5V1VfI2teNvjFovgPSY9D0BbLREtE8vULKEXcjJj7zHkJ+KDHrXrXwZ8R+M9T+GWh3 k2lW+qyTRyM15daqUklPmPyy+U2MdMZPAFAHr9Fcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDB wf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bw f/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB 1VFcr/avi/8A6FfTf/Bwf/jFH9r+LE5k8K2jD0h1YMf/AB6NRj8aAOqorlf7b8T/APQo/wDlTi/w o/tvxP8A9Cj/AOVOL/CgDqqK5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AAoA6qiuV/tvxP8A 9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8KAOqorlf7b8T/8AQo/+VOL/AAo/tvxP/wBCj/5U4v8ACgDq qK5X+2/E/wD0KP8A5U4v8KP7b8T/APQo/wDlTi/woA6qiuV/tvxP/wBCj/5U4v8ACj+2/E//AEKP /lTi/wAKAOpZgoyxAGQOT3PSlryvxxrlpizTxhoGn29++9NOj1K7jmtckDzJZBjA2AKBwWO8hcZY jGsYra1uIYbK9ivfE8Oo2MOnXLupuZ7EW0G91ycmJk85m/hzuz8woA9toryz4WNZnUtKOkNCXbQ0 fWvJILfbS0e0z9/N/wBfnd83Bz0FZup/2L/YniNtUe3/AOE+Fzd/ZPm/04Sea32QQA/PsK+Tjb8p Gc/xUAey0V4zo4vBfrN4oihk8Mf25exhEJKx3JuWMcs4PBTflFHRW2Mc5GzvT4h18EgeC9SI9ftt p/8AHaAOporlf+Ei1/8A6ErUv/A20/8AjtH/AAkWv/8AQlal/wCBtp/8doA6qiuV/wCEi1//AKEr Uv8AwNtP/jtH/CRa/wD9CVqX/gbaf/HaAOqorlf+Ei1//oStS/8AA20/+O0f8JFr/wD0JWpf+Btp /wDHaAOqorlf+Ei1/wD6ErUv/A20/wDjtH/CRa//ANCVqX/gbaf/AB2gDqqK5X/hItf/AOhK1L/w NtP/AI7R/wAJJricyeCNYZfSK7smb/x6dR+tAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/wlGr/wDQ ieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUAdVRXK/8A CUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/ wlGr/wDQieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUA dVRXK/8ACUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+ nf8AyVVzSdd1G+vkguvCutadEwJNxdS2bRrgdCI53bnpwp/CgCn8J/8Aklng3/sC2X/ohK6quV+E /wDySzwb/wBgWy/9EJXVUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8Kv+ SceHP+vKP+VdSqhRhQAMk8e9ct8Kv+SceHP+vKP+VdVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRgZzjn1oooAAAM4HXrRgbgcDI4zRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/wDklng3/sC2X/ohK6qv Efgh4U8Pa/4Yludd0HSdTuI49OiSW8s45nVBpNidoLAkDLMcdMk+teif8K48D/8AQm+G/wDwVwf/ ABNAHVUVyv8AwrjwP/0Jvhv/AMFcH/xNRP4A8ApcRW7+E/CyzyhmjjOm24ZwuNxA25IGRn0yKAOv orhT4T+GYskvDoHg0WcjOiT/AGK28tmXduAbbgkbHyO21vQ1of8ACuPA/wD0Jvhv/wAFcH/xNAHV UVx0/gP4f27os/hXwrEzsqKH063UszZwBleScHA9jUzfDrwMqlm8HeGgoGSTpcAAH/fNAHV0V5rb 6b8HrmXy7ez+H8sm1m2xxWbHABJOAOgAJPsK6D/hXHgf/oTfDf8A4K4P/iaAOqorlf8AhXHgf/oT fDf/AIK4P/iaP+FceB/+hN8N/wDgrg/+JoA6qiuV/wCFceB/+hN8N/8Agrg/+Jr5/wD2ptD0nwzc +Gx4b0ux0gXCXBmFhbpb+ZtMe3dsAzjJxnpk0AfVVFFFABRRRQAUUUUAeYfDbxX9m8BaFB/YOvze XaIvmRWe5G46g55FdL/wmX/UueJf/AH/AOyo+FX/ACTjw5/15R/yrqqAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL /qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyr qqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9 S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8A gD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/h Mv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8A AH/7KuqooA8/8XeM5h4T1s22i+I7ScWM5juGtNgiby2w5YNxg857VzPiDXtX0S08canLf3T6UU+x qfMbOnzf2fC8UqH+FWkkKt6MUP8AeNex3EMVxBJBcRpLDIpR43UMrqRggg9QR2qB9NsXt7qB7K2a C7/4+IzEpWb5QnzjGG+VVXnsAOgoA8+udQv4GvPDIvLr7dq00D2M5mJkjt5lJnKtnIMYinZfTdGB jiqerQSXfhq0vZNR1dLk+JXsC0Op3EQMB1V4yhCOAfkO0HGQAACMDHp7WVo1zBctbQG4gRo4ZTGN 8atjcFPUA4GQPQU06dZGAQmztjCs32gIYl2iXf5nmYx97f8ANnru560AeVRWV9N448TWFvba7qVl YvaxwhfEdzb+SGgViD+8y5JJOTk13d74q+yXk1v/AGDr83lsV8yGz3I2O6nPIq1qfhPw7qt493qe gaReXTgBprizjkdsDAyzKScDitlVCqFUAKBgADAAoA5b/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/ AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8A CZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8 S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA 5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54 l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA8I+Nnxn 1fwVBotzo+iXEaTyyJPHqtq0ayKACNhDZBHP+Fa/wm+N0Pj+RLc+F9as5idrXEMJuLVT/tSgDb+I /GvSdf8ADOieIpLN9d0u01E2jM8C3MYkVGOMnaeCeB1FakMUcESRQxpHGgwqIMBR6ACgDy39nT/k Trn/ALh3/pnsK9Vryr9nT/kTrn/uHf8ApnsK9VoAK474mJqNvptlq+hWkt3qmnTkxQxIWZxLG8OM f3Q0iOfaPPauxqrq139g0u8vAnmfZ4Xl2Zxu2qTjPbpQB49rvg6+sdP1jQdPsrqbSrHTp7mwKIW3 TSwxwhRx8z5W5Yj/AKaqe9amujV7DWbnS4U8QzaT5gliuRNduFJhUFS8StKw3ZIUOqg7sn7orX8M /ESO/cHVG0ZLcae2oST6fqJuRAqlBslXYu1jv45OdjDHFaN1490yLUrC1hjvJRPJJFKv2OcTwssY cZg8vzCCD1xjFAGT4Etbma4W51q21NtVm0iwmka5jlCeeiMH4bEYkDYOODk596m+Fs2q5vLfVE1O RUggYXV4J4xLId4b93MMo/ClgjNHyNuOc76+MdDd7QR3UsiXQgMcqWsrRfv8eUGkC7ULblwGIPzD 1FNuPF2l+VpbWl3DIdR8p4Q6yLmNpUjycKSrZkACtt5yDjaxAByHiDStQmj+KgisrpjfQQi12xE+ eRaqp2cfNg8cd6p+JYfEthrsljp76s/h9Jt7SyNdzOWaFcKHizKU3K5ODgMQDgECu7t/Gmgzuix3 r/vDGIi9vKqzB5ViVoyVAdS8iDcuQNwJIBzUzeKtIGpQWC3E0l3NNJbpHFbSv88ZQPkqpCqpkTLH C89aAJfCJ1BvC+lnWWZ9RNuhnZk2MWx1K9j6j1zWvRRQAV8y/tkf8fXhT/cuv5xV9NV8y/tkf8fX hT/cuv5xUAfTVFFFABRRRQAUUUUAcr8Kv+SceHP+vKP+VdVXK/Cr/knHhz/ryj/lXVUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5V+zp/wAidc/9w7/0z2Fe q15B8IrLxTpHgvT7jSdN0S+stTstPvEe51SW2kTGn2sJUqtvIOsJOd3Q9K7X7d44/wChe8N/+D6f /wCQ6AOqqrqtp9v0y8sy/li4heLfjO3cpGcfjXP/AG7xx/0L3hv/AMH0/wD8h0fbvHH/AEL3hv8A 8H0//wAh0AY1x8OZtVtI7fxBrEd2lvYvY2/2ayEG1W2cvln342L8vA65B4xb8OeALfRdZt9SiksY pYndmisrBbeNg0ewD7zNkcnJZuvGBV77d44/6F7w3/4Pp/8A5Do+3eOP+he8N/8Ag+n/APkOgDCt vhm0H9mo2rrPFZNZPGZ7Xe8Zt2RgIzvxGrFOQBn5jzjitUeArRbm8mjupB59/b3iqyAiJIpzOYh7 NI8rZ7bwMfKKsfbvHH/QveG//B9P/wDIdH27xx/0L3hv/wAH0/8A8h0AZTfD64ey0+3l1oMNJhjh 0xvsgzEI5oZVMvzfvD/o8anGzjd3ORraB4UfTNaGp3F+Li4P2suFh8tS1w8DHA3HAUwYA54bk8ZK fbvHH/QveG//AAfT/wDyHR9u8cf9C94b/wDB9P8A/IdAHVUVyv27xx/0L3hv/wAH0/8A8h0fbvHH /QveG/8AwfT/APyHQB1VfMv7ZH/H14U/3Lr+cVe4fbvHH/QveG//AAfT/wDyHXm3xf8Ahx4y+JUu lvND4e0r7AsgAXUZrjzN+3/p3TGNvvnPagD3OiiigAooooAKKKKAOV+FX/JOPDn/AF5R/wAq6quV +FX/ACTjw5/15R/yrqqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKRmCqWYgKOpPagBaKbJIkSF5HVEHVmOAKdQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/+SWeDf+wLZf8AohK6quV+E/8AySzwb/2BbL/0 QldVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABQenHWiigD5g1LxX8XtH+H2ip4S8 M2/9lLZx7L+1H22cjb18vjb+KMPeum/Z68U+OdY8EXVzf2K6xc/2hKjz32oGCRCFT5NnlNgD2x1P Fen/AAq/5Jx4c/68o/5V1QABJAAzyfegDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK 6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/t Xxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7 V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCv pv8A4OD/APGK6qigDlf7Z8VJxJ4TgY+sOqow/wDHkU5/Cj+2/E//AEKP/lTi/wAK6qigDlf7b8T/ APQo/wDlTi/wo/tvxP8A9Cj/AOVOL/CuqooA5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AArq qKAOV/tvxP8A9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8K6qigDlf7b8T/8AQo/+VOL/AAo/tvxP/wBC j/5U4v8ACuqooA5X+2/E/wD0KP8A5U4v8K53xbNrHilrXwzqHh4QQ3RN1cxHUEIlt48ZXcqnafMa HtyA3oa9MooA8e0+/t9S1HSJPiIlibSzspbCX7eqtbrqEcgWRiWG0F0CshPZmx1IqrKtxJf6gfC1 ncx+HI9Ms3ubXLx3U1qLq8+SAdVVk3soyDtCqu3dlfa6KAOSt9buLe1to/DXhee+0UQxm0uLS4to 4njKAjarOCAM45A6U/8A4SLX/wDoStS/8DbT/wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf /wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWpf+Btp/8AHaP+Ei1//oStS/8AA20/+O11VFAHK/8A CRa//wBCVqX/AIG2n/x2j/hItf8A+hK1L/wNtP8A47XVUUAcr/wkWv8A/Qlal/4G2n/x2j/hItf/ AOhK1L/wNtP/AI7XVUUAcr/wkWv/APQlal/4G2n/AMdo/wCEi1//AKErUv8AwNtP/jtdVRQByv8A wkmuJzJ4I1hl9IruyZv/AB6dR+tH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf /JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8A JVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/ AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6 d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVTWXiLU7i8hhm8G6/aRuwVp5prEpGP7zBLlmwPYE+1 dJRQByvwn/5JZ4N/7Atl/wCiErqq5X4T/wDJLPBv/YFsv/RCV1VABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCVdVXMfC9PL+Hnh5c5xZR8/hXT0AFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWf4h1H+x9A1PU/K877Fay3 Pl7tu/YhbbnBxnGM4NAGL8J/+SWeDf8AsC2X/ohK6quW+FI2/C7wevXGjWY/8gJXU0AFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAf/9k= ------_=_NextPart_001_01CAD6D6.893DDE47-- From ranjit@motorola.com Wed Apr 7 22:31:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91B73A6992 for ; Wed, 7 Apr 2010 22:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.138 X-Spam-Level: X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3OypJ3WAETn for ; Wed, 7 Apr 2010 22:31:07 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 4EBB73A687C for ; Wed, 7 Apr 2010 22:31:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-15.tower-55.messagelabs.com!1270704662!98258914!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25378 invoked from network); 8 Apr 2010 05:31:02 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2010 05:31:02 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o385V2MM028586 for ; Wed, 7 Apr 2010 22:31:02 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o385V18h012668 for ; Thu, 8 Apr 2010 00:31:01 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o385UxH9012665 for ; Thu, 8 Apr 2010 00:31:00 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAD6DC.9EF8C280" Date: Thu, 8 Apr 2010 13:30:37 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A44CB55@ZMY16EXM66.ds.mot.com> In-Reply-To: <0B28F3C8F2581D419709A71814CA59D703533CC5@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Need Clarification on UAS behaviour thread-index: AcrWTNWsseUH0j4iTXOnPDLNqMW6owAiaaNwAAF8cTA= References: <0B28F3C8F2581D419709A71814CA59D703533CC5@ZMY16EXM67.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "NAVEEN S-RHVG46" , X-CFilter-Loop: Reflected Subject: Re: [sipcore] Need Clarification on UAS behaviour X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 05:31:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD6DC.9EF8C280 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD6DC.9EF8C280" ------_=_NextPart_002_01CAD6DC.9EF8C280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Naveen =20 The UAS should send 500 response to the INVITE - because the earlier INVITE transaction is not yet complete. . =20 Also I feel this question is more appropriate in sip-implementors list rather than sipcore Regards=20 Ranjit=20 =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of NAVEEN S-RHVG46 Sent: Thursday, April 08, 2010 10:17 AM To: sipcore@ietf.org Subject: [sipcore] Need Clarification on UAS behaviour Hi, =20 In Section 14.2 UAS Behaviour, we have requirement stating as below =20 A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. =20 Above requirement is valid when we receive INVITE, before sending 2xx response... we are responding with 500 in our implementation... =20 =20 What's the UAS behaviour ? =20 If we receive INVITE, after sending final response, before getting ACK.=20 =20 =20 =20 =20 =20 Regards, Naveen =20 ------_=_NextPart_002_01CAD6DC.9EF8C280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Naveen
 
The UAS should send 500 response to the INVITE = - because=20 the earlier INVITE transaction is not yet complete. = .
 
Also I feel this = question is more=20 appropriate in sip-implementors list rather than = sipcore

Regards =
Ranjit

 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of NAVEEN=20 S-RHVG46
Sent: Thursday, April 08, 2010 10:17 AM
To: = sipcore@ietf.org
Subject: [sipcore] Need Clarification on UAS=20 behaviour

Hi,
 
In = Section 14.2 UAS=20 Behaviour, we have requirement stating as below
 
  =20 A UAS that receives a second INVITE before it sends the = final
  =20 response to a first INVITE with a lower CSeq sequence number on=20 the
   same dialog MUST return a 500 (Server Internal = Error)=20 response to the
   second INVITE and MUST include a = Retry-After=20 header field with a
   randomly chosen value of between 0 = and 10=20 seconds.
 
Above = requirement is=20 valid when we receive INVITE, before sending 2xx response... we are = responding=20 with 500 in our implementation...
 
 
What's = the UAS=20 behaviour ?
 
If we=20 receive INVITE, after sending final response, before getting ACK.=20
 
 
 
 
Regards,
Naveen
 
------_=_NextPart_002_01CAD6DC.9EF8C280-- ------_=_NextPart_001_01CAD6DC.9EF8C280 Content-Type: image/jpeg; name="Outlook.jpg" Content-Transfer-Encoding: base64 Content-ID: <017162905@08042010-1536> Content-Description: Outlook.jpg Content-Location: Outlook.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCADNAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD134d+ CPDOpeBtEvb/AESxuLue1SSWaSMMzsRySe5rov8AhXfhD/oXNN/78ij4Vf8AJOPDn/XlH/KuqoA5 X/hXfhD/AKFzTf8AvyKP+Fd+EP8AoXNN/wC/IrqqKAOV/wCFd+EP+hc03/vyKP8AhXfhD/oXNN/7 8it7VNUs9LW2a/m8oXNwlrEdpO6RzhV4HGT3PFRXWt6fatqS3FyEOnW4urrKt+7iIchunPEb9Mni gDG/4V34Q/6FzTf+/Io/4V34Q/6FzTf+/IrSn8S6VDo1lqrXLNZ3oQ2xjheR5iy7lCRqC7NtBO0D IAORwataPqtnrFobiwlZ0VzG6vG0bxuOqujgMrdDggHBB7igDD/4V34Q/wChc03/AL8ij/hXfhD/ AKFzTf8AvyK6qigDlf8AhXfhD/oXNN/78ij/AIV34Q/6FzTf+/IrqqKAOW+FTFvhn4VZiWY6Zb5J OSf3a11Ncr8KP+SZeFf+wZb/APota6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKzPFOrroHhnV9Zki MyadZzXbRK20uI0L7Qe2cYoA06K5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK P7V8X/8AQr6b/wCDg/8AxigDqqK5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK o654o8T6Jo17ql94XsfslnC88vl6sWbYoycDyRk4HrQB3FFFFABRRRQAUUUUAFFFFAHK/Cr/AJJx 4c/68o/5V1Vcr8Kv+SceHP8Aryj/AJV1VABRRRQBzXj7S7nU9KsnsYWuLiw1C2v1gVlUyiOQMygs QMld2MkDOMkVzOo6NrviDU72cafJplnqctnDKLpopHSC382UsyI5BDuyR7QxO0sTivS6KAPMbTw/ r+jaxaXJtX1O00q+uZYEt2jiM0N0m59qM+A0cu4AEj5G4PGK7rQJr64ju7jUdOXTjJOTFCWVpSgV VDSlCV3Eg9CcLtGc5rUooAKKKKACiiigDlfhR/yTLwr/ANgy3/8ARa11Vcr8KP8AkmXhX/sGW/8A 6LWuqoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACuV+LH/JLPGX/YFvf/RD11Vcr8WP+SWeMv8AsC3v/oh6 AOqooooAKKKKACiuQ8dyxWOseEdTvZo7ewtNRk8+eQ7UiD2s6KWPQDcyrk92FcXqU8Xii81rR9Nj fUtP1jVjdStayqoltYLS1RikhIH+vCLkdQr46UAex0V4rqOoWmtWukS+JLnRItVsbeayurXxDGDZ yXEbhZGjkyAkvyhsgMdkgwOpr0/wROLnwho8qwT26m1jAjnlMrgAYGXIBbOM7iASDnA6UAbdFFFA BXK/Ff8A5Jl4q/7Blx/6Lauqrlfiv/yTLxV/2DLj/wBFtQB1VFFFABRRRQAUUUUAFFFFAHnfgvV9 T0HwppelXnhLX3uLOBYZGiW3ZCRxlT5oyK2v+Etu/wDoUPEn/fu3/wDj1dVRQByv/CW3f/QoeJP+ /dv/APHqP+Etu/8AoUPEn/fu3/8Aj1dVRQByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t/ /j1dVRQByv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PVd8Canc6z4N0fUb5la6ubZ JJCq4BYjnjtW7QByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t//j1dVRQByv8Awlt3/wBC h4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PV1VFAHPfDuwudL8BeHbC/hMF3bWEEU0RIJRwgBGRkc H0roaKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigArlfix/ySzxl/2Bb3/0Q9dVXP8AxEsLnVfh/wCJtOsI jNeXel3VvBGCBvd4mVRk8DJI60AdBRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/AH7t/wD4 9QB1VFcr/wAJbd/9Ch4k/wC/dv8A/HqP+Etu/wDoUPEn/fu3/wDj1AHVEAggjIPagAAAAYA7Vyv/ AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ8Sf9+7f/AOPUAdUQGGCAR15orlf+Etu/+hQ8Sf8Afu3/ APj1H/CW3f8A0KHiT/v3b/8Ax6gDqqK5X/hLbv8A6FDxJ/37t/8A49R/wlt3/wBCh4k/792//wAe oA6quV+K/wDyTLxV/wBgy4/9FtR/wlt3/wBCh4k/792//wAerE8bavqeveD9a0my8JeIFub6zlt4 mlW3VAzqQCx87gZNAHotFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCV dVXmHw28T3Vv4C0GFfC2vzqloiiWJICj8dRmUHH1Arpf+Etu/wDoUPEn/fu3/wDj1AHVUVyv/CW3 f/QoeJP+/dv/APHqP+Etu/8AoUPEn/fu3/8Aj1AHVUVyv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6F DxJ/37t//j1AHVUVyv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PUAdVRXK/8ACW3f /QoeJP8Av3b/APx6j/hLbv8A6FDxJ/37t/8A49QB1VFcr/wlt3/0KHiT/v3b/wDx6j/hLbv/AKFD xJ/37t//AI9QB1VFcr/wlt3/ANCh4k/792//AMeo/wCEtu/+hQ8Sf9+7f/49QB1VFcr/AMJbd/8A QoeJP+/dv/8AHqP+Etu/+hQ8Sf8Afu3/APj1AHVUVyv/AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ 8Sf9+7f/AOPUAdVRXK/8Jbd/9Ch4k/792/8A8eo/4S27/wChQ8Sf9+7f/wCPUAdVRXK/8Jbd/wDQ oeJP+/dv/wDHqP8AhLbv/oUPEn/fu3/+PUAdVRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/ AH7t/wD49QB1VFeeeNPFV5J4O15B4Z8Q2pbT7gCeRYAsX7tvmJWUkAdeATXK+Jb/AFLR9O8fauLi 4m0ySP7FcRhiTbMdOtzFOnoN8hV8f3lb+E0Ae20V5hdS3NvPceFUlm3a7LDcW8m85jgkUm7AJ6Ee VI2R0M6Vn6xpVnf+GbS8ukke5Pid7PzPNdT5LavIpTg9NrEfSgD1+ivEX06xi8f+KLJrPR5rS1e1 SFNR1qW0MSm3QkIoR9wzzkkc16Ve+Jrm2u5oU8Ma/cpGxUTQpAUceq5lBx9QKAOkorlf+Etu/wDo UPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k /wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ /wB+7f8A+PUf8Jbd/wDQoeJP+/dv/wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v 3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUP En/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ/wB+7f8A+PUf8Jbd/wDQoeJP+/dv /wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/3 7t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A 8eoA6qo7mCK6t5be4jWWCVCkiMMhlIwQR6EV4J8ePi/4j8G2+hXWi6Pd6f5s0izR6rBE0c4ABAGy QsCOehHWt74QfF3WPHQhS+8D6tao/H9oQYNqffdJtwPZS5/OgDufhW7y/DDwfJIzO7aPZszMckkw Jkk11Fcr8J/+SWeDf+wLZf8AohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDlfhV/yTjw5/15R/yrqq5X4Vf8k48Of9eUf8q6qgAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKCQOpxQA2WNJY3jlRXjcFWVhkMD1BFMNvAUmQwxlZv9aCow/AX5vXg Ac9hUm4btuRuxnHfFLQAwwxmVJTGhkQFVcqMqDjIB7A4H5Cm/ZoPL8vyYtm/zNuwY37t27Hru5z6 81LRQBQutG0u7naa702ynmbGZJYFZjjjkkVfHA4oooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigCjqWj6Zqk1tLqWn2l5JasWgaeFZDEx6lcjg8dRV6iigDlfhP/yS zwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigD53vPE/xR0b4b6EvgrwpaXlkLKPF7HKbmbp1EHykH8HFQfs7eNPiDr0vih9Ztm1 a7hmhVo766+x/Zsh+FjERAz34HQda9l+FX/JOPDn/XlH/Kup2jcWwNxGCe/+eaAOW/tXxf8A9Cvp v/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A 8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xi j+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+2vFK8P4SjZh1MeqRlfwJUH9BXV UUAcr/bfif8A6FH/AMqcX+FH9t+J/wDoUf8Aypxf4V1VFAHK/wBt+J/+hR/8qcX+FH9t+J/+hR/8 qcX+FdVRQByv9t+J/wDoUf8Aypxf4Uf234n/AOhR/wDKnF/hXVUUAcr/AG34n/6FH/ypxf4Uf234 n/6FH/ypxf4V1VFAHK/234n/AOhR/wDKnF/hR/bfif8A6FH/AMqcX+FdVRQByv8Abfif/oUf/KnF /hWT4qGo6ppdhc6rp9xpklpq+nGOGO8EiTZvIAWcL12jOAeOc9QCPQKKAPFdZWX/AITu+u7Brb+2 k1NlhsxEPtzJ9j8tZBIT/wAe+SG2bcZH3s/LXQfDF7A6tENAeBrQ6NbNf+QwP+lFm5k7+aRv3Z+b pu7V6VRQB4B4M0yS10/w3qNxZaTY2M2ryb9Wt7c/bAwuZAkcr8YSQ/u93IwwGOcjf8Ha5rdxpNlN Hfpb29qdJj+yR2saxutwyJID8uRgNldpGD1yOB7BRQB4jqni3U7m3hSTVoLuWexluNQ0t7WJhYTL cQKsZG3I272XD5JK544rZk8SeI7fTH1Jb77R541BRA1shW3ENyI0kXaAx2puZgSc9sV3umeHNP02 /wDtluLlpljeGPzrmSVYkZgzKgYkKCVXp/dA6AVo39pDf2c1rcqzQyqUYK5Q49mBBB9wQRQBwXh/ xLqr6hrcentP4ssbeWFLee3e2j2ho9zZfKI/Jx8vTp1zW1/wkWv/APQlal/4G2n/AMdra0bR7XSF uPsvnPJcyedNLPM0ryNtCglmJPCqoA6DFaFAHK/8JFr/AP0JWpf+Btp/8do/4SLX/wDoStS/8DbT /wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf/wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWp f+Btp/8AHaP+El1tP9Z4H1t89PJurFsfXdcL+ma6qigDlf8AhKNX/wChE8Sf9/8ATv8A5Ko/4SjV /wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9/wDTv/kquqoo A5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKNX/wChE8Sf9/8A Tv8A5Ko/4SjV/wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9 /wDTv/kquqooA5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKtT XmXwR4kjX132L/olyT+lH/CW3f8A0KHiT/v3b/8Ax6uqooA5X/hLbv8A6FDxJ/37t/8A49Tk8V3b uq/8Ij4jXJxlkt8D6/vq6iigDlfhP/ySzwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiimTGQQuYVR5QDtV22gnsCQDge+DQBzHwq/ 5Jx4c/68o/5V1VfI2teNvjFovgPSY9D0BbLREtE8vULKEXcjJj7zHkJ+KDHrXrXwZ8R+M9T+GWh3 k2lW+qyTRyM15daqUklPmPyy+U2MdMZPAFAHr9Fcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDB wf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bw f/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB 1VFcr/avi/8A6FfTf/Bwf/jFH9r+LE5k8K2jD0h1YMf/AB6NRj8aAOqorlf7b8T/APQo/wDlTi/w o/tvxP8A9Cj/AOVOL/CgDqqK5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AAoA6qiuV/tvxP8A 9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8KAOqorlf7b8T/8AQo/+VOL/AAo/tvxP/wBCj/5U4v8ACgDq qK5X+2/E/wD0KP8A5U4v8KP7b8T/APQo/wDlTi/woA6qiuV/tvxP/wBCj/5U4v8ACj+2/E//AEKP /lTi/wAKAOpZgoyxAGQOT3PSlryvxxrlpizTxhoGn29++9NOj1K7jmtckDzJZBjA2AKBwWO8hcZY jGsYra1uIYbK9ivfE8Oo2MOnXLupuZ7EW0G91ycmJk85m/hzuz8woA9toryz4WNZnUtKOkNCXbQ0 fWvJILfbS0e0z9/N/wBfnd83Bz0FZup/2L/YniNtUe3/AOE+Fzd/ZPm/04Sea32QQA/PsK+Tjb8p Gc/xUAey0V4zo4vBfrN4oihk8Mf25exhEJKx3JuWMcs4PBTflFHRW2Mc5GzvT4h18EgeC9SI9ftt p/8AHaAOporlf+Ei1/8A6ErUv/A20/8AjtH/AAkWv/8AQlal/wCBtp/8doA6qiuV/wCEi1//AKEr Uv8AwNtP/jtH/CRa/wD9CVqX/gbaf/HaAOqorlf+Ei1//oStS/8AA20/+O0f8JFr/wD0JWpf+Btp /wDHaAOqorlf+Ei1/wD6ErUv/A20/wDjtH/CRa//ANCVqX/gbaf/AB2gDqqK5X/hItf/AOhK1L/w NtP/AI7R/wAJJricyeCNYZfSK7smb/x6dR+tAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/wlGr/wDQ ieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUAdVRXK/8A CUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/ wlGr/wDQieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUA dVRXK/8ACUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+ nf8AyVVzSdd1G+vkguvCutadEwJNxdS2bRrgdCI53bnpwp/CgCn8J/8Aklng3/sC2X/ohK6quV+E /wDySzwb/wBgWy/9EJXVUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8Kv+ SceHP+vKP+VdSqhRhQAMk8e9ct8Kv+SceHP+vKP+VdVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRgZzjn1oooAAAM4HXrRgbgcDI4zRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/wDklng3/sC2X/ohK6qv Efgh4U8Pa/4Yludd0HSdTuI49OiSW8s45nVBpNidoLAkDLMcdMk+teif8K48D/8AQm+G/wDwVwf/ ABNAHVUVyv8AwrjwP/0Jvhv/AMFcH/xNRP4A8ApcRW7+E/CyzyhmjjOm24ZwuNxA25IGRn0yKAOv orhT4T+GYskvDoHg0WcjOiT/AGK28tmXduAbbgkbHyO21vQ1of8ACuPA/wD0Jvhv/wAFcH/xNAHV UVx0/gP4f27os/hXwrEzsqKH063UszZwBleScHA9jUzfDrwMqlm8HeGgoGSTpcAAH/fNAHV0V5rb 6b8HrmXy7ez+H8sm1m2xxWbHABJOAOgAJPsK6D/hXHgf/oTfDf8A4K4P/iaAOqorlf8AhXHgf/oT fDf/AIK4P/iaP+FceB/+hN8N/wDgrg/+JoA6qiuV/wCFceB/+hN8N/8Agrg/+Jr5/wD2ptD0nwzc +Gx4b0ux0gXCXBmFhbpb+ZtMe3dsAzjJxnpk0AfVVFFFABRRRQAUUUUAeYfDbxX9m8BaFB/YOvze XaIvmRWe5G46g55FdL/wmX/UueJf/AH/AOyo+FX/ACTjw5/15R/yrqqAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL /qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyr qqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9 S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8A gD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/h Mv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8A AH/7KuqooA8/8XeM5h4T1s22i+I7ScWM5juGtNgiby2w5YNxg857VzPiDXtX0S08canLf3T6UU+x qfMbOnzf2fC8UqH+FWkkKt6MUP8AeNex3EMVxBJBcRpLDIpR43UMrqRggg9QR2qB9NsXt7qB7K2a C7/4+IzEpWb5QnzjGG+VVXnsAOgoA8+udQv4GvPDIvLr7dq00D2M5mJkjt5lJnKtnIMYinZfTdGB jiqerQSXfhq0vZNR1dLk+JXsC0Op3EQMB1V4yhCOAfkO0HGQAACMDHp7WVo1zBctbQG4gRo4ZTGN 8atjcFPUA4GQPQU06dZGAQmztjCs32gIYl2iXf5nmYx97f8ANnru560AeVRWV9N448TWFvba7qVl YvaxwhfEdzb+SGgViD+8y5JJOTk13d74q+yXk1v/AGDr83lsV8yGz3I2O6nPIq1qfhPw7qt493qe gaReXTgBprizjkdsDAyzKScDitlVCqFUAKBgADAAoA5b/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/ AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8A CZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8 S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA 5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54 l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA8I+Nnxn 1fwVBotzo+iXEaTyyJPHqtq0ayKACNhDZBHP+Fa/wm+N0Pj+RLc+F9as5idrXEMJuLVT/tSgDb+I /GvSdf8ADOieIpLN9d0u01E2jM8C3MYkVGOMnaeCeB1FakMUcESRQxpHGgwqIMBR6ACgDy39nT/k Trn/ALh3/pnsK9Vryr9nT/kTrn/uHf8ApnsK9VoAK474mJqNvptlq+hWkt3qmnTkxQxIWZxLG8OM f3Q0iOfaPPauxqrq139g0u8vAnmfZ4Xl2Zxu2qTjPbpQB49rvg6+sdP1jQdPsrqbSrHTp7mwKIW3 TSwxwhRx8z5W5Yj/AKaqe9amujV7DWbnS4U8QzaT5gliuRNduFJhUFS8StKw3ZIUOqg7sn7orX8M /ESO/cHVG0ZLcae2oST6fqJuRAqlBslXYu1jv45OdjDHFaN1490yLUrC1hjvJRPJJFKv2OcTwssY cZg8vzCCD1xjFAGT4Etbma4W51q21NtVm0iwmka5jlCeeiMH4bEYkDYOODk596m+Fs2q5vLfVE1O RUggYXV4J4xLId4b93MMo/ClgjNHyNuOc76+MdDd7QR3UsiXQgMcqWsrRfv8eUGkC7ULblwGIPzD 1FNuPF2l+VpbWl3DIdR8p4Q6yLmNpUjycKSrZkACtt5yDjaxAByHiDStQmj+KgisrpjfQQi12xE+ eRaqp2cfNg8cd6p+JYfEthrsljp76s/h9Jt7SyNdzOWaFcKHizKU3K5ODgMQDgECu7t/Gmgzuix3 r/vDGIi9vKqzB5ViVoyVAdS8iDcuQNwJIBzUzeKtIGpQWC3E0l3NNJbpHFbSv88ZQPkqpCqpkTLH C89aAJfCJ1BvC+lnWWZ9RNuhnZk2MWx1K9j6j1zWvRRQAV8y/tkf8fXhT/cuv5xV9NV8y/tkf8fX hT/cuv5xUAfTVFFFABRRRQAUUUUAcr8Kv+SceHP+vKP+VdVXK/Cr/knHhz/ryj/lXVUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5V+zp/wAidc/9w7/0z2Fe q15B8IrLxTpHgvT7jSdN0S+stTstPvEe51SW2kTGn2sJUqtvIOsJOd3Q9K7X7d44/wChe8N/+D6f /wCQ6AOqqrqtp9v0y8sy/li4heLfjO3cpGcfjXP/AG7xx/0L3hv/AMH0/wD8h0fbvHH/AEL3hv8A 8H0//wAh0AY1x8OZtVtI7fxBrEd2lvYvY2/2ayEG1W2cvln342L8vA65B4xb8OeALfRdZt9SiksY pYndmisrBbeNg0ewD7zNkcnJZuvGBV77d44/6F7w3/4Pp/8A5Do+3eOP+he8N/8Ag+n/APkOgDCt vhm0H9mo2rrPFZNZPGZ7Xe8Zt2RgIzvxGrFOQBn5jzjitUeArRbm8mjupB59/b3iqyAiJIpzOYh7 NI8rZ7bwMfKKsfbvHH/QveG//B9P/wDIdH27xx/0L3hv/wAH0/8A8h0AZTfD64ey0+3l1oMNJhjh 0xvsgzEI5oZVMvzfvD/o8anGzjd3ORraB4UfTNaGp3F+Li4P2suFh8tS1w8DHA3HAUwYA54bk8ZK fbvHH/QveG//AAfT/wDyHR9u8cf9C94b/wDB9P8A/IdAHVUVyv27xx/0L3hv/wAH0/8A8h0fbvHH /QveG/8AwfT/APyHQB1VfMv7ZH/H14U/3Lr+cVe4fbvHH/QveG//AAfT/wDyHXm3xf8Ahx4y+JUu lvND4e0r7AsgAXUZrjzN+3/p3TGNvvnPagD3OiiigAooooAKKKKAOV+FX/JOPDn/AF5R/wAq6quV +FX/ACTjw5/15R/yrqqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKRmCqWYgKOpPagBaKbJIkSF5HVEHVmOAKdQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/+SWeDf+wLZf8AohK6quV+E/8AySzwb/2BbL/0 QldVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABQenHWiigD5g1LxX8XtH+H2ip4S8 M2/9lLZx7L+1H22cjb18vjb+KMPeum/Z68U+OdY8EXVzf2K6xc/2hKjz32oGCRCFT5NnlNgD2x1P Fen/AAq/5Jx4c/68o/5V1QABJAAzyfegDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK 6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/t Xxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7 V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCv pv8A4OD/APGK6qigDlf7Z8VJxJ4TgY+sOqow/wDHkU5/Cj+2/E//AEKP/lTi/wAK6qigDlf7b8T/ APQo/wDlTi/wo/tvxP8A9Cj/AOVOL/CuqooA5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AArq qKAOV/tvxP8A9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8K6qigDlf7b8T/8AQo/+VOL/AAo/tvxP/wBC j/5U4v8ACuqooA5X+2/E/wD0KP8A5U4v8K53xbNrHilrXwzqHh4QQ3RN1cxHUEIlt48ZXcqnafMa HtyA3oa9MooA8e0+/t9S1HSJPiIlibSzspbCX7eqtbrqEcgWRiWG0F0CshPZmx1IqrKtxJf6gfC1 ncx+HI9Ms3ubXLx3U1qLq8+SAdVVk3soyDtCqu3dlfa6KAOSt9buLe1to/DXhee+0UQxm0uLS4to 4njKAjarOCAM45A6U/8A4SLX/wDoStS/8DbT/wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf /wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWpf+Btp/8AHaP+Ei1//oStS/8AA20/+O11VFAHK/8A CRa//wBCVqX/AIG2n/x2j/hItf8A+hK1L/wNtP8A47XVUUAcr/wkWv8A/Qlal/4G2n/x2j/hItf/ AOhK1L/wNtP/AI7XVUUAcr/wkWv/APQlal/4G2n/AMdo/wCEi1//AKErUv8AwNtP/jtdVRQByv8A wkmuJzJ4I1hl9IruyZv/AB6dR+tH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf /JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8A JVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/ AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6 d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVTWXiLU7i8hhm8G6/aRuwVp5prEpGP7zBLlmwPYE+1 dJRQByvwn/5JZ4N/7Atl/wCiErqq5X4T/wDJLPBv/YFsv/RCV1VABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCVdVXMfC9PL+Hnh5c5xZR8/hXT0AFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWf4h1H+x9A1PU/K877Fay3 Pl7tu/YhbbnBxnGM4NAGL8J/+SWeDf8AsC2X/ohK6quW+FI2/C7wevXGjWY/8gJXU0AFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAf/9k= ------_=_NextPart_001_01CAD6DC.9EF8C280-- From christer.holmberg@ericsson.com Wed Apr 7 23:46:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98BE3A68F8 for ; Wed, 7 Apr 2010 23:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.288 X-Spam-Level: X-Spam-Status: No, score=-5.288 tagged_above=-999 required=5 tests=[AWL=1.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOSVCdhQP3Nm for ; Wed, 7 Apr 2010 23:46:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 44A9E3A691B for ; Wed, 7 Apr 2010 23:46:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-f8-4bbd7bbd7e84 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4D.FC.23532.DBB7DBB4; Thu, 8 Apr 2010 08:46:21 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 8 Apr 2010 08:46:21 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Thu, 8 Apr 2010 08:46:20 +0200 Thread-Topic: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] Thread-Index: AcrV4iet/Jl04c79TTyKI1KBY3+fSQAN9L+QADL0YJA= Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:46:27 -0000 Hi, In the case of DE-subscriptions (which is just one variant of re-subscripti= on), I still think there are some issues regarding whether the SUB 200 or t= he NOT req acknowledges the SUB req. Assuming the sub dialog is terminated when an entity receives a SUB 200 tha= t contains 'Expires: 0'. Now, if there is then a NOT request (that contains 'Subscription-State: ter= minated'), won't it be treated as an out-of-dialog request, and rejected? (Again, IF one is supposed to wait for the NOT req before terminating the d= ialog we again have a problem with the subnot draft.) Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 7. huhtikuuta 2010 9:21 > To: Adam Roach; Brett Tate > Cc: SIPCORE > Subject: [sipcore] Rfc3265bis: NOTIFY request or response=20 > confirms (re-)subscription? [was rfc3265bis: SIP events redux=20 > [was Minutes Posted]] >=20 >=20 > Hi, >=20 > I haven't double checked whether it is said in 3265bis, but=20 > we also need to make clear whether it is the NOTIFY request,=20 > or the NOT 200 response, that "acknowledges" the (re-)subscription. >=20 > Because, a NOTIFY request can also be rejected (e.g. due to=20 > overload), so in order to avoid sub state unsynch every=20 > entity in the path needs to know what a NOT non-200 response means. >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 7. huhtikuuta 2010 2:37 > > To: Brett Tate > > Cc: SIPCORE > > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes=20 > > Posted] > >=20 > > On 4/6/10 17:46, Apr 6, Brett Tate wrote: > > >> Is there *any* problem here? This seems to be working > > about as well > > >> as anyone might hope. > > >> =20 > > > It works okay excluding the non backward compatibility with > > RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)... > >=20 > > I don't think it's accurate to characterize the change as=20 > > non-backwards-compatible. The only wire-visible behavior that one=20 > > could conceivable observe is that a subscriber might make a=20 > different=20 > > decision about which subscription to accept if the=20 > SUBSCRIBE forks and=20 > > the subscriber wants only one subscription. > >=20 > > What we *do* gain is a simplification for implementors.=20 > > Because the behavior of establishing the dialog when a=20 > NOTIFY shows up=20 > > (instead of "the first of a 2xx or a NOTIFY) is much easier=20 > to code,=20 > > people will make fewer mistakes, and have fewer bugs. But you'd be=20 > > hard pressed to see a difference on the wire. > >=20 > > > The draft's Timer N (and lack of related NOTIFY) text is > > potentially > > > worded in a way which does not require the tear down (and non > > > creation) of subscription. > >=20 > > Tear-down of existing dialogs is still an open issue, sure. I don't=20 > > get where you see any wiggle room in what happens if Timer=20 > N fires for=20 > > the first SUBSCRIBE/NOTIFY exchange. > >=20 > > /a > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Wed Apr 7 23:48:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE9A3A67FF for ; Wed, 7 Apr 2010 23:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVF0Pe5Jvx7m for ; Wed, 7 Apr 2010 23:48:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 854793A68F8 for ; Wed, 7 Apr 2010 23:48:14 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-fa-4bbd7c29b5cc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 93.3B.23740.92C7DBB4; Thu, 8 Apr 2010 08:48:09 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 8 Apr 2010 08:48:09 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Thu, 8 Apr 2010 08:48:09 +0200 Thread-Topic: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] Thread-Index: AcrV4iet/Jl04c79TTyKI1KBY3+fSQAN9L+QADL0YJAAAGJCcA== Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:48:21 -0000 Hi, Also, both 3265 and 3265bis contains the following text: "A subscriber may send a SUBSCRIBE request with an "Expires" header field of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY transaction with a "Subscription-State" of "terminated" completes." Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 8. huhtikuuta 2010 9:46 > To: sipcore@ietf.org > Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response=20 > confirms (re-)subscription? [was rfc3265bis: SIP events redux=20 > [was Minutes Posted]] >=20 >=20 > Hi, >=20 > In the case of DE-subscriptions (which is just one variant of=20 > re-subscription), I still think there are some issues=20 > regarding whether the SUB 200 or the NOT req acknowledges the SUB req. >=20 > Assuming the sub dialog is terminated when an entity receives=20 > a SUB 200 that contains 'Expires: 0'. >=20 > Now, if there is then a NOT request (that contains=20 > 'Subscription-State: terminated'), won't it be treated as an=20 > out-of-dialog request, and rejected? >=20 > (Again, IF one is supposed to wait for the NOT req before=20 > terminating the dialog we again have a problem with the subnot draft.) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 7. huhtikuuta 2010 9:21 > > To: Adam Roach; Brett Tate > > Cc: SIPCORE > > Subject: [sipcore] Rfc3265bis: NOTIFY request or response confirms=20 > > (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes=20 > > Posted]] > >=20 > >=20 > > Hi, > >=20 > > I haven't double checked whether it is said in 3265bis, but we also=20 > > need to make clear whether it is the NOTIFY request, or the NOT 200=20 > > response, that "acknowledges" the (re-)subscription. > >=20 > > Because, a NOTIFY request can also be rejected (e.g. due to=20 > overload),=20 > > so in order to avoid sub state unsynch every entity in the=20 > path needs=20 > > to know what a NOT non-200 response means. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > > Sent: 7. huhtikuuta 2010 2:37 > > > To: Brett Tate > > > Cc: SIPCORE > > > Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes=20 > > > Posted] > > >=20 > > > On 4/6/10 17:46, Apr 6, Brett Tate wrote: > > > >> Is there *any* problem here? This seems to be working > > > about as well > > > >> as anyone might hope. > > > >> =20 > > > > It works okay excluding the non backward compatibility with > > > RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)... > > >=20 > > > I don't think it's accurate to characterize the change as=20 > > > non-backwards-compatible. The only wire-visible behavior that one=20 > > > could conceivable observe is that a subscriber might make a > > different > > > decision about which subscription to accept if the > > SUBSCRIBE forks and > > > the subscriber wants only one subscription. > > >=20 > > > What we *do* gain is a simplification for implementors.=20 > > > Because the behavior of establishing the dialog when a > > NOTIFY shows up > > > (instead of "the first of a 2xx or a NOTIFY) is much easier > > to code, > > > people will make fewer mistakes, and have fewer bugs. But=20 > you'd be=20 > > > hard pressed to see a difference on the wire. > > >=20 > > > > The draft's Timer N (and lack of related NOTIFY) text is > > > potentially > > > > worded in a way which does not require the tear down (and non > > > > creation) of subscription. > > >=20 > > > Tear-down of existing dialogs is still an open issue,=20 > sure. I don't=20 > > > get where you see any wiggle room in what happens if Timer > > N fires for > > > the first SUBSCRIBE/NOTIFY exchange. > > >=20 > > > /a > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From gao.yang2@zte.com.cn Thu Apr 8 01:05:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934083A699A for ; Thu, 8 Apr 2010 01:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.848 X-Spam-Level: X-Spam-Status: No, score=-98.848 tagged_above=-999 required=5 tests=[AWL=-1.813, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPDz-VF9zGH1 for ; Thu, 8 Apr 2010 01:05:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 4EE293A6A0D for ; Thu, 8 Apr 2010 01:04:30 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Thu, 8 Apr 2010 16:02:09 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 97773.3690589170; Thu, 8 Apr 2010 16:01:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o387xtpf076445; Thu, 8 Apr 2010 15:59:55 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <0B28F3C8F2581D419709A71814CA59D703533CC5@ZMY16EXM67.ds.mot.com> To: "NAVEEN S-RHVG46" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 8 Apr 2010 15:57:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-08 15:59:45, Serialize complete at 2010-04-08 15:59:45 Content-Type: multipart/related; boundary="=_related 002BE6C9482576FF_=" X-MAIL: mse2.zte.com.cn o387xtpf076445 Cc: sipcore@ietf.org Subject: Re: [sipcore] Need Clarification on UAS behaviour X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:05:12 -0000 This is a multipart message in MIME format. --=_related 002BE6C9482576FF_= Content-Type: multipart/alternative; boundary="=_alternative 002BE6CB482576FF_=" --=_alternative 002BE6CB482576FF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkl0IGRlcGVuZHMgb24gaW1wbGVtZW50YXRpb24uIEkga25vdyB0aGVzZSBraW5kcyBv ZiBpbXBsZW1lbnRhdGlvbjoNCg0KMS4gNTAwICsgcmV0cnkgYWZ0ZXI7DQoyLiBCdWZmZXIgdGhl IG5ldyByZXF1ZXN0LCBhbmQgaGFuZGxlIGl0IGFmdGVyIEFDSzsNCjMuIEhhbmRsZSB0aGUgbmV3 IHJlcXVlc3QgYmVmb3JlIEFDSywgaWYgdGhlcmUgaXMgbm90IHZpb2xhdGlvbiBvZiBvdGhlciAN CnJ1bGVzKHN1Y2ggYXMgTy9BIHJ1bGVzKS4NCg0KQW5kIHRoZXJlJ3Mgb25lIHZhcmlhdGlvbiBv ZiB0aGUgc2Vjb25kIG9uZTogSnVzdCBkaXNjYXJkaW5nIHRoZSBuZXcgDQpyZXF1ZXN0LCBhbmQg aGFuZGxlIGl0J3MgcmV0cmFuc21pdHRpbmcgY29weSBhZnRlciBBQ0suDQoNCkdhbw0KDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAg ICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFu ZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoN CiJOQVZFRU4gUy1SSFZHNDYiIDxuYXZlZW4uc2hpdmFubmFAbW90b3JvbGEuY29tPiANCreivP7I yzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNC0wOCAxMjo0Nw0KDQrK1bz+yMsN CjxzaXBjb3JlQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbc2lwY29yZV0gTmVlZCBDbGFyaWZp Y2F0aW9uIG9uIFVBUyBiZWhhdmlvdXINCg0KDQoNCg0KDQoNCkhpLA0KIA0KSW4gU2VjdGlvbiAx NC4yIFVBUyBCZWhhdmlvdXIsIHdlIGhhdmUgcmVxdWlyZW1lbnQgc3RhdGluZyBhcyBiZWxvdw0K IA0KICAgQSBVQVMgdGhhdCByZWNlaXZlcyBhIHNlY29uZCBJTlZJVEUgYmVmb3JlIGl0IHNlbmRz IHRoZSBmaW5hbA0KICAgcmVzcG9uc2UgdG8gYSBmaXJzdCBJTlZJVEUgd2l0aCBhIGxvd2VyIENT ZXEgc2VxdWVuY2UgbnVtYmVyIG9uIHRoZQ0KICAgc2FtZSBkaWFsb2cgTVVTVCByZXR1cm4gYSA1 MDAgKFNlcnZlciBJbnRlcm5hbCBFcnJvcikgcmVzcG9uc2UgdG8gdGhlDQogICBzZWNvbmQgSU5W SVRFIGFuZCBNVVNUIGluY2x1ZGUgYSBSZXRyeS1BZnRlciBoZWFkZXIgZmllbGQgd2l0aCBhDQog ICByYW5kb21seSBjaG9zZW4gdmFsdWUgb2YgYmV0d2VlbiAwIGFuZCAxMCBzZWNvbmRzLg0KIA0K QWJvdmUgcmVxdWlyZW1lbnQgaXMgdmFsaWQgd2hlbiB3ZSByZWNlaXZlIElOVklURSwgYmVmb3Jl IHNlbmRpbmcgMnh4IA0KcmVzcG9uc2UuLi4gd2UgYXJlIHJlc3BvbmRpbmcgd2l0aCA1MDAgaW4g b3VyIGltcGxlbWVudGF0aW9uLi4uDQogDQogDQpXaGF0J3MgdGhlIFVBUyBiZWhhdmlvdXIgPw0K IA0KSWYgd2UgcmVjZWl2ZSBJTlZJVEUsIGFmdGVyIHNlbmRpbmcgZmluYWwgcmVzcG9uc2UsIGJl Zm9yZSBnZXR0aW5nIEFDSy4gDQogDQoNCiANCiANCg0KIA0KUmVnYXJkcywNCk5hdmVlbg0KIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1h aWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXBjb3JlDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002BE6CB482576FF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SXQgZGVwZW5kcyBvbiBpbXBsZW1lbnRh dGlvbi4gSSBrbm93DQp0aGVzZSBraW5kcyBvZiBpbXBsZW1lbnRhdGlvbjo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuIDUwMCArIHJldHJ5IGFmdGVy OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gQnVmZmVyIHRo ZSBuZXcgcmVxdWVzdCwgYW5kIGhhbmRsZQ0KaXQgYWZ0ZXIgQUNLOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+My4gSGFuZGxlIHRoZSBuZXcgcmVxdWVzdCBiZWZv cmUgQUNLLA0KaWYgdGhlcmUgaXMgbm90IHZpb2xhdGlvbiBvZiBvdGhlciBydWxlcyhzdWNoIGFz IE8vQSBydWxlcykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5BbmQgdGhlcmUncyBvbmUgdmFyaWF0aW9uIG9mIHRoZSBzZWNvbmQNCm9uZTogSnVzdCBk aXNjYXJkaW5nIHRoZSBuZXcgcmVxdWVzdCwgYW5kIGhhbmRsZSBpdCdzIHJldHJhbnNtaXR0aW5n IGNvcHkNCmFmdGVyIEFDSy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNw OyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVs MiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O05BVkVF TiBTLVJIVkc0NiZxdW90Ow0KJmx0O25hdmVlbi5zaGl2YW5uYUBtb3Rvcm9sYS5jb20mZ3Q7PC9i PiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5i c3A7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTAtMDQtMDggMTI6NDc8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5b c2lwY29yZV0gTmVlZCBDbGFyaWZpY2F0aW9uIG9uIFVBUw0KYmVoYXZpb3VyPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5I aSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPkluIFNlY3Rpb24gMTQuMiBVQVMgQmVoYXZpb3VyLCB3ZSBoYXZlIHJl cXVpcmVtZW50DQpzdGF0aW5nIGFzIGJlbG93PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48Yj4mbmJzcDsgJm5ic3A7 QSBVQVMgdGhhdCByZWNlaXZlcyBhIHNlY29uZA0KSU5WSVRFIGJlZm9yZSBpdCBzZW5kcyB0aGUg ZmluYWw8YnI+DQogJm5ic3A7IHJlc3BvbnNlIHRvIGEgZmlyc3QgSU5WSVRFIHdpdGggYSBsb3dl ciBDU2VxIHNlcXVlbmNlIG51bWJlciBvbg0KdGhlPGJyPg0KICZuYnNwOyBzYW1lIGRpYWxvZyBN VVNUIHJldHVybiBhIDUwMCAoU2VydmVyIEludGVybmFsIEVycm9yKSByZXNwb25zZQ0KdG8gdGhl PGJyPg0KICZuYnNwOyBzZWNvbmQgSU5WSVRFIGFuZCBNVVNUIGluY2x1ZGUgYSBSZXRyeS1BZnRl ciBoZWFkZXIgZmllbGQgd2l0aA0KYTxicj4NCiAmbmJzcDsgcmFuZG9tbHkgY2hvc2VuIHZhbHVl IG9mIGJldHdlZW4gMCBhbmQgMTAgc2Vjb25kcy48L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5BYm92ZSByZXF1 aXJlbWVudCBpcyB2YWxpZCB3aGVuIHdlIHJlY2VpdmUNCklOVklURSwgYmVmb3JlIHNlbmRpbmcg Mnh4IHJlc3BvbnNlLi4uIHdlIGFyZSByZXNwb25kaW5nIHdpdGggNTAwIGluIG91cg0KaW1wbGVt ZW50YXRpb24uLi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ V2hhdCdzIHRoZSBVQVMgYmVoYXZpb3VyID88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkFyaWFsIj5JZiB3ZSBy ZWNlaXZlIElOVklURSwgYWZ0ZXIgc2VuZGluZw0KZmluYWwgcmVzcG9uc2UsIGJlZm9yZSBnZXR0 aW5nIEFDSy4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGlt ZyBzcmM9Y2lkOl8yXzA4QTFENjdDMDhBMUQ0MjgwMDJCRTZDNjQ4MjU3NkZGPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGI+Jm5ic3A7PC9iPjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5SZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+TmF2ZWVuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PHR0Pjxm b250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0 eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3Bl cnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJz cDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVu dGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNw O29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5i c3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNw O3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5i c3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNw O2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9y Jm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7 YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7 dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlm eSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2Uu Jm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4m bmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJz cDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002BE6CB482576FF_=-- --=_related 002BE6C9482576FF_= Content-Type: image/jpeg Content-ID: <_2_08A1D67C08A1D428002BE6C6482576FF> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCADNAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD134d+ CPDOpeBtEvb/AESxuLue1SSWaSMMzsRySe5rov8AhXfhD/oXNN/78ij4Vf8AJOPDn/XlH/KuqoA5 X/hXfhD/AKFzTf8AvyKP+Fd+EP8AoXNN/wC/IrqqKAOV/wCFd+EP+hc03/vyKP8AhXfhD/oXNN/7 8it7VNUs9LW2a/m8oXNwlrEdpO6RzhV4HGT3PFRXWt6fatqS3FyEOnW4urrKt+7iIchunPEb9Mni gDG/4V34Q/6FzTf+/Io/4V34Q/6FzTf+/IrSn8S6VDo1lqrXLNZ3oQ2xjheR5iy7lCRqC7NtBO0D IAORwataPqtnrFobiwlZ0VzG6vG0bxuOqujgMrdDggHBB7igDD/4V34Q/wChc03/AL8ij/hXfhD/ AKFzTf8AvyK6qigDlf8AhXfhD/oXNN/78ij/AIV34Q/6FzTf+/IrqqKAOW+FTFvhn4VZiWY6Zb5J OSf3a11Ncr8KP+SZeFf+wZb/APota6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKzPFOrroHhnV9Zki MyadZzXbRK20uI0L7Qe2cYoA06K5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK P7V8X/8AQr6b/wCDg/8AxigDqqK5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK o654o8T6Jo17ql94XsfslnC88vl6sWbYoycDyRk4HrQB3FFFFABRRRQAUUUUAFFFFAHK/Cr/AJJx 4c/68o/5V1Vcr8Kv+SceHP8Aryj/AJV1VABRRRQBzXj7S7nU9KsnsYWuLiw1C2v1gVlUyiOQMygs QMld2MkDOMkVzOo6NrviDU72cafJplnqctnDKLpopHSC382UsyI5BDuyR7QxO0sTivS6KAPMbTw/ r+jaxaXJtX1O00q+uZYEt2jiM0N0m59qM+A0cu4AEj5G4PGK7rQJr64ju7jUdOXTjJOTFCWVpSgV VDSlCV3Eg9CcLtGc5rUooAKKKKACiiigDlfhR/yTLwr/ANgy3/8ARa11Vcr8KP8AkmXhX/sGW/8A 6LWuqoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACuV+LH/JLPGX/YFvf/RD11Vcr8WP+SWeMv8AsC3v/oh6 AOqooooAKKKKACiuQ8dyxWOseEdTvZo7ewtNRk8+eQ7UiD2s6KWPQDcyrk92FcXqU8Xii81rR9Nj fUtP1jVjdStayqoltYLS1RikhIH+vCLkdQr46UAex0V4rqOoWmtWukS+JLnRItVsbeayurXxDGDZ yXEbhZGjkyAkvyhsgMdkgwOpr0/wROLnwho8qwT26m1jAjnlMrgAYGXIBbOM7iASDnA6UAbdFFFA BXK/Ff8A5Jl4q/7Blx/6Lauqrlfiv/yTLxV/2DLj/wBFtQB1VFFFABRRRQAUUUUAFFFFAHnfgvV9 T0HwppelXnhLX3uLOBYZGiW3ZCRxlT5oyK2v+Etu/wDoUPEn/fu3/wDj1dVRQByv/CW3f/QoeJP+ /dv/APHqP+Etu/8AoUPEn/fu3/8Aj1dVRQByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t/ /j1dVRQByv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PVd8Canc6z4N0fUb5la6ubZ JJCq4BYjnjtW7QByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t//j1dVRQByv8Awlt3/wBC h4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PV1VFAHPfDuwudL8BeHbC/hMF3bWEEU0RIJRwgBGRkc H0roaKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigArlfix/ySzxl/2Bb3/0Q9dVXP8AxEsLnVfh/wCJtOsI jNeXel3VvBGCBvd4mVRk8DJI60AdBRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/AH7t/wD4 9QB1VFcr/wAJbd/9Ch4k/wC/dv8A/HqP+Etu/wDoUPEn/fu3/wDj1AHVEAggjIPagAAAAYA7Vyv/ AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ8Sf9+7f/AOPUAdUQGGCAR15orlf+Etu/+hQ8Sf8Afu3/ APj1H/CW3f8A0KHiT/v3b/8Ax6gDqqK5X/hLbv8A6FDxJ/37t/8A49R/wlt3/wBCh4k/792//wAe oA6quV+K/wDyTLxV/wBgy4/9FtR/wlt3/wBCh4k/792//wAerE8bavqeveD9a0my8JeIFub6zlt4 mlW3VAzqQCx87gZNAHotFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCV dVXmHw28T3Vv4C0GFfC2vzqloiiWJICj8dRmUHH1Arpf+Etu/wDoUPEn/fu3/wDj1AHVUVyv/CW3 f/QoeJP+/dv/APHqP+Etu/8AoUPEn/fu3/8Aj1AHVUVyv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6F DxJ/37t//j1AHVUVyv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PUAdVRXK/8ACW3f /QoeJP8Av3b/APx6j/hLbv8A6FDxJ/37t/8A49QB1VFcr/wlt3/0KHiT/v3b/wDx6j/hLbv/AKFD xJ/37t//AI9QB1VFcr/wlt3/ANCh4k/792//AMeo/wCEtu/+hQ8Sf9+7f/49QB1VFcr/AMJbd/8A QoeJP+/dv/8AHqP+Etu/+hQ8Sf8Afu3/APj1AHVUVyv/AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ 8Sf9+7f/AOPUAdVRXK/8Jbd/9Ch4k/792/8A8eo/4S27/wChQ8Sf9+7f/wCPUAdVRXK/8Jbd/wDQ oeJP+/dv/wDHqP8AhLbv/oUPEn/fu3/+PUAdVRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/ AH7t/wD49QB1VFeeeNPFV5J4O15B4Z8Q2pbT7gCeRYAsX7tvmJWUkAdeATXK+Jb/AFLR9O8fauLi 4m0ySP7FcRhiTbMdOtzFOnoN8hV8f3lb+E0Ae20V5hdS3NvPceFUlm3a7LDcW8m85jgkUm7AJ6Ee VI2R0M6Vn6xpVnf+GbS8ukke5Pid7PzPNdT5LavIpTg9NrEfSgD1+ivEX06xi8f+KLJrPR5rS1e1 SFNR1qW0MSm3QkIoR9wzzkkc16Ve+Jrm2u5oU8Ma/cpGxUTQpAUceq5lBx9QKAOkorlf+Etu/wDo UPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k /wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ /wB+7f8A+PUf8Jbd/wDQoeJP+/dv/wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v 3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUP En/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ/wB+7f8A+PUf8Jbd/wDQoeJP+/dv /wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/3 7t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A 8eoA6qo7mCK6t5be4jWWCVCkiMMhlIwQR6EV4J8ePi/4j8G2+hXWi6Pd6f5s0izR6rBE0c4ABAGy QsCOehHWt74QfF3WPHQhS+8D6tao/H9oQYNqffdJtwPZS5/OgDufhW7y/DDwfJIzO7aPZszMckkw Jkk11Fcr8J/+SWeDf+wLZf8AohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDlfhV/yTjw5/15R/yrqq5X4Vf8k48Of9eUf8q6qgAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKCQOpxQA2WNJY3jlRXjcFWVhkMD1BFMNvAUmQwxlZv9aCow/AX5vXg Ac9hUm4btuRuxnHfFLQAwwxmVJTGhkQFVcqMqDjIB7A4H5Cm/ZoPL8vyYtm/zNuwY37t27Hru5z6 81LRQBQutG0u7naa702ynmbGZJYFZjjjkkVfHA4oooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigCjqWj6Zqk1tLqWn2l5JasWgaeFZDEx6lcjg8dRV6iigDlfhP/yS zwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigD53vPE/xR0b4b6EvgrwpaXlkLKPF7HKbmbp1EHykH8HFQfs7eNPiDr0vih9Ztm1 a7hmhVo766+x/Zsh+FjERAz34HQda9l+FX/JOPDn/XlH/Kup2jcWwNxGCe/+eaAOW/tXxf8A9Cvp v/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A 8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xi j+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+2vFK8P4SjZh1MeqRlfwJUH9BXV UUAcr/bfif8A6FH/AMqcX+FH9t+J/wDoUf8Aypxf4V1VFAHK/wBt+J/+hR/8qcX+FH9t+J/+hR/8 qcX+FdVRQByv9t+J/wDoUf8Aypxf4Uf234n/AOhR/wDKnF/hXVUUAcr/AG34n/6FH/ypxf4Uf234 n/6FH/ypxf4V1VFAHK/234n/AOhR/wDKnF/hR/bfif8A6FH/AMqcX+FdVRQByv8Abfif/oUf/KnF /hWT4qGo6ppdhc6rp9xpklpq+nGOGO8EiTZvIAWcL12jOAeOc9QCPQKKAPFdZWX/AITu+u7Brb+2 k1NlhsxEPtzJ9j8tZBIT/wAe+SG2bcZH3s/LXQfDF7A6tENAeBrQ6NbNf+QwP+lFm5k7+aRv3Z+b pu7V6VRQB4B4M0yS10/w3qNxZaTY2M2ryb9Wt7c/bAwuZAkcr8YSQ/u93IwwGOcjf8Ha5rdxpNlN Hfpb29qdJj+yR2saxutwyJID8uRgNldpGD1yOB7BRQB4jqni3U7m3hSTVoLuWexluNQ0t7WJhYTL cQKsZG3I272XD5JK544rZk8SeI7fTH1Jb77R541BRA1shW3ENyI0kXaAx2puZgSc9sV3umeHNP02 /wDtluLlpljeGPzrmSVYkZgzKgYkKCVXp/dA6AVo39pDf2c1rcqzQyqUYK5Q49mBBB9wQRQBwXh/ xLqr6hrcentP4ssbeWFLee3e2j2ho9zZfKI/Jx8vTp1zW1/wkWv/APQlal/4G2n/AMdra0bR7XSF uPsvnPJcyedNLPM0ryNtCglmJPCqoA6DFaFAHK/8JFr/AP0JWpf+Btp/8do/4SLX/wDoStS/8DbT /wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf/wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWp f+Btp/8AHaP+El1tP9Z4H1t89PJurFsfXdcL+ma6qigDlf8AhKNX/wChE8Sf9/8ATv8A5Ko/4SjV /wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9/wDTv/kquqoo A5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKNX/wChE8Sf9/8A Tv8A5Ko/4SjV/wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9 /wDTv/kquqooA5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKtT XmXwR4kjX132L/olyT+lH/CW3f8A0KHiT/v3b/8Ax6uqooA5X/hLbv8A6FDxJ/37t/8A49Tk8V3b uq/8Ij4jXJxlkt8D6/vq6iigDlfhP/ySzwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiimTGQQuYVR5QDtV22gnsCQDge+DQBzHwq/ 5Jx4c/68o/5V1VfI2teNvjFovgPSY9D0BbLREtE8vULKEXcjJj7zHkJ+KDHrXrXwZ8R+M9T+GWh3 k2lW+qyTRyM15daqUklPmPyy+U2MdMZPAFAHr9Fcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDB wf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bw f/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB 1VFcr/avi/8A6FfTf/Bwf/jFH9r+LE5k8K2jD0h1YMf/AB6NRj8aAOqorlf7b8T/APQo/wDlTi/w o/tvxP8A9Cj/AOVOL/CgDqqK5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AAoA6qiuV/tvxP8A 9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8KAOqorlf7b8T/8AQo/+VOL/AAo/tvxP/wBCj/5U4v8ACgDq qK5X+2/E/wD0KP8A5U4v8KP7b8T/APQo/wDlTi/woA6qiuV/tvxP/wBCj/5U4v8ACj+2/E//AEKP /lTi/wAKAOpZgoyxAGQOT3PSlryvxxrlpizTxhoGn29++9NOj1K7jmtckDzJZBjA2AKBwWO8hcZY jGsYra1uIYbK9ivfE8Oo2MOnXLupuZ7EW0G91ycmJk85m/hzuz8woA9toryz4WNZnUtKOkNCXbQ0 fWvJILfbS0e0z9/N/wBfnd83Bz0FZup/2L/YniNtUe3/AOE+Fzd/ZPm/04Sea32QQA/PsK+Tjb8p Gc/xUAey0V4zo4vBfrN4oihk8Mf25exhEJKx3JuWMcs4PBTflFHRW2Mc5GzvT4h18EgeC9SI9ftt p/8AHaAOporlf+Ei1/8A6ErUv/A20/8AjtH/AAkWv/8AQlal/wCBtp/8doA6qiuV/wCEi1//AKEr Uv8AwNtP/jtH/CRa/wD9CVqX/gbaf/HaAOqorlf+Ei1//oStS/8AA20/+O0f8JFr/wD0JWpf+Btp /wDHaAOqorlf+Ei1/wD6ErUv/A20/wDjtH/CRa//ANCVqX/gbaf/AB2gDqqK5X/hItf/AOhK1L/w NtP/AI7R/wAJJricyeCNYZfSK7smb/x6dR+tAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/wlGr/wDQ ieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUAdVRXK/8A CUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/ wlGr/wDQieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUA dVRXK/8ACUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+ nf8AyVVzSdd1G+vkguvCutadEwJNxdS2bRrgdCI53bnpwp/CgCn8J/8Aklng3/sC2X/ohK6quV+E /wDySzwb/wBgWy/9EJXVUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8Kv+ SceHP+vKP+VdSqhRhQAMk8e9ct8Kv+SceHP+vKP+VdVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRgZzjn1oooAAAM4HXrRgbgcDI4zRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/wDklng3/sC2X/ohK6qv Efgh4U8Pa/4Yludd0HSdTuI49OiSW8s45nVBpNidoLAkDLMcdMk+teif8K48D/8AQm+G/wDwVwf/ ABNAHVUVyv8AwrjwP/0Jvhv/AMFcH/xNRP4A8ApcRW7+E/CyzyhmjjOm24ZwuNxA25IGRn0yKAOv orhT4T+GYskvDoHg0WcjOiT/AGK28tmXduAbbgkbHyO21vQ1of8ACuPA/wD0Jvhv/wAFcH/xNAHV UVx0/gP4f27os/hXwrEzsqKH063UszZwBleScHA9jUzfDrwMqlm8HeGgoGSTpcAAH/fNAHV0V5rb 6b8HrmXy7ez+H8sm1m2xxWbHABJOAOgAJPsK6D/hXHgf/oTfDf8A4K4P/iaAOqorlf8AhXHgf/oT fDf/AIK4P/iaP+FceB/+hN8N/wDgrg/+JoA6qiuV/wCFceB/+hN8N/8Agrg/+Jr5/wD2ptD0nwzc +Gx4b0ux0gXCXBmFhbpb+ZtMe3dsAzjJxnpk0AfVVFFFABRRRQAUUUUAeYfDbxX9m8BaFB/YOvze XaIvmRWe5G46g55FdL/wmX/UueJf/AH/AOyo+FX/ACTjw5/15R/yrqqAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL /qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyr qqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9 S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8A gD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/h Mv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8A AH/7KuqooA8/8XeM5h4T1s22i+I7ScWM5juGtNgiby2w5YNxg857VzPiDXtX0S08canLf3T6UU+x qfMbOnzf2fC8UqH+FWkkKt6MUP8AeNex3EMVxBJBcRpLDIpR43UMrqRggg9QR2qB9NsXt7qB7K2a C7/4+IzEpWb5QnzjGG+VVXnsAOgoA8+udQv4GvPDIvLr7dq00D2M5mJkjt5lJnKtnIMYinZfTdGB jiqerQSXfhq0vZNR1dLk+JXsC0Op3EQMB1V4yhCOAfkO0HGQAACMDHp7WVo1zBctbQG4gRo4ZTGN 8atjcFPUA4GQPQU06dZGAQmztjCs32gIYl2iXf5nmYx97f8ANnru560AeVRWV9N448TWFvba7qVl YvaxwhfEdzb+SGgViD+8y5JJOTk13d74q+yXk1v/AGDr83lsV8yGz3I2O6nPIq1qfhPw7qt493qe gaReXTgBprizjkdsDAyzKScDitlVCqFUAKBgADAAoA5b/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/ AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8A CZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8 S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA 5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54 l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA8I+Nnxn 1fwVBotzo+iXEaTyyJPHqtq0ayKACNhDZBHP+Fa/wm+N0Pj+RLc+F9as5idrXEMJuLVT/tSgDb+I /GvSdf8ADOieIpLN9d0u01E2jM8C3MYkVGOMnaeCeB1FakMUcESRQxpHGgwqIMBR6ACgDy39nT/k Trn/ALh3/pnsK9Vryr9nT/kTrn/uHf8ApnsK9VoAK474mJqNvptlq+hWkt3qmnTkxQxIWZxLG8OM f3Q0iOfaPPauxqrq139g0u8vAnmfZ4Xl2Zxu2qTjPbpQB49rvg6+sdP1jQdPsrqbSrHTp7mwKIW3 TSwxwhRx8z5W5Yj/AKaqe9amujV7DWbnS4U8QzaT5gliuRNduFJhUFS8StKw3ZIUOqg7sn7orX8M /ESO/cHVG0ZLcae2oST6fqJuRAqlBslXYu1jv45OdjDHFaN1490yLUrC1hjvJRPJJFKv2OcTwssY cZg8vzCCD1xjFAGT4Etbma4W51q21NtVm0iwmka5jlCeeiMH4bEYkDYOODk596m+Fs2q5vLfVE1O RUggYXV4J4xLId4b93MMo/ClgjNHyNuOc76+MdDd7QR3UsiXQgMcqWsrRfv8eUGkC7ULblwGIPzD 1FNuPF2l+VpbWl3DIdR8p4Q6yLmNpUjycKSrZkACtt5yDjaxAByHiDStQmj+KgisrpjfQQi12xE+ eRaqp2cfNg8cd6p+JYfEthrsljp76s/h9Jt7SyNdzOWaFcKHizKU3K5ODgMQDgECu7t/Gmgzuix3 r/vDGIi9vKqzB5ViVoyVAdS8iDcuQNwJIBzUzeKtIGpQWC3E0l3NNJbpHFbSv88ZQPkqpCqpkTLH C89aAJfCJ1BvC+lnWWZ9RNuhnZk2MWx1K9j6j1zWvRRQAV8y/tkf8fXhT/cuv5xV9NV8y/tkf8fX hT/cuv5xUAfTVFFFABRRRQAUUUUAcr8Kv+SceHP+vKP+VdVXK/Cr/knHhz/ryj/lXVUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5V+zp/wAidc/9w7/0z2Fe q15B8IrLxTpHgvT7jSdN0S+stTstPvEe51SW2kTGn2sJUqtvIOsJOd3Q9K7X7d44/wChe8N/+D6f /wCQ6AOqqrqtp9v0y8sy/li4heLfjO3cpGcfjXP/AG7xx/0L3hv/AMH0/wD8h0fbvHH/AEL3hv8A 8H0//wAh0AY1x8OZtVtI7fxBrEd2lvYvY2/2ayEG1W2cvln342L8vA65B4xb8OeALfRdZt9SiksY pYndmisrBbeNg0ewD7zNkcnJZuvGBV77d44/6F7w3/4Pp/8A5Do+3eOP+he8N/8Ag+n/APkOgDCt vhm0H9mo2rrPFZNZPGZ7Xe8Zt2RgIzvxGrFOQBn5jzjitUeArRbm8mjupB59/b3iqyAiJIpzOYh7 NI8rZ7bwMfKKsfbvHH/QveG//B9P/wDIdH27xx/0L3hv/wAH0/8A8h0AZTfD64ey0+3l1oMNJhjh 0xvsgzEI5oZVMvzfvD/o8anGzjd3ORraB4UfTNaGp3F+Li4P2suFh8tS1w8DHA3HAUwYA54bk8ZK fbvHH/QveG//AAfT/wDyHR9u8cf9C94b/wDB9P8A/IdAHVUVyv27xx/0L3hv/wAH0/8A8h0fbvHH /QveG/8AwfT/APyHQB1VfMv7ZH/H14U/3Lr+cVe4fbvHH/QveG//AAfT/wDyHXm3xf8Ahx4y+JUu lvND4e0r7AsgAXUZrjzN+3/p3TGNvvnPagD3OiiigAooooAKKKKAOV+FX/JOPDn/AF5R/wAq6quV +FX/ACTjw5/15R/yrqqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKRmCqWYgKOpPagBaKbJIkSF5HVEHVmOAKdQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/+SWeDf+wLZf8AohK6quV+E/8AySzwb/2BbL/0 QldVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABQenHWiigD5g1LxX8XtH+H2ip4S8 M2/9lLZx7L+1H22cjb18vjb+KMPeum/Z68U+OdY8EXVzf2K6xc/2hKjz32oGCRCFT5NnlNgD2x1P Fen/AAq/5Jx4c/68o/5V1QABJAAzyfegDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK 6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/t Xxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7 V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCv pv8A4OD/APGK6qigDlf7Z8VJxJ4TgY+sOqow/wDHkU5/Cj+2/E//AEKP/lTi/wAK6qigDlf7b8T/ APQo/wDlTi/wo/tvxP8A9Cj/AOVOL/CuqooA5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AArq qKAOV/tvxP8A9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8K6qigDlf7b8T/8AQo/+VOL/AAo/tvxP/wBC j/5U4v8ACuqooA5X+2/E/wD0KP8A5U4v8K53xbNrHilrXwzqHh4QQ3RN1cxHUEIlt48ZXcqnafMa HtyA3oa9MooA8e0+/t9S1HSJPiIlibSzspbCX7eqtbrqEcgWRiWG0F0CshPZmx1IqrKtxJf6gfC1 ncx+HI9Ms3ubXLx3U1qLq8+SAdVVk3soyDtCqu3dlfa6KAOSt9buLe1to/DXhee+0UQxm0uLS4to 4njKAjarOCAM45A6U/8A4SLX/wDoStS/8DbT/wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf /wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWpf+Btp/8AHaP+Ei1//oStS/8AA20/+O11VFAHK/8A CRa//wBCVqX/AIG2n/x2j/hItf8A+hK1L/wNtP8A47XVUUAcr/wkWv8A/Qlal/4G2n/x2j/hItf/ AOhK1L/wNtP/AI7XVUUAcr/wkWv/APQlal/4G2n/AMdo/wCEi1//AKErUv8AwNtP/jtdVRQByv8A wkmuJzJ4I1hl9IruyZv/AB6dR+tH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf /JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8A JVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/ AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6 d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVTWXiLU7i8hhm8G6/aRuwVp5prEpGP7zBLlmwPYE+1 dJRQByvwn/5JZ4N/7Atl/wCiErqq5X4T/wDJLPBv/YFsv/RCV1VABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCVdVXMfC9PL+Hnh5c5xZR8/hXT0AFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWf4h1H+x9A1PU/K877Fay3 Pl7tu/YhbbnBxnGM4NAGL8J/+SWeDf8AsC2X/ohK6quW+FI2/C7wevXGjWY/8gJXU0AFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAf/9k= --=_related 002BE6C9482576FF_=-- From naveen.shivanna@motorola.com Thu Apr 8 01:35:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BF13A68F8 for ; Thu, 8 Apr 2010 01:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=-2.495, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_CHARSET_FARAWAY=2.45, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc6If8Z0NNxo for ; Thu, 8 Apr 2010 01:35:48 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id AF4A23A67D9 for ; Thu, 8 Apr 2010 01:35:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: naveen.shivanna@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1270715736!35627621!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 13081 invoked from network); 8 Apr 2010 08:35:36 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2010 08:35:36 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id o388Zadw012134 for ; Thu, 8 Apr 2010 01:35:36 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o388ZZeX009709 for ; Thu, 8 Apr 2010 03:35:35 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o388ZEKs008983 for ; Thu, 8 Apr 2010 03:35:15 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CAD6F6.5BDF3548"; type="multipart/alternative" Date: Thu, 8 Apr 2010 16:34:52 +0800 Message-ID: <0B28F3C8F2581D419709A71814CA59D703533D9C@ZMY16EXM67.ds.mot.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: thread-topic: [sipcore] Need Clarification on UAS behaviour thread-index: AcrW8iAZyoAixMHOTfa08kBzig3RaAAA6UXQ From: "NAVEEN S-RHVG46" To: , X-CFilter-Loop: Reflected Subject: Re: [sipcore] Need Clarification on UAS behaviour X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:35:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD6F6.5BDF3548 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD6F6.5BDF3548" ------_=_NextPart_002_01CAD6F6.5BDF3548 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, =20 If we handle the new request before the ACK.=20 =20 What is the behaviour if we don't receive the ACK for the first INVITE.=20 Should we close the call or should we proceed with the Re-Invite or not. =20 Regards Naveen.S ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: Thursday, April 08, 2010 1:28 PM To: NAVEEN S-RHVG46 Cc: sipcore@ietf.org Subject: Re: [sipcore] Need Clarification on UAS behaviour Hi,=20 It depends on implementation. I know these kinds of implementation:=20 1. 500 + retry after;=20 2. Buffer the new request, and handle it after ACK;=20 3. Handle the new request before ACK, if there is not violation of other = rules(such as O/A rules).=20 And there's one variation of the second one: Just discarding the new = request, and handle it's retransmitting copy after ACK.=20 Gao=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 "NAVEEN S-RHVG46" =20 =B7=A2=BC=FE=C8=CB: sipcore-bounces@ietf.org=20 2010-04-08 12:47=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =D6=F7=CC=E2 [sipcore] Need Clarification on UAS behaviour =09 Hi,=20 =20 In Section 14.2 UAS Behaviour, we have requirement stating as below=20 =20 A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds.=20 =20 Above requirement is valid when we receive INVITE, before sending 2xx = response... we are responding with 500 in our implementation...=20 =20 =20 What's the UAS behaviour ?=20 =20 If we receive INVITE, after sending final response, before getting ACK.=20 =20 =20 =20 =20 =20 Regards,=20 Naveen=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_002_01CAD6F6.5BDF3548 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
If we handle the new request before the ACK.=20
 
What is the behaviour if we don't = receive the ACK=20 for the first INVITE.
Should we close the call or should we proceed = with the=20 Re-Invite or not.
 
Regards
Naveen.S

From: gao.yang2@zte.com.cn=20 [mailto:gao.yang2@zte.com.cn]
Sent: Thursday, April 08, 2010 = 1:28=20 PM
To: NAVEEN S-RHVG46
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Need Clarification on = UAS=20 behaviour


Hi,

It depends on implementation. I know these = kinds of=20 implementation:

1. 500 + = retry=20 after;
2. Buffer the new = request, and=20 handle it after ACK;
3. = Handle the new=20 request before ACK, if there is not violation of other rules(such as O/A = rules).

And there's one = variation of=20 the second one: Just discarding the new request, and handle it's = retransmitting=20 copy after ACK.

Gao=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip=20    : 210012
Tel    : 87211
Tel2  =20 :(+86)-025-52877211
e_mail :=20 gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =


"NAVEEN = S-RHVG46"=20 <naveen.shivanna@motorola.com>
=B7=A2=BC=FE=C8=CB:  sipcore-bounces@ietf.org =

2010-04-08 12:47

=CA=D5=BC=FE=C8=CB
<sipcore@ietf.org>=20
=B3=AD=CB=CD
=D6=F7=CC=E2
[sipcore] Need = Clarification on UAS=20 behaviour

=




Hi,
 
In=20 Section 14.2 UAS Behaviour, we have requirement stating as below=20
 
   A UAS=20 that receives a second INVITE before it sends the final
  = response to a=20 first INVITE with a lower CSeq sequence number on the
  same = dialog MUST=20 return a 500 (Server Internal Error) response to the
  second = INVITE and=20 MUST include a Retry-After header field with a
  randomly chosen = value=20 of between 0 and 10 seconds.
  =
Above requirement is valid when we receive INVITE, = before=20 sending 2xx response... we are responding with 500 in our=20 implementation...
 
 
What's the UAS = behaviour=20 ?
 
If=20 we receive INVITE, after sending final response, before getting ACK.=20
 

 =20
 

 
Regards,
Naveen
 _______________________________________________
sipcore = mailing=20 list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore= 


--------------------------------------------=
------------
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_002_01CAD6F6.5BDF3548-- ------_=_NextPart_001_01CAD6F6.5BDF3548 Content-Type: image/jpeg; name="ATT2610934.jpg" Content-Transfer-Encoding: base64 Content-ID: <735393008@08042010-2024> Content-Description: ATT2610934.jpg Content-Location: ATT2610934.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCADNAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD134d+ CPDOpeBtEvb/AESxuLue1SSWaSMMzsRySe5rov8AhXfhD/oXNN/78ij4Vf8AJOPDn/XlH/KuqoA5 X/hXfhD/AKFzTf8AvyKP+Fd+EP8AoXNN/wC/IrqqKAOV/wCFd+EP+hc03/vyKP8AhXfhD/oXNN/7 8it7VNUs9LW2a/m8oXNwlrEdpO6RzhV4HGT3PFRXWt6fatqS3FyEOnW4urrKt+7iIchunPEb9Mni gDG/4V34Q/6FzTf+/Io/4V34Q/6FzTf+/IrSn8S6VDo1lqrXLNZ3oQ2xjheR5iy7lCRqC7NtBO0D IAORwataPqtnrFobiwlZ0VzG6vG0bxuOqujgMrdDggHBB7igDD/4V34Q/wChc03/AL8ij/hXfhD/ AKFzTf8AvyK6qigDlf8AhXfhD/oXNN/78ij/AIV34Q/6FzTf+/IrqqKAOW+FTFvhn4VZiWY6Zb5J OSf3a11Ncr8KP+SZeFf+wZb/APota6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKzPFOrroHhnV9Zki MyadZzXbRK20uI0L7Qe2cYoA06K5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK P7V8X/8AQr6b/wCDg/8AxigDqqK5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK o654o8T6Jo17ql94XsfslnC88vl6sWbYoycDyRk4HrQB3FFFFABRRRQAUUUUAFFFFAHK/Cr/AJJx 4c/68o/5V1Vcr8Kv+SceHP8Aryj/AJV1VABRRRQBzXj7S7nU9KsnsYWuLiw1C2v1gVlUyiOQMygs QMld2MkDOMkVzOo6NrviDU72cafJplnqctnDKLpopHSC382UsyI5BDuyR7QxO0sTivS6KAPMbTw/ r+jaxaXJtX1O00q+uZYEt2jiM0N0m59qM+A0cu4AEj5G4PGK7rQJr64ju7jUdOXTjJOTFCWVpSgV VDSlCV3Eg9CcLtGc5rUooAKKKKACiiigDlfhR/yTLwr/ANgy3/8ARa11Vcr8KP8AkmXhX/sGW/8A 6LWuqoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACuV+LH/JLPGX/YFvf/RD11Vcr8WP+SWeMv8AsC3v/oh6 AOqooooAKKKKACiuQ8dyxWOseEdTvZo7ewtNRk8+eQ7UiD2s6KWPQDcyrk92FcXqU8Xii81rR9Nj fUtP1jVjdStayqoltYLS1RikhIH+vCLkdQr46UAex0V4rqOoWmtWukS+JLnRItVsbeayurXxDGDZ yXEbhZGjkyAkvyhsgMdkgwOpr0/wROLnwho8qwT26m1jAjnlMrgAYGXIBbOM7iASDnA6UAbdFFFA BXK/Ff8A5Jl4q/7Blx/6Lauqrlfiv/yTLxV/2DLj/wBFtQB1VFFFABRRRQAUUUUAFFFFAHnfgvV9 T0HwppelXnhLX3uLOBYZGiW3ZCRxlT5oyK2v+Etu/wDoUPEn/fu3/wDj1dVRQByv/CW3f/QoeJP+ /dv/APHqP+Etu/8AoUPEn/fu3/8Aj1dVRQByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t/ /j1dVRQByv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PVd8Canc6z4N0fUb5la6ubZ JJCq4BYjnjtW7QByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t//j1dVRQByv8Awlt3/wBC h4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PV1VFAHPfDuwudL8BeHbC/hMF3bWEEU0RIJRwgBGRkc H0roaKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigArlfix/ySzxl/2Bb3/0Q9dVXP8AxEsLnVfh/wCJtOsI jNeXel3VvBGCBvd4mVRk8DJI60AdBRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/AH7t/wD4 9QB1VFcr/wAJbd/9Ch4k/wC/dv8A/HqP+Etu/wDoUPEn/fu3/wDj1AHVEAggjIPagAAAAYA7Vyv/ AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ8Sf9+7f/AOPUAdUQGGCAR15orlf+Etu/+hQ8Sf8Afu3/ APj1H/CW3f8A0KHiT/v3b/8Ax6gDqqK5X/hLbv8A6FDxJ/37t/8A49R/wlt3/wBCh4k/792//wAe oA6quV+K/wDyTLxV/wBgy4/9FtR/wlt3/wBCh4k/792//wAerE8bavqeveD9a0my8JeIFub6zlt4 mlW3VAzqQCx87gZNAHotFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCV dVXmHw28T3Vv4C0GFfC2vzqloiiWJICj8dRmUHH1Arpf+Etu/wDoUPEn/fu3/wDj1AHVUVyv/CW3 f/QoeJP+/dv/APHqP+Etu/8AoUPEn/fu3/8Aj1AHVUVyv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6F DxJ/37t//j1AHVUVyv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PUAdVRXK/8ACW3f /QoeJP8Av3b/APx6j/hLbv8A6FDxJ/37t/8A49QB1VFcr/wlt3/0KHiT/v3b/wDx6j/hLbv/AKFD xJ/37t//AI9QB1VFcr/wlt3/ANCh4k/792//AMeo/wCEtu/+hQ8Sf9+7f/49QB1VFcr/AMJbd/8A QoeJP+/dv/8AHqP+Etu/+hQ8Sf8Afu3/APj1AHVUVyv/AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ 8Sf9+7f/AOPUAdVRXK/8Jbd/9Ch4k/792/8A8eo/4S27/wChQ8Sf9+7f/wCPUAdVRXK/8Jbd/wDQ oeJP+/dv/wDHqP8AhLbv/oUPEn/fu3/+PUAdVRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/ AH7t/wD49QB1VFeeeNPFV5J4O15B4Z8Q2pbT7gCeRYAsX7tvmJWUkAdeATXK+Jb/AFLR9O8fauLi 4m0ySP7FcRhiTbMdOtzFOnoN8hV8f3lb+E0Ae20V5hdS3NvPceFUlm3a7LDcW8m85jgkUm7AJ6Ee VI2R0M6Vn6xpVnf+GbS8ukke5Pid7PzPNdT5LavIpTg9NrEfSgD1+ivEX06xi8f+KLJrPR5rS1e1 SFNR1qW0MSm3QkIoR9wzzkkc16Ve+Jrm2u5oU8Ma/cpGxUTQpAUceq5lBx9QKAOkorlf+Etu/wDo UPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k /wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ /wB+7f8A+PUf8Jbd/wDQoeJP+/dv/wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v 3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUP En/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ/wB+7f8A+PUf8Jbd/wDQoeJP+/dv /wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/3 7t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A 8eoA6qo7mCK6t5be4jWWCVCkiMMhlIwQR6EV4J8ePi/4j8G2+hXWi6Pd6f5s0izR6rBE0c4ABAGy QsCOehHWt74QfF3WPHQhS+8D6tao/H9oQYNqffdJtwPZS5/OgDufhW7y/DDwfJIzO7aPZszMckkw Jkk11Fcr8J/+SWeDf+wLZf8AohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDlfhV/yTjw5/15R/yrqq5X4Vf8k48Of9eUf8q6qgAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKCQOpxQA2WNJY3jlRXjcFWVhkMD1BFMNvAUmQwxlZv9aCow/AX5vXg Ac9hUm4btuRuxnHfFLQAwwxmVJTGhkQFVcqMqDjIB7A4H5Cm/ZoPL8vyYtm/zNuwY37t27Hru5z6 81LRQBQutG0u7naa702ynmbGZJYFZjjjkkVfHA4oooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigCjqWj6Zqk1tLqWn2l5JasWgaeFZDEx6lcjg8dRV6iigDlfhP/yS zwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigD53vPE/xR0b4b6EvgrwpaXlkLKPF7HKbmbp1EHykH8HFQfs7eNPiDr0vih9Ztm1 a7hmhVo766+x/Zsh+FjERAz34HQda9l+FX/JOPDn/XlH/Kup2jcWwNxGCe/+eaAOW/tXxf8A9Cvp v/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A 8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xi j+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+2vFK8P4SjZh1MeqRlfwJUH9BXV UUAcr/bfif8A6FH/AMqcX+FH9t+J/wDoUf8Aypxf4V1VFAHK/wBt+J/+hR/8qcX+FH9t+J/+hR/8 qcX+FdVRQByv9t+J/wDoUf8Aypxf4Uf234n/AOhR/wDKnF/hXVUUAcr/AG34n/6FH/ypxf4Uf234 n/6FH/ypxf4V1VFAHK/234n/AOhR/wDKnF/hR/bfif8A6FH/AMqcX+FdVRQByv8Abfif/oUf/KnF /hWT4qGo6ppdhc6rp9xpklpq+nGOGO8EiTZvIAWcL12jOAeOc9QCPQKKAPFdZWX/AITu+u7Brb+2 k1NlhsxEPtzJ9j8tZBIT/wAe+SG2bcZH3s/LXQfDF7A6tENAeBrQ6NbNf+QwP+lFm5k7+aRv3Z+b pu7V6VRQB4B4M0yS10/w3qNxZaTY2M2ryb9Wt7c/bAwuZAkcr8YSQ/u93IwwGOcjf8Ha5rdxpNlN Hfpb29qdJj+yR2saxutwyJID8uRgNldpGD1yOB7BRQB4jqni3U7m3hSTVoLuWexluNQ0t7WJhYTL cQKsZG3I272XD5JK544rZk8SeI7fTH1Jb77R541BRA1shW3ENyI0kXaAx2puZgSc9sV3umeHNP02 /wDtluLlpljeGPzrmSVYkZgzKgYkKCVXp/dA6AVo39pDf2c1rcqzQyqUYK5Q49mBBB9wQRQBwXh/ xLqr6hrcentP4ssbeWFLee3e2j2ho9zZfKI/Jx8vTp1zW1/wkWv/APQlal/4G2n/AMdra0bR7XSF uPsvnPJcyedNLPM0ryNtCglmJPCqoA6DFaFAHK/8JFr/AP0JWpf+Btp/8do/4SLX/wDoStS/8DbT /wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf/wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWp f+Btp/8AHaP+El1tP9Z4H1t89PJurFsfXdcL+ma6qigDlf8AhKNX/wChE8Sf9/8ATv8A5Ko/4SjV /wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9/wDTv/kquqoo A5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKNX/wChE8Sf9/8A Tv8A5Ko/4SjV/wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9 /wDTv/kquqooA5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKtT XmXwR4kjX132L/olyT+lH/CW3f8A0KHiT/v3b/8Ax6uqooA5X/hLbv8A6FDxJ/37t/8A49Tk8V3b uq/8Ij4jXJxlkt8D6/vq6iigDlfhP/ySzwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiimTGQQuYVR5QDtV22gnsCQDge+DQBzHwq/ 5Jx4c/68o/5V1VfI2teNvjFovgPSY9D0BbLREtE8vULKEXcjJj7zHkJ+KDHrXrXwZ8R+M9T+GWh3 k2lW+qyTRyM15daqUklPmPyy+U2MdMZPAFAHr9Fcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDB wf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bw f/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB 1VFcr/avi/8A6FfTf/Bwf/jFH9r+LE5k8K2jD0h1YMf/AB6NRj8aAOqorlf7b8T/APQo/wDlTi/w o/tvxP8A9Cj/AOVOL/CgDqqK5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AAoA6qiuV/tvxP8A 9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8KAOqorlf7b8T/8AQo/+VOL/AAo/tvxP/wBCj/5U4v8ACgDq qK5X+2/E/wD0KP8A5U4v8KP7b8T/APQo/wDlTi/woA6qiuV/tvxP/wBCj/5U4v8ACj+2/E//AEKP /lTi/wAKAOpZgoyxAGQOT3PSlryvxxrlpizTxhoGn29++9NOj1K7jmtckDzJZBjA2AKBwWO8hcZY jGsYra1uIYbK9ivfE8Oo2MOnXLupuZ7EW0G91ycmJk85m/hzuz8woA9toryz4WNZnUtKOkNCXbQ0 fWvJILfbS0e0z9/N/wBfnd83Bz0FZup/2L/YniNtUe3/AOE+Fzd/ZPm/04Sea32QQA/PsK+Tjb8p Gc/xUAey0V4zo4vBfrN4oihk8Mf25exhEJKx3JuWMcs4PBTflFHRW2Mc5GzvT4h18EgeC9SI9ftt p/8AHaAOporlf+Ei1/8A6ErUv/A20/8AjtH/AAkWv/8AQlal/wCBtp/8doA6qiuV/wCEi1//AKEr Uv8AwNtP/jtH/CRa/wD9CVqX/gbaf/HaAOqorlf+Ei1//oStS/8AA20/+O0f8JFr/wD0JWpf+Btp /wDHaAOqorlf+Ei1/wD6ErUv/A20/wDjtH/CRa//ANCVqX/gbaf/AB2gDqqK5X/hItf/AOhK1L/w NtP/AI7R/wAJJricyeCNYZfSK7smb/x6dR+tAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/wlGr/wDQ ieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUAdVRXK/8A CUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/ wlGr/wDQieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUA dVRXK/8ACUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+ nf8AyVVzSdd1G+vkguvCutadEwJNxdS2bRrgdCI53bnpwp/CgCn8J/8Aklng3/sC2X/ohK6quV+E /wDySzwb/wBgWy/9EJXVUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8Kv+ SceHP+vKP+VdSqhRhQAMk8e9ct8Kv+SceHP+vKP+VdVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRgZzjn1oooAAAM4HXrRgbgcDI4zRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/wDklng3/sC2X/ohK6qv Efgh4U8Pa/4Yludd0HSdTuI49OiSW8s45nVBpNidoLAkDLMcdMk+teif8K48D/8AQm+G/wDwVwf/ ABNAHVUVyv8AwrjwP/0Jvhv/AMFcH/xNRP4A8ApcRW7+E/CyzyhmjjOm24ZwuNxA25IGRn0yKAOv orhT4T+GYskvDoHg0WcjOiT/AGK28tmXduAbbgkbHyO21vQ1of8ACuPA/wD0Jvhv/wAFcH/xNAHV UVx0/gP4f27os/hXwrEzsqKH063UszZwBleScHA9jUzfDrwMqlm8HeGgoGSTpcAAH/fNAHV0V5rb 6b8HrmXy7ez+H8sm1m2xxWbHABJOAOgAJPsK6D/hXHgf/oTfDf8A4K4P/iaAOqorlf8AhXHgf/oT fDf/AIK4P/iaP+FceB/+hN8N/wDgrg/+JoA6qiuV/wCFceB/+hN8N/8Agrg/+Jr5/wD2ptD0nwzc +Gx4b0ux0gXCXBmFhbpb+ZtMe3dsAzjJxnpk0AfVVFFFABRRRQAUUUUAeYfDbxX9m8BaFB/YOvze XaIvmRWe5G46g55FdL/wmX/UueJf/AH/AOyo+FX/ACTjw5/15R/yrqqAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL /qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyr qqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9 S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8A gD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/h Mv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8A AH/7KuqooA8/8XeM5h4T1s22i+I7ScWM5juGtNgiby2w5YNxg857VzPiDXtX0S08canLf3T6UU+x qfMbOnzf2fC8UqH+FWkkKt6MUP8AeNex3EMVxBJBcRpLDIpR43UMrqRggg9QR2qB9NsXt7qB7K2a C7/4+IzEpWb5QnzjGG+VVXnsAOgoA8+udQv4GvPDIvLr7dq00D2M5mJkjt5lJnKtnIMYinZfTdGB jiqerQSXfhq0vZNR1dLk+JXsC0Op3EQMB1V4yhCOAfkO0HGQAACMDHp7WVo1zBctbQG4gRo4ZTGN 8atjcFPUA4GQPQU06dZGAQmztjCs32gIYl2iXf5nmYx97f8ANnru560AeVRWV9N448TWFvba7qVl YvaxwhfEdzb+SGgViD+8y5JJOTk13d74q+yXk1v/AGDr83lsV8yGz3I2O6nPIq1qfhPw7qt493qe gaReXTgBprizjkdsDAyzKScDitlVCqFUAKBgADAAoA5b/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/ AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8A CZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8 S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA 5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54 l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA8I+Nnxn 1fwVBotzo+iXEaTyyJPHqtq0ayKACNhDZBHP+Fa/wm+N0Pj+RLc+F9as5idrXEMJuLVT/tSgDb+I /GvSdf8ADOieIpLN9d0u01E2jM8C3MYkVGOMnaeCeB1FakMUcESRQxpHGgwqIMBR6ACgDy39nT/k Trn/ALh3/pnsK9Vryr9nT/kTrn/uHf8ApnsK9VoAK474mJqNvptlq+hWkt3qmnTkxQxIWZxLG8OM f3Q0iOfaPPauxqrq139g0u8vAnmfZ4Xl2Zxu2qTjPbpQB49rvg6+sdP1jQdPsrqbSrHTp7mwKIW3 TSwxwhRx8z5W5Yj/AKaqe9amujV7DWbnS4U8QzaT5gliuRNduFJhUFS8StKw3ZIUOqg7sn7orX8M /ESO/cHVG0ZLcae2oST6fqJuRAqlBslXYu1jv45OdjDHFaN1490yLUrC1hjvJRPJJFKv2OcTwssY cZg8vzCCD1xjFAGT4Etbma4W51q21NtVm0iwmka5jlCeeiMH4bEYkDYOODk596m+Fs2q5vLfVE1O RUggYXV4J4xLId4b93MMo/ClgjNHyNuOc76+MdDd7QR3UsiXQgMcqWsrRfv8eUGkC7ULblwGIPzD 1FNuPF2l+VpbWl3DIdR8p4Q6yLmNpUjycKSrZkACtt5yDjaxAByHiDStQmj+KgisrpjfQQi12xE+ eRaqp2cfNg8cd6p+JYfEthrsljp76s/h9Jt7SyNdzOWaFcKHizKU3K5ODgMQDgECu7t/Gmgzuix3 r/vDGIi9vKqzB5ViVoyVAdS8iDcuQNwJIBzUzeKtIGpQWC3E0l3NNJbpHFbSv88ZQPkqpCqpkTLH C89aAJfCJ1BvC+lnWWZ9RNuhnZk2MWx1K9j6j1zWvRRQAV8y/tkf8fXhT/cuv5xV9NV8y/tkf8fX hT/cuv5xUAfTVFFFABRRRQAUUUUAcr8Kv+SceHP+vKP+VdVXK/Cr/knHhz/ryj/lXVUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5V+zp/wAidc/9w7/0z2Fe q15B8IrLxTpHgvT7jSdN0S+stTstPvEe51SW2kTGn2sJUqtvIOsJOd3Q9K7X7d44/wChe8N/+D6f /wCQ6AOqqrqtp9v0y8sy/li4heLfjO3cpGcfjXP/AG7xx/0L3hv/AMH0/wD8h0fbvHH/AEL3hv8A 8H0//wAh0AY1x8OZtVtI7fxBrEd2lvYvY2/2ayEG1W2cvln342L8vA65B4xb8OeALfRdZt9SiksY pYndmisrBbeNg0ewD7zNkcnJZuvGBV77d44/6F7w3/4Pp/8A5Do+3eOP+he8N/8Ag+n/APkOgDCt vhm0H9mo2rrPFZNZPGZ7Xe8Zt2RgIzvxGrFOQBn5jzjitUeArRbm8mjupB59/b3iqyAiJIpzOYh7 NI8rZ7bwMfKKsfbvHH/QveG//B9P/wDIdH27xx/0L3hv/wAH0/8A8h0AZTfD64ey0+3l1oMNJhjh 0xvsgzEI5oZVMvzfvD/o8anGzjd3ORraB4UfTNaGp3F+Li4P2suFh8tS1w8DHA3HAUwYA54bk8ZK fbvHH/QveG//AAfT/wDyHR9u8cf9C94b/wDB9P8A/IdAHVUVyv27xx/0L3hv/wAH0/8A8h0fbvHH /QveG/8AwfT/APyHQB1VfMv7ZH/H14U/3Lr+cVe4fbvHH/QveG//AAfT/wDyHXm3xf8Ahx4y+JUu lvND4e0r7AsgAXUZrjzN+3/p3TGNvvnPagD3OiiigAooooAKKKKAOV+FX/JOPDn/AF5R/wAq6quV +FX/ACTjw5/15R/yrqqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKRmCqWYgKOpPagBaKbJIkSF5HVEHVmOAKdQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/+SWeDf+wLZf8AohK6quV+E/8AySzwb/2BbL/0 QldVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABQenHWiigD5g1LxX8XtH+H2ip4S8 M2/9lLZx7L+1H22cjb18vjb+KMPeum/Z68U+OdY8EXVzf2K6xc/2hKjz32oGCRCFT5NnlNgD2x1P Fen/AAq/5Jx4c/68o/5V1QABJAAzyfegDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK 6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/t Xxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7 V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCv pv8A4OD/APGK6qigDlf7Z8VJxJ4TgY+sOqow/wDHkU5/Cj+2/E//AEKP/lTi/wAK6qigDlf7b8T/ APQo/wDlTi/wo/tvxP8A9Cj/AOVOL/CuqooA5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AArq qKAOV/tvxP8A9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8K6qigDlf7b8T/8AQo/+VOL/AAo/tvxP/wBC j/5U4v8ACuqooA5X+2/E/wD0KP8A5U4v8K53xbNrHilrXwzqHh4QQ3RN1cxHUEIlt48ZXcqnafMa HtyA3oa9MooA8e0+/t9S1HSJPiIlibSzspbCX7eqtbrqEcgWRiWG0F0CshPZmx1IqrKtxJf6gfC1 ncx+HI9Ms3ubXLx3U1qLq8+SAdVVk3soyDtCqu3dlfa6KAOSt9buLe1to/DXhee+0UQxm0uLS4to 4njKAjarOCAM45A6U/8A4SLX/wDoStS/8DbT/wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf /wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWpf+Btp/8AHaP+Ei1//oStS/8AA20/+O11VFAHK/8A CRa//wBCVqX/AIG2n/x2j/hItf8A+hK1L/wNtP8A47XVUUAcr/wkWv8A/Qlal/4G2n/x2j/hItf/ AOhK1L/wNtP/AI7XVUUAcr/wkWv/APQlal/4G2n/AMdo/wCEi1//AKErUv8AwNtP/jtdVRQByv8A wkmuJzJ4I1hl9IruyZv/AB6dR+tH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf /JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8A JVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/ AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6 d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVTWXiLU7i8hhm8G6/aRuwVp5prEpGP7zBLlmwPYE+1 dJRQByvwn/5JZ4N/7Atl/wCiErqq5X4T/wDJLPBv/YFsv/RCV1VABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCVdVXMfC9PL+Hnh5c5xZR8/hXT0AFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWf4h1H+x9A1PU/K877Fay3 Pl7tu/YhbbnBxnGM4NAGL8J/+SWeDf8AsC2X/ohK6quW+FI2/C7wevXGjWY/8gJXU0AFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAf/9k= ------_=_NextPart_001_01CAD6F6.5BDF3548-- From gao.yang2@zte.com.cn Thu Apr 8 01:59:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB9228C0E3 for ; Thu, 8 Apr 2010 01:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.944 X-Spam-Level: X-Spam-Status: No, score=-97.944 tagged_above=-999 required=5 tests=[AWL=-1.509, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrZW5G8wdDTR for ; Thu, 8 Apr 2010 01:59:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id EA8403A6407 for ; Thu, 8 Apr 2010 01:59:18 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Thu, 8 Apr 2010 16:57:01 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.3690589170; Thu, 8 Apr 2010 16:59:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o388wsYF085998; Thu, 8 Apr 2010 16:59:00 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <0B28F3C8F2581D419709A71814CA59D703533D9C@ZMY16EXM67.ds.mot.com> To: "NAVEEN S-RHVG46" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 8 Apr 2010 16:57:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-08 16:58:49, Serialize complete at 2010-04-08 16:58:49 Content-Type: multipart/related; boundary="=_related 00315087482576FF_=" X-MAIL: mse2.zte.com.cn o388wsYF085998 Cc: sipcore@ietf.org Subject: Re: [sipcore] Need Clarification on UAS behaviour X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:59:22 -0000 This is a multipart message in MIME format. --=_related 00315087482576FF_= Content-Type: multipart/alternative; boundary="=_alternative 0031508A482576FF_=" --=_alternative 0031508A482576FF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGVybWluYXRlIHRoZSBzZXNzaW9uKGNhbGwpLCBhbmQgaXQgaXMgbm9ybWF0aXZlLiBBcyBpbiBS RkMzMjYxJ3MgDQoxMy4zLjEuNDogDQoNCklmIHRoZSBzZXJ2ZXIgcmV0cmFuc21pdHMgdGhlIDJ4 eCByZXNwb25zZSBmb3IgNjQqVDEgc2Vjb25kcyB3aXRob3V0DQogICByZWNlaXZpbmcgYW4gQUNL LCB0aGUgZGlhbG9nIGlzIGNvbmZpcm1lZCwgYnV0IHRoZSBzZXNzaW9uIFNIT1VMRCBiZQ0KICAg dGVybWluYXRlZC4gIFRoaXMgaXMgYWNjb21wbGlzaGVkIHdpdGggYSBCWUUsIGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uDQogICAxNS4NCg0KSWYgdGhlIFVBUyBkbyByZXRyYW5zbWl0dGluZyByaWdo dCBhbmQgdGhlIFVBQyBoYW5kbGUgdGhlIG5leHQgcHJvY2VzcyANCk9LKHN1Y2ggYXMgVUFTIGhh cyBnb3R0ZW4gUmUtSU5WSVRFJ3MgQUNLKSwgbW9zdGx5IHRoZSBVQVMgc2hvdWxkIGdldCB0aGUg DQpJbmktSU5WSVRFJ3MgQUNLLiBCdXQgaWYgaXQgcmVhbGx5IGRpZCBub3QgcmVjZWl2ZSB0aGUg SW5pLUlOVklURSdzIEFDSywgDQp0aGUgVUFTIHNob3VsZCB0ZXJtaW5hdGUgdGhlIGNhbGwuDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQog VGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K DQoNCg0KIk5BVkVFTiBTLVJIVkc0NiIgPG5hdmVlbi5zaGl2YW5uYUBtb3Rvcm9sYS5jb20+IA0K t6K8/sjLOiAgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTA0LTA4IDE2OjM0DQoNCsrV vP7Iyw0KPGdhby55YW5nMkB6dGUuY29tLmNuPiwgPHNpcGNvcmVAaWV0Zi5vcmc+DQqzrcvNDQoN Ctb3zOINClJlOiBbc2lwY29yZV0gTmVlZCBDbGFyaWZpY2F0aW9uIG9uIFVBUyBiZWhhdmlvdXIN Cg0KDQoNCg0KDQoNCkhpLA0KIA0KSWYgd2UgaGFuZGxlIHRoZSBuZXcgcmVxdWVzdCBiZWZvcmUg dGhlIEFDSy4gDQogDQpXaGF0IGlzIHRoZSBiZWhhdmlvdXIgaWYgd2UgZG9uJ3QgcmVjZWl2ZSB0 aGUgQUNLIGZvciB0aGUgZmlyc3QgSU5WSVRFLiANClNob3VsZCB3ZSBjbG9zZSB0aGUgY2FsbCBv ciBzaG91bGQgd2UgcHJvY2VlZCB3aXRoIHRoZSBSZS1JbnZpdGUgb3Igbm90Lg0KIA0KUmVnYXJk cw0KTmF2ZWVuLlMNCg0KRnJvbTogZ2FvLnlhbmcyQHp0ZS5jb20uY24gW21haWx0bzpnYW8ueWFu ZzJAenRlLmNvbS5jbl0gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDgsIDIwMTAgMToyOCBQTQ0K VG86IE5BVkVFTiBTLVJIVkc0Ng0KQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb c2lwY29yZV0gTmVlZCBDbGFyaWZpY2F0aW9uIG9uIFVBUyBiZWhhdmlvdXINCg0KDQpIaSwgDQoN Ckl0IGRlcGVuZHMgb24gaW1wbGVtZW50YXRpb24uIEkga25vdyB0aGVzZSBraW5kcyBvZiBpbXBs ZW1lbnRhdGlvbjogDQoNCjEuIDUwMCArIHJldHJ5IGFmdGVyOyANCjIuIEJ1ZmZlciB0aGUgbmV3 IHJlcXVlc3QsIGFuZCBoYW5kbGUgaXQgYWZ0ZXIgQUNLOyANCjMuIEhhbmRsZSB0aGUgbmV3IHJl cXVlc3QgYmVmb3JlIEFDSywgaWYgdGhlcmUgaXMgbm90IHZpb2xhdGlvbiBvZiBvdGhlciANCnJ1 bGVzKHN1Y2ggYXMgTy9BIHJ1bGVzKS4gDQoNCkFuZCB0aGVyZSdzIG9uZSB2YXJpYXRpb24gb2Yg dGhlIHNlY29uZCBvbmU6IEp1c3QgZGlzY2FyZGluZyB0aGUgbmV3IA0KcmVxdWVzdCwgYW5kIGhh bmRsZSBpdCdzIHJldHJhbnNtaXR0aW5nIGNvcHkgYWZ0ZXIgQUNLLiANCg0KR2FvIA0KDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpUZWwgICAg OiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSANCg0KDQoiTkFW RUVOIFMtUkhWRzQ2IiA8bmF2ZWVuLnNoaXZhbm5hQG1vdG9yb2xhLmNvbT4gDQq3orz+yMs6ICBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEwLTA0LTA4IDEyOjQ3IA0KDQoNCsrVvP7Iyw0K PHNpcGNvcmVAaWV0Zi5vcmc+IA0Ks63LzQ0KDQrW98ziDQpbc2lwY29yZV0gTmVlZCBDbGFyaWZp Y2F0aW9uIG9uIFVBUyBiZWhhdmlvdXINCg0KDQoNCg0KDQoNCg0KDQpIaSwgDQogIA0KSW4gU2Vj dGlvbiAxNC4yIFVBUyBCZWhhdmlvdXIsIHdlIGhhdmUgcmVxdWlyZW1lbnQgc3RhdGluZyBhcyBi ZWxvdyANCiAgDQogICBBIFVBUyB0aGF0IHJlY2VpdmVzIGEgc2Vjb25kIElOVklURSBiZWZvcmUg aXQgc2VuZHMgdGhlIGZpbmFsDQogIHJlc3BvbnNlIHRvIGEgZmlyc3QgSU5WSVRFIHdpdGggYSBs b3dlciBDU2VxIHNlcXVlbmNlIG51bWJlciBvbiB0aGUNCiAgc2FtZSBkaWFsb2cgTVVTVCByZXR1 cm4gYSA1MDAgKFNlcnZlciBJbnRlcm5hbCBFcnJvcikgcmVzcG9uc2UgdG8gdGhlDQogIHNlY29u ZCBJTlZJVEUgYW5kIE1VU1QgaW5jbHVkZSBhIFJldHJ5LUFmdGVyIGhlYWRlciBmaWVsZCB3aXRo IGENCiAgcmFuZG9tbHkgY2hvc2VuIHZhbHVlIG9mIGJldHdlZW4gMCBhbmQgMTAgc2Vjb25kcy4g DQogIA0KQWJvdmUgcmVxdWlyZW1lbnQgaXMgdmFsaWQgd2hlbiB3ZSByZWNlaXZlIElOVklURSwg YmVmb3JlIHNlbmRpbmcgMnh4IA0KcmVzcG9uc2UuLi4gd2UgYXJlIHJlc3BvbmRpbmcgd2l0aCA1 MDAgaW4gb3VyIGltcGxlbWVudGF0aW9uLi4uIA0KIA0KICANCldoYXQncyB0aGUgVUFTIGJlaGF2 aW91ciA/IA0KICANCklmIHdlIHJlY2VpdmUgSU5WSVRFLCBhZnRlciBzZW5kaW5nIGZpbmFsIHJl c3BvbnNlLCBiZWZvcmUgZ2V0dGluZyBBQ0suIA0KIA0KDQogIA0KICANCg0KIA0KUmVnYXJkcywg DQpOYXZlZW4gDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg DQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0u DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29y ZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0031508A482576FF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRlcm1pbmF0ZSB0aGUgc2Vzc2lv bihjYWxsKSwgYW5kIGl0DQppcyBub3JtYXRpdmUuIEFzIGluIFJGQzMyNjEncyA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDIwNDEgZmFjZT0iQ291cmllciBOZXciPjxiPjEzLjMuMS40Og0K PC9iPjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPklm IHRoZSBzZXJ2ZXIgcmV0cmFuc21pdHMgdGhlIDJ4eCByZXNwb25zZQ0KZm9yIDY0KlQxIHNlY29u ZHMgPGI+d2l0aG91dDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48Yj4mbmJzcDsgJm5ic3A7cmVjZWl2aW5nIGFuIEFDSzwvYj4sDQp0aGUgZGlhbG9nIGlz IGNvbmZpcm1lZCwgYnV0IDxiPnRoZSBzZXNzaW9uIFNIT1VMRCBiZTwvYj48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7dGVybWluYXRl ZDwvYj4uICZuYnNwO1RoaXMNCmlzIGFjY29tcGxpc2hlZCB3aXRoIGEgPGI+QllFPC9iPiwgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsgJm5ic3A7MTUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5JZiB0aGUgVUFTIGRvIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPnJldHJhbnNtaXR0aW5nDQpyaWdodCBhbmQgdGhlIFVBQyBoYW5kbGUgdGhl IG5leHQgcHJvY2VzcyBPSyhzdWNoIGFzIFVBUyBoYXMgZ290dGVuIFJlLUlOVklURSdzDQpBQ0sp LCBtb3N0bHkgdGhlIFVBUyBzaG91bGQgZ2V0IHRoZSBJbmktSU5WSVRFJ3MgQUNLLiBCdXQgaWYg aXQgcmVhbGx5DQpkaWQgbm90IHJlY2VpdmUgdGhlIEluaS1JTlZJVEUncyBBQ0ssIHRoZSBVQVMg c2hvdWxkIHRlcm1pbmF0ZSB0aGUgY2FsbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3 MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj4mcXVvdDtOQVZFRU4gUy1SSFZHNDYmcXVvdDsNCiZsdDtuYXZlZW4uc2hpdmFubmFAbW90b3Jv bGEuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij63orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA0LTA4IDE2OjM0PC9mb250Pg0KPHRkIHdp ZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtnYW8ueWFuZzJA enRlLmNvbS5jbiZndDssICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBO ZWVkIENsYXJpZmljYXRpb24gb24NClVBUyBiZWhhdmlvdXI8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ SGksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPklmIHdlIGhhbmRs ZSB0aGUgbmV3IHJlcXVlc3QgYmVmb3JlDQp0aGUgQUNLLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+V2hhdCBpcyB0aGUgYmVoYXZpb3VyIGlmIHdlIGRvbid0DQpy ZWNlaXZlIHRoZSBBQ0sgZm9yIHRoZSBmaXJzdCBJTlZJVEUuIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+U2hvdWxkIHdlIGNsb3NlIHRoZSBjYWxsIG9y IHNob3VsZA0Kd2UgcHJvY2VlZCB3aXRoIHRoZSBSZS1JbnZpdGUgb3Igbm90LjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5SZWdhcmRzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5OYXZlZW4uUzwvZm9udD4NCjxicj4NCjxi cj4NCjxocj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gZ2FvLnlhbmcy QHp0ZS5jb20uY24gW21haWx0bzpnYW8ueWFuZzJAenRlLmNvbS5jbl0NCjxiPjxicj4NClNlbnQ6 PC9iPiBUaHVyc2RheSwgQXByaWwgMDgsIDIwMTAgMToyOCBQTTxiPjxicj4NClRvOjwvYj4gTkFW RUVOIFMtUkhWRzQ2PGI+PGJyPg0KQ2M6PC9iPiBzaXBjb3JlQGlldGYub3JnPGI+PGJyPg0KU3Vi amVjdDo8L2I+IFJlOiBbc2lwY29yZV0gTmVlZCBDbGFyaWZpY2F0aW9uIG9uIFVBUyBiZWhhdmlv dXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGksPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpJdCBkZXBlbmRzIG9uIGltcGxlbWVudGF0aW9uLiBJIGtub3cgdGhl c2Uga2luZHMgb2YgaW1wbGVtZW50YXRpb246PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KMS4gNTAwICsgcmV0cnkgYWZ0ZXI7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQoyLiBCdWZm ZXIgdGhlIG5ldyByZXF1ZXN0LCBhbmQgaGFuZGxlIGl0IGFmdGVyIEFDSzs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQozLiBIYW5kbGUgdGhlIG5ldyByZXF1ZXN0IGJlZm9yZSBBQ0ssIGlmIHRo ZXJlIGlzIG5vdCB2aW9sYXRpb24gb2Ygb3RoZXINCnJ1bGVzKHN1Y2ggYXMgTy9BIHJ1bGVzKS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFuZCB0aGVyZSdzIG9uZSB2YXJpYXRpb24g b2YgdGhlIHNlY29uZCBvbmU6IEp1c3QgZGlzY2FyZGluZyB0aGUgbmV3IHJlcXVlc3QsDQphbmQg aGFuZGxlIGl0J3MgcmV0cmFuc21pdHRpbmcgY29weSBhZnRlciBBQ0suPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KR2FvPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NClppcCAmbmJzcDsgJm5ic3A7OiAy MTAwMTI8YnI+DQpUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQpUZWwyICZuYnNwOyA6KCs4 NiktMDI1LTUyODc3MjExPGJyPg0KZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUyJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+JnF1b3Q7TkFWRUVOIFMtUkhWRzQ2JnF1b3Q7DQombHQ7bmF2ZWVuLnNoaXZhbm5h QG1vdG9yb2xhLmNvbSZndDs8L2I+IDxicj4NCreivP7IyzogJm5ic3A7c2lwY29yZS1ib3VuY2Vz QGlldGYub3JnPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA0LTA4IDEyOjQ3PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD00NyU+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEx JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD04OCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPltzaXBjb3JlXSBOZWVkIENsYXJpZmljYXRpb24gb24gVUFTDQpiZWhhdmlv dXI8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkhpLDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48YnI+DQpJbiBTZWN0aW9uIDE0LjIgVUFTIEJlaGF2aW91ciwgd2UgaGF2ZSBy ZXF1aXJlbWVudCBzdGF0aW5nIGFzIGJlbG93PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 Yj48YnI+DQogJm5ic3A7IEEgVUFTIHRoYXQgcmVjZWl2ZXMgYSBzZWNvbmQgSU5WSVRFIGJlZm9y ZSBpdCBzZW5kcyB0aGUgZmluYWw8YnI+DQogJm5ic3A7cmVzcG9uc2UgdG8gYSBmaXJzdCBJTlZJ VEUgd2l0aCBhIGxvd2VyIENTZXEgc2VxdWVuY2UgbnVtYmVyIG9uDQp0aGU8YnI+DQogJm5ic3A7 c2FtZSBkaWFsb2cgTVVTVCByZXR1cm4gYSA1MDAgKFNlcnZlciBJbnRlcm5hbCBFcnJvcikgcmVz cG9uc2UgdG8NCnRoZTxicj4NCiAmbmJzcDtzZWNvbmQgSU5WSVRFIGFuZCBNVVNUIGluY2x1ZGUg YSBSZXRyeS1BZnRlciBoZWFkZXIgZmllbGQgd2l0aCBhPGJyPg0KICZuYnNwO3JhbmRvbWx5IGNo b3NlbiB2YWx1ZSBvZiBiZXR3ZWVuIDAgYW5kIDEwIHNlY29uZHMuPC9iPjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KQWJvdmUgcmVxdWlyZW1lbnQgaXMgdmFsaWQgd2hlbiB3ZSBy ZWNlaXZlIElOVklURSwgYmVmb3JlIHNlbmRpbmcgMnh4IHJlc3BvbnNlLi4uDQp3ZSBhcmUgcmVz cG9uZGluZyB3aXRoIDUwMCBpbiBvdXIgaW1wbGVtZW50YXRpb24uLi48L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KICZuYnNwOzxicj4NCiAmbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpXaGF0J3MgdGhlIFVBUyBiZWhhdmlvdXIg PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJBcmlhbCI+PGJyPg0KSWYgd2UgcmVjZWl2 ZSBJTlZJVEUsIGFmdGVyIHNlbmRpbmcgZmluYWwgcmVzcG9uc2UsIGJlZm9yZSBnZXR0aW5nIEFD Sy4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOzxi cj4NCjwvZm9udD48aW1nIHNyYz1jaWQ6XzJfMDk5NzNFRTQwOTk2RjlFODAwMzE1MDc3NDgyNTc2 RkY+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 Yj48YnI+DQogPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 PGJyPg0KPGJyPg0KICZuYnNwOzxicj4NClJlZ2FyZHMsIDxicj4NCk5hdmVlbiA8YnI+DQogPC9m b250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5v cmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2Zv bnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTM+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMg ZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIGludGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KPC9mb250 PjwvdHQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv cHJlPg== --=_alternative 0031508A482576FF_=-- --=_related 00315087482576FF_= Content-Type: image/jpeg Content-ID: <_2_09973EE40996F9E800315077482576FF> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCADNAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD134d+ CPDOpeBtEvb/AESxuLue1SSWaSMMzsRySe5rov8AhXfhD/oXNN/78ij4Vf8AJOPDn/XlH/KuqoA5 X/hXfhD/AKFzTf8AvyKP+Fd+EP8AoXNN/wC/IrqqKAOV/wCFd+EP+hc03/vyKP8AhXfhD/oXNN/7 8it7VNUs9LW2a/m8oXNwlrEdpO6RzhV4HGT3PFRXWt6fatqS3FyEOnW4urrKt+7iIchunPEb9Mni gDG/4V34Q/6FzTf+/Io/4V34Q/6FzTf+/IrSn8S6VDo1lqrXLNZ3oQ2xjheR5iy7lCRqC7NtBO0D IAORwataPqtnrFobiwlZ0VzG6vG0bxuOqujgMrdDggHBB7igDD/4V34Q/wChc03/AL8ij/hXfhD/ AKFzTf8AvyK6qigDlf8AhXfhD/oXNN/78ij/AIV34Q/6FzTf+/IrqqKAOW+FTFvhn4VZiWY6Zb5J OSf3a11Ncr8KP+SZeFf+wZb/APota6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKzPFOrroHhnV9Zki MyadZzXbRK20uI0L7Qe2cYoA06K5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK P7V8X/8AQr6b/wCDg/8AxigDqqK5X+1fF/8A0K+m/wDg4P8A8Yo/tXxf/wBCvpv/AIOD/wDGKAOq orlf7V8X/wDQr6b/AODg/wDxij+1fF//AEK+m/8Ag4P/AMYoA6qiuV/tXxf/ANCvpv8A4OD/APGK o654o8T6Jo17ql94XsfslnC88vl6sWbYoycDyRk4HrQB3FFFFABRRRQAUUUUAFFFFAHK/Cr/AJJx 4c/68o/5V1Vcr8Kv+SceHP8Aryj/AJV1VABRRRQBzXj7S7nU9KsnsYWuLiw1C2v1gVlUyiOQMygs QMld2MkDOMkVzOo6NrviDU72cafJplnqctnDKLpopHSC382UsyI5BDuyR7QxO0sTivS6KAPMbTw/ r+jaxaXJtX1O00q+uZYEt2jiM0N0m59qM+A0cu4AEj5G4PGK7rQJr64ju7jUdOXTjJOTFCWVpSgV VDSlCV3Eg9CcLtGc5rUooAKKKKACiiigDlfhR/yTLwr/ANgy3/8ARa11Vcr8KP8AkmXhX/sGW/8A 6LWuqoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACuV+LH/JLPGX/YFvf/RD11Vcr8WP+SWeMv8AsC3v/oh6 AOqooooAKKKKACiuQ8dyxWOseEdTvZo7ewtNRk8+eQ7UiD2s6KWPQDcyrk92FcXqU8Xii81rR9Nj fUtP1jVjdStayqoltYLS1RikhIH+vCLkdQr46UAex0V4rqOoWmtWukS+JLnRItVsbeayurXxDGDZ yXEbhZGjkyAkvyhsgMdkgwOpr0/wROLnwho8qwT26m1jAjnlMrgAYGXIBbOM7iASDnA6UAbdFFFA BXK/Ff8A5Jl4q/7Blx/6Lauqrlfiv/yTLxV/2DLj/wBFtQB1VFFFABRRRQAUUUUAFFFFAHnfgvV9 T0HwppelXnhLX3uLOBYZGiW3ZCRxlT5oyK2v+Etu/wDoUPEn/fu3/wDj1dVRQByv/CW3f/QoeJP+ /dv/APHqP+Etu/8AoUPEn/fu3/8Aj1dVRQByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t/ /j1dVRQByv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PVd8Canc6z4N0fUb5la6ubZ JJCq4BYjnjtW7QByv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6FDxJ/37t//j1dVRQByv8Awlt3/wBC h4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PV1VFAHPfDuwudL8BeHbC/hMF3bWEEU0RIJRwgBGRkc H0roaKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigArlfix/ySzxl/2Bb3/0Q9dVXP8AxEsLnVfh/wCJtOsI jNeXel3VvBGCBvd4mVRk8DJI60AdBRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/AH7t/wD4 9QB1VFcr/wAJbd/9Ch4k/wC/dv8A/HqP+Etu/wDoUPEn/fu3/wDj1AHVEAggjIPagAAAAYA7Vyv/ AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ8Sf9+7f/AOPUAdUQGGCAR15orlf+Etu/+hQ8Sf8Afu3/ APj1H/CW3f8A0KHiT/v3b/8Ax6gDqqK5X/hLbv8A6FDxJ/37t/8A49R/wlt3/wBCh4k/792//wAe oA6quV+K/wDyTLxV/wBgy4/9FtR/wlt3/wBCh4k/792//wAerE8bavqeveD9a0my8JeIFub6zlt4 mlW3VAzqQCx87gZNAHotFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCV dVXmHw28T3Vv4C0GFfC2vzqloiiWJICj8dRmUHH1Arpf+Etu/wDoUPEn/fu3/wDj1AHVUVyv/CW3 f/QoeJP+/dv/APHqP+Etu/8AoUPEn/fu3/8Aj1AHVUVyv/CW3f8A0KHiT/v3b/8Ax6j/AIS27/6F DxJ/37t//j1AHVUVyv8Awlt3/wBCh4k/792//wAeo/4S27/6FDxJ/wB+7f8A+PUAdVRXK/8ACW3f /QoeJP8Av3b/APx6j/hLbv8A6FDxJ/37t/8A49QB1VFcr/wlt3/0KHiT/v3b/wDx6j/hLbv/AKFD xJ/37t//AI9QB1VFcr/wlt3/ANCh4k/792//AMeo/wCEtu/+hQ8Sf9+7f/49QB1VFcr/AMJbd/8A QoeJP+/dv/8AHqP+Etu/+hQ8Sf8Afu3/APj1AHVUVyv/AAlt3/0KHiT/AL92/wD8eo/4S27/AOhQ 8Sf9+7f/AOPUAdVRXK/8Jbd/9Ch4k/792/8A8eo/4S27/wChQ8Sf9+7f/wCPUAdVRXK/8Jbd/wDQ oeJP+/dv/wDHqP8AhLbv/oUPEn/fu3/+PUAdVRXK/wDCW3f/AEKHiT/v3b//AB6j/hLbv/oUPEn/ AH7t/wD49QB1VFeeeNPFV5J4O15B4Z8Q2pbT7gCeRYAsX7tvmJWUkAdeATXK+Jb/AFLR9O8fauLi 4m0ySP7FcRhiTbMdOtzFOnoN8hV8f3lb+E0Ae20V5hdS3NvPceFUlm3a7LDcW8m85jgkUm7AJ6Ee VI2R0M6Vn6xpVnf+GbS8ukke5Pid7PzPNdT5LavIpTg9NrEfSgD1+ivEX06xi8f+KLJrPR5rS1e1 SFNR1qW0MSm3QkIoR9wzzkkc16Ve+Jrm2u5oU8Ma/cpGxUTQpAUceq5lBx9QKAOkorlf+Etu/wDo UPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k /wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ /wB+7f8A+PUf8Jbd/wDQoeJP+/dv/wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v 3b//AB6gDqqK5X/hLbv/AKFDxJ/37t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUP En/fu3/+PUf8Jbd/9Ch4k/792/8A8eoA6qiuV/4S27/6FDxJ/wB+7f8A+PUf8Jbd/wDQoeJP+/dv /wDHqAOqorlf+Etu/wDoUPEn/fu3/wDj1H/CW3f/AEKHiT/v3b//AB6gDqqK5X/hLbv/AKFDxJ/3 7t//AI9R/wAJbd/9Ch4k/wC/dv8A/HqAOqorlf8AhLbv/oUPEn/fu3/+PUf8Jbd/9Ch4k/792/8A 8eoA6qo7mCK6t5be4jWWCVCkiMMhlIwQR6EV4J8ePi/4j8G2+hXWi6Pd6f5s0izR6rBE0c4ABAGy QsCOehHWt74QfF3WPHQhS+8D6tao/H9oQYNqffdJtwPZS5/OgDufhW7y/DDwfJIzO7aPZszMckkw Jkk11Fcr8J/+SWeDf+wLZf8AohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDlfhV/yTjw5/15R/yrqq5X4Vf8k48Of9eUf8q6qgAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKCQOpxQA2WNJY3jlRXjcFWVhkMD1BFMNvAUmQwxlZv9aCow/AX5vXg Ac9hUm4btuRuxnHfFLQAwwxmVJTGhkQFVcqMqDjIB7A4H5Cm/ZoPL8vyYtm/zNuwY37t27Hru5z6 81LRQBQutG0u7naa702ynmbGZJYFZjjjkkVfHA4oooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigCjqWj6Zqk1tLqWn2l5JasWgaeFZDEx6lcjg8dRV6iigDlfhP/yS zwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigD53vPE/xR0b4b6EvgrwpaXlkLKPF7HKbmbp1EHykH8HFQfs7eNPiDr0vih9Ztm1 a7hmhVo766+x/Zsh+FjERAz34HQda9l+FX/JOPDn/XlH/Kup2jcWwNxGCe/+eaAOW/tXxf8A9Cvp v/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A 8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xi j+1fF/8A0K+m/wDg4P8A8YrqqKAOV/tXxf8A9Cvpv/g4P/xij+2vFK8P4SjZh1MeqRlfwJUH9BXV UUAcr/bfif8A6FH/AMqcX+FH9t+J/wDoUf8Aypxf4V1VFAHK/wBt+J/+hR/8qcX+FH9t+J/+hR/8 qcX+FdVRQByv9t+J/wDoUf8Aypxf4Uf234n/AOhR/wDKnF/hXVUUAcr/AG34n/6FH/ypxf4Uf234 n/6FH/ypxf4V1VFAHK/234n/AOhR/wDKnF/hR/bfif8A6FH/AMqcX+FdVRQByv8Abfif/oUf/KnF /hWT4qGo6ppdhc6rp9xpklpq+nGOGO8EiTZvIAWcL12jOAeOc9QCPQKKAPFdZWX/AITu+u7Brb+2 k1NlhsxEPtzJ9j8tZBIT/wAe+SG2bcZH3s/LXQfDF7A6tENAeBrQ6NbNf+QwP+lFm5k7+aRv3Z+b pu7V6VRQB4B4M0yS10/w3qNxZaTY2M2ryb9Wt7c/bAwuZAkcr8YSQ/u93IwwGOcjf8Ha5rdxpNlN Hfpb29qdJj+yR2saxutwyJID8uRgNldpGD1yOB7BRQB4jqni3U7m3hSTVoLuWexluNQ0t7WJhYTL cQKsZG3I272XD5JK544rZk8SeI7fTH1Jb77R541BRA1shW3ENyI0kXaAx2puZgSc9sV3umeHNP02 /wDtluLlpljeGPzrmSVYkZgzKgYkKCVXp/dA6AVo39pDf2c1rcqzQyqUYK5Q49mBBB9wQRQBwXh/ xLqr6hrcentP4ssbeWFLee3e2j2ho9zZfKI/Jx8vTp1zW1/wkWv/APQlal/4G2n/AMdra0bR7XSF uPsvnPJcyedNLPM0ryNtCglmJPCqoA6DFaFAHK/8JFr/AP0JWpf+Btp/8do/4SLX/wDoStS/8DbT /wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf/wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWp f+Btp/8AHaP+El1tP9Z4H1t89PJurFsfXdcL+ma6qigDlf8AhKNX/wChE8Sf9/8ATv8A5Ko/4SjV /wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9/wDTv/kquqoo A5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKNX/wChE8Sf9/8A Tv8A5Ko/4SjV/wDoRPEn/f8A07/5KrqqKAOV/wCEo1f/AKETxJ/3/wBO/wDkqj/hKNX/AOhE8Sf9 /wDTv/kquqooA5X/AISjV/8AoRPEn/f/AE7/AOSqP+Eo1f8A6ETxJ/3/ANO/+Sq6qigDlf8AhKtT XmXwR4kjX132L/olyT+lH/CW3f8A0KHiT/v3b/8Ax6uqooA5X/hLbv8A6FDxJ/37t/8A49Tk8V3b uq/8Ij4jXJxlkt8D6/vq6iigDlfhP/ySzwb/ANgWy/8ARCV1Vcr8J/8Aklng3/sC2X/ohK6qgAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiimTGQQuYVR5QDtV22gnsCQDge+DQBzHwq/ 5Jx4c/68o/5V1VfI2teNvjFovgPSY9D0BbLREtE8vULKEXcjJj7zHkJ+KDHrXrXwZ8R+M9T+GWh3 k2lW+qyTRyM15daqUklPmPyy+U2MdMZPAFAHr9Fcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDB wf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bw f/jFH9q+L/8AoV9N/wDBwf8A4xQB1VFcr/avi/8A6FfTf/Bwf/jFH9q+L/8AoV9N/wDBwf8A4xQB 1VFcr/avi/8A6FfTf/Bwf/jFH9r+LE5k8K2jD0h1YMf/AB6NRj8aAOqorlf7b8T/APQo/wDlTi/w o/tvxP8A9Cj/AOVOL/CgDqqK5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AAoA6qiuV/tvxP8A 9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8KAOqorlf7b8T/8AQo/+VOL/AAo/tvxP/wBCj/5U4v8ACgDq qK5X+2/E/wD0KP8A5U4v8KP7b8T/APQo/wDlTi/woA6qiuV/tvxP/wBCj/5U4v8ACj+2/E//AEKP /lTi/wAKAOpZgoyxAGQOT3PSlryvxxrlpizTxhoGn29++9NOj1K7jmtckDzJZBjA2AKBwWO8hcZY jGsYra1uIYbK9ivfE8Oo2MOnXLupuZ7EW0G91ycmJk85m/hzuz8woA9toryz4WNZnUtKOkNCXbQ0 fWvJILfbS0e0z9/N/wBfnd83Bz0FZup/2L/YniNtUe3/AOE+Fzd/ZPm/04Sea32QQA/PsK+Tjb8p Gc/xUAey0V4zo4vBfrN4oihk8Mf25exhEJKx3JuWMcs4PBTflFHRW2Mc5GzvT4h18EgeC9SI9ftt p/8AHaAOporlf+Ei1/8A6ErUv/A20/8AjtH/AAkWv/8AQlal/wCBtp/8doA6qiuV/wCEi1//AKEr Uv8AwNtP/jtH/CRa/wD9CVqX/gbaf/HaAOqorlf+Ei1//oStS/8AA20/+O0f8JFr/wD0JWpf+Btp /wDHaAOqorlf+Ei1/wD6ErUv/A20/wDjtH/CRa//ANCVqX/gbaf/AB2gDqqK5X/hItf/AOhK1L/w NtP/AI7R/wAJJricyeCNYZfSK7smb/x6dR+tAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/wlGr/wDQ ieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUAdVRXK/8A CUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+nf8AyVR/ wlGr/wDQieJP+/8Ap3/yVQB1VFcr/wAJRq//AEIniT/v/p3/AMlUf8JRq/8A0IniT/v/AKd/8lUA dVRXK/8ACUav/wBCJ4k/7/6d/wDJVH/CUav/ANCJ4k/7/wCnf/JVAHVUVyv/AAlGr/8AQieJP+/+ nf8AyVVzSdd1G+vkguvCutadEwJNxdS2bRrgdCI53bnpwp/CgCn8J/8Aklng3/sC2X/ohK6quV+E /wDySzwb/wBgWy/9EJXVUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8Kv+ SceHP+vKP+VdSqhRhQAMk8e9ct8Kv+SceHP+vKP+VdVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRgZzjn1oooAAAM4HXrRgbgcDI4zRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/wDklng3/sC2X/ohK6qv Efgh4U8Pa/4Yludd0HSdTuI49OiSW8s45nVBpNidoLAkDLMcdMk+teif8K48D/8AQm+G/wDwVwf/ ABNAHVUVyv8AwrjwP/0Jvhv/AMFcH/xNRP4A8ApcRW7+E/CyzyhmjjOm24ZwuNxA25IGRn0yKAOv orhT4T+GYskvDoHg0WcjOiT/AGK28tmXduAbbgkbHyO21vQ1of8ACuPA/wD0Jvhv/wAFcH/xNAHV UVx0/gP4f27os/hXwrEzsqKH063UszZwBleScHA9jUzfDrwMqlm8HeGgoGSTpcAAH/fNAHV0V5rb 6b8HrmXy7ez+H8sm1m2xxWbHABJOAOgAJPsK6D/hXHgf/oTfDf8A4K4P/iaAOqorlf8AhXHgf/oT fDf/AIK4P/iaP+FceB/+hN8N/wDgrg/+JoA6qiuV/wCFceB/+hN8N/8Agrg/+Jr5/wD2ptD0nwzc +Gx4b0ux0gXCXBmFhbpb+ZtMe3dsAzjJxnpk0AfVVFFFABRRRQAUUUUAeYfDbxX9m8BaFB/YOvze XaIvmRWe5G46g55FdL/wmX/UueJf/AH/AOyo+FX/ACTjw5/15R/yrqqAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL /qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyr qqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9 S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8S/8A gD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/h Mv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8A AH/7KuqooA8/8XeM5h4T1s22i+I7ScWM5juGtNgiby2w5YNxg857VzPiDXtX0S08canLf3T6UU+x qfMbOnzf2fC8UqH+FWkkKt6MUP8AeNex3EMVxBJBcRpLDIpR43UMrqRggg9QR2qB9NsXt7qB7K2a C7/4+IzEpWb5QnzjGG+VVXnsAOgoA8+udQv4GvPDIvLr7dq00D2M5mJkjt5lJnKtnIMYinZfTdGB jiqerQSXfhq0vZNR1dLk+JXsC0Op3EQMB1V4yhCOAfkO0HGQAACMDHp7WVo1zBctbQG4gRo4ZTGN 8atjcFPUA4GQPQU06dZGAQmztjCs32gIYl2iXf5nmYx97f8ANnru560AeVRWV9N448TWFvba7qVl YvaxwhfEdzb+SGgViD+8y5JJOTk13d74q+yXk1v/AGDr83lsV8yGz3I2O6nPIq1qfhPw7qt493qe gaReXTgBprizjkdsDAyzKScDitlVCqFUAKBgADAAoA5b/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/ AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8A CZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54l/8AAH/7KuqooA5X/hMv+pc8 S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZUf8Jl/wBS54l/8Af/ALKuqooA 5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA5X/AITL/qXPEv8A4A//AGVH/CZf9S54 l/8AAH/7KuqooA5X/hMv+pc8S/8AgD/9lR/wmX/UueJf/AH/AOyrqqKAOV/4TL/qXPEv/gD/APZU f8Jl/wBS54l/8Af/ALKuqooA5X/hMv8AqXPEv/gD/wDZUf8ACZf9S54l/wDAH/7KuqooA8I+Nnxn 1fwVBotzo+iXEaTyyJPHqtq0ayKACNhDZBHP+Fa/wm+N0Pj+RLc+F9as5idrXEMJuLVT/tSgDb+I /GvSdf8ADOieIpLN9d0u01E2jM8C3MYkVGOMnaeCeB1FakMUcESRQxpHGgwqIMBR6ACgDy39nT/k Trn/ALh3/pnsK9Vryr9nT/kTrn/uHf8ApnsK9VoAK474mJqNvptlq+hWkt3qmnTkxQxIWZxLG8OM f3Q0iOfaPPauxqrq139g0u8vAnmfZ4Xl2Zxu2qTjPbpQB49rvg6+sdP1jQdPsrqbSrHTp7mwKIW3 TSwxwhRx8z5W5Yj/AKaqe9amujV7DWbnS4U8QzaT5gliuRNduFJhUFS8StKw3ZIUOqg7sn7orX8M /ESO/cHVG0ZLcae2oST6fqJuRAqlBslXYu1jv45OdjDHFaN1490yLUrC1hjvJRPJJFKv2OcTwssY cZg8vzCCD1xjFAGT4Etbma4W51q21NtVm0iwmka5jlCeeiMH4bEYkDYOODk596m+Fs2q5vLfVE1O RUggYXV4J4xLId4b93MMo/ClgjNHyNuOc76+MdDd7QR3UsiXQgMcqWsrRfv8eUGkC7ULblwGIPzD 1FNuPF2l+VpbWl3DIdR8p4Q6yLmNpUjycKSrZkACtt5yDjaxAByHiDStQmj+KgisrpjfQQi12xE+ eRaqp2cfNg8cd6p+JYfEthrsljp76s/h9Jt7SyNdzOWaFcKHizKU3K5ODgMQDgECu7t/Gmgzuix3 r/vDGIi9vKqzB5ViVoyVAdS8iDcuQNwJIBzUzeKtIGpQWC3E0l3NNJbpHFbSv88ZQPkqpCqpkTLH C89aAJfCJ1BvC+lnWWZ9RNuhnZk2MWx1K9j6j1zWvRRQAV8y/tkf8fXhT/cuv5xV9NV8y/tkf8fX hT/cuv5xUAfTVFFFABRRRQAUUUUAcr8Kv+SceHP+vKP+VdVXK/Cr/knHhz/ryj/lXVUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5V+zp/wAidc/9w7/0z2Fe q15B8IrLxTpHgvT7jSdN0S+stTstPvEe51SW2kTGn2sJUqtvIOsJOd3Q9K7X7d44/wChe8N/+D6f /wCQ6AOqqrqtp9v0y8sy/li4heLfjO3cpGcfjXP/AG7xx/0L3hv/AMH0/wD8h0fbvHH/AEL3hv8A 8H0//wAh0AY1x8OZtVtI7fxBrEd2lvYvY2/2ayEG1W2cvln342L8vA65B4xb8OeALfRdZt9SiksY pYndmisrBbeNg0ewD7zNkcnJZuvGBV77d44/6F7w3/4Pp/8A5Do+3eOP+he8N/8Ag+n/APkOgDCt vhm0H9mo2rrPFZNZPGZ7Xe8Zt2RgIzvxGrFOQBn5jzjitUeArRbm8mjupB59/b3iqyAiJIpzOYh7 NI8rZ7bwMfKKsfbvHH/QveG//B9P/wDIdH27xx/0L3hv/wAH0/8A8h0AZTfD64ey0+3l1oMNJhjh 0xvsgzEI5oZVMvzfvD/o8anGzjd3ORraB4UfTNaGp3F+Li4P2suFh8tS1w8DHA3HAUwYA54bk8ZK fbvHH/QveG//AAfT/wDyHR9u8cf9C94b/wDB9P8A/IdAHVUVyv27xx/0L3hv/wAH0/8A8h0fbvHH /QveG/8AwfT/APyHQB1VfMv7ZH/H14U/3Lr+cVe4fbvHH/QveG//AAfT/wDyHXm3xf8Ahx4y+JUu lvND4e0r7AsgAXUZrjzN+3/p3TGNvvnPagD3OiiigAooooAKKKKAOV+FX/JOPDn/AF5R/wAq6quV +FX/ACTjw5/15R/yrqqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKRmCqWYgKOpPagBaKbJIkSF5HVEHVmOAKdQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcr8J/+SWeDf+wLZf8AohK6quV+E/8AySzwb/2BbL/0 QldVQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABQenHWiigD5g1LxX8XtH+H2ip4S8 M2/9lLZx7L+1H22cjb18vjb+KMPeum/Z68U+OdY8EXVzf2K6xc/2hKjz32oGCRCFT5NnlNgD2x1P Fen/AAq/5Jx4c/68o/5V1QABJAAzyfegDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK 6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/t Xxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7 V8X/APQr6b/4OD/8Yo/tXxf/ANCvpv8A4OD/APGK6qigDlf7V8X/APQr6b/4OD/8Yo/tXxf/ANCv pv8A4OD/APGK6qigDlf7Z8VJxJ4TgY+sOqow/wDHkU5/Cj+2/E//AEKP/lTi/wAK6qigDlf7b8T/ APQo/wDlTi/wo/tvxP8A9Cj/AOVOL/CuqooA5X+2/E//AEKP/lTi/wAKP7b8T/8AQo/+VOL/AArq qKAOV/tvxP8A9Cj/AOVOL/Cj+2/E/wD0KP8A5U4v8K6qigDlf7b8T/8AQo/+VOL/AAo/tvxP/wBC j/5U4v8ACuqooA5X+2/E/wD0KP8A5U4v8K53xbNrHilrXwzqHh4QQ3RN1cxHUEIlt48ZXcqnafMa HtyA3oa9MooA8e0+/t9S1HSJPiIlibSzspbCX7eqtbrqEcgWRiWG0F0CshPZmx1IqrKtxJf6gfC1 ncx+HI9Ms3ubXLx3U1qLq8+SAdVVk3soyDtCqu3dlfa6KAOSt9buLe1to/DXhee+0UQxm0uLS4to 4njKAjarOCAM45A6U/8A4SLX/wDoStS/8DbT/wCO11VFAHK/8JFr/wD0JWpf+Btp/wDHaP8AhItf /wChK1L/AMDbT/47XVUUAcr/AMJFr/8A0JWpf+Btp/8AHaP+Ei1//oStS/8AA20/+O11VFAHK/8A CRa//wBCVqX/AIG2n/x2j/hItf8A+hK1L/wNtP8A47XVUUAcr/wkWv8A/Qlal/4G2n/x2j/hItf/ AOhK1L/wNtP/AI7XVUUAcr/wkWv/APQlal/4G2n/AMdo/wCEi1//AKErUv8AwNtP/jtdVRQByv8A wkmuJzJ4I1hl9IruyZv/AB6dR+tH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf /JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8A JVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/ AOnf/JVH/CUav/0IniT/AL/6d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVH/CUav/0IniT/AL/6 d/8AJVdVRQByv/CUav8A9CJ4k/7/AOnf/JVTWXiLU7i8hhm8G6/aRuwVp5prEpGP7zBLlmwPYE+1 dJRQByvwn/5JZ4N/7Atl/wCiErqq5X4T/wDJLPBv/YFsv/RCV1VABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAHK/Cr/knHhz/AK8o/wCVdVXMfC9PL+Hnh5c5xZR8/hXT0AFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWf4h1H+x9A1PU/K877Fay3 Pl7tu/YhbbnBxnGM4NAGL8J/+SWeDf8AsC2X/ohK6quW+FI2/C7wevXGjWY/8gJXU0AFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAf/9k= --=_related 00315087482576FF_=-- From christer.holmberg@ericsson.com Thu Apr 8 02:47:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A1928C11A for ; Thu, 8 Apr 2010 02:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6WPI8lAdMgm for ; Thu, 8 Apr 2010 02:47:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7121028C101 for ; Thu, 8 Apr 2010 02:47:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-cd-4bbda612489c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D9.9B.23532.216ADBB4; Thu, 8 Apr 2010 11:46:58 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 8 Apr 2010 11:46:57 +0200 From: Christer Holmberg To: Hadriel Kaplan , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Thu, 8 Apr 2010 11:46:56 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAACPuvQABgDy5ACORmbAAKZ9ZcA== Message-ID: References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, , , <430FC6BDED356B4C8498F634416644A91A79F3CFD1@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CFD1@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:47:04 -0000 Hi, >>>Why not just send the INVITE and see if it fails? In the most=20 >>>common case (success), that saves one round-trip. >>=20 >>Because that is crappy protocol design. And, the INVITE might trigger=20 >>different resources etc to be reserved, so you don't want to keep=20 >>sending those. >=20 >What's so crappy about using an INVITE to say you want to=20 >start a session? A failure of an INVITE request isn't a=20 >protocol failure or error condition (unless the response code=20 >is an error condition type). =20 >=20 >What's next, we need an OPTIONS before the OPTIONS to make=20 >sure the second OPTIONS won't fail?? ;) >=20 >Sure the INVITE might trigger resources reservation - that's=20 >GOOD, because it verifies the resources are available - if=20 >those resources aren't available the request will fail,=20 >whereas for an OPTIONS it wouldn't have. The resources will be released when the first INVITE is rejected, and a new= resource reservation procedure will start when the next INVITE comes. Regards, Christer From christer.holmberg@ericsson.com Thu Apr 8 03:12:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD0B3A6935 for ; Thu, 8 Apr 2010 03:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.315 X-Spam-Level: X-Spam-Status: No, score=-5.315 tagged_above=-999 required=5 tests=[AWL=1.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsZ43fAtdZQi for ; Thu, 8 Apr 2010 03:12:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A31753A68D3 for ; Thu, 8 Apr 2010 03:12:41 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-da-4bbdac14e0b3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id EB.8F.23532.41CADBB4; Thu, 8 Apr 2010 12:12:37 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 8 Apr 2010 12:12:36 +0200 From: Christer Holmberg To: "Elwell, John" , Hans Erik van Elburg Date: Thu, 8 Apr 2010 12:12:34 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5AAAL6EcAAq+I2A Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:12:45 -0000 Hi, =20 >[JRE] But even if you then target the INVITE request at the=20 >GRUU of the preferred user, there is no guarantee it will=20 >succeed (e.g., no media resources, UA has become busy in the=20 >meantime), and because it is targeted directly, you lose the=20 >opportunity to take alternative action, e.g., forwarding to=20 >voicemail or to another UA with similar capabilities. It is a=20 >case of the calling user trying to override policies=20 >associated with the called user, which I think is a bad=20 >thing. The result of the OPTIONS request can only ever act as=20 >a guideline - it is effectively no better than presence. >=20 >It would be helpful to have a concrete example of something=20 >that could go into an INVITE request targeted at a particular=20 >UA known to have a particular capability, that could not go=20 >into an INVITE request targeted at the AOR and with caller=20 >preferences RECOMMENDING selection of a UA with that=20 >particular capability. Apologies if such an example has=20 >already been given earlier in the discussion. I don't think I have said that the INVITE would necessarily be targeted to = a particular UA. There MAY of course be use-cases where you would target al= so the INVITE to a specific UAS. For example, if an UAS supports a specific= capability, and you don't want the call to proceed unless that UAS accepts= the INVITE. Then, if the INVITE fails, it may still be possible for the ca= ll to be forwarded to a voice mail etc, depending on policies and service d= esign in the network. But, the main point of the O-3xx mechanisms is that it allows you to target= *OPTIONS* request to particular UAs, in order to get the capabilities of t= hose. That is the only thing the mechanism is supposed to provide. What you then = do with that information is a separate issue, and that seems to be what the= discussion is now about. Now, we can discuss use-cases etc, but I just want to make it clear that th= e O-3xx mechanism itself does not make any assumptions regarding use-cases.= It only allows the usage of OPTIONS in forking scenarios - nothing more, n= othing less. Apart from providing a way to deal with the forking issue, it = does not solve any other issues, bugs or shortcomings there may be with OPT= IONS. Regards, Christer From HKaplan@acmepacket.com Thu Apr 8 03:17:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FC328C13F for ; Thu, 8 Apr 2010 03:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T1yQS-8jFt6 for ; Thu, 8 Apr 2010 03:17:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 895B63A688E for ; Thu, 8 Apr 2010 03:16:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 06:16:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 06:16:02 -0400 From: Hadriel Kaplan To: Christer Holmberg , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Thu, 8 Apr 2010 06:16:02 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAACPuvQABgDy5ACORmbAAKZ9ZcAAA9/KQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D1DE@mail> References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, , , <430FC6BDED356B4C8498F634416644A91A79F3CFD1@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:17:27 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, April 08, 2010 5:47 AM >=20 > Hadriel said: > >What's so crappy about using an INVITE to say you want to > >start a session? A failure of an INVITE request isn't a > >protocol failure or error condition (unless the response code > >is an error condition type). > > > >What's next, we need an OPTIONS before the OPTIONS to make > >sure the second OPTIONS won't fail?? ;) > > > >Sure the INVITE might trigger resources reservation - that's > >GOOD, because it verifies the resources are available - if > >those resources aren't available the request will fail, > >whereas for an OPTIONS it wouldn't have. >=20 > The resources will be released when the first INVITE is rejected, and a > new resource reservation procedure will start when the next INVITE comes. Yup, but I don't see what that has to do with what we're talking about? (th= e statement confuses me in this context) And again it's GOOD that the resources are reserved again. It may not be g= ood from a performance perspective, but it guarantees accuracy. Resources = change constantly. There are any number of resource availability changes i= n the network between the OPTIONS and the INVITE, or between two INVITES. = Obviously you could do a resource reservation model that is separate from I= NVITEs (or SIP altogether), but I don't see how that's relevant to this dis= cussion. (I must be missing something?) -hadriel From christer.holmberg@ericsson.com Thu Apr 8 03:30:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506BD3A67AD for ; Thu, 8 Apr 2010 03:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.343 X-Spam-Level: X-Spam-Status: No, score=-5.343 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwo-AmCA3zPX for ; Thu, 8 Apr 2010 03:30:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6E8183A681F for ; Thu, 8 Apr 2010 03:30:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-cb-4bbdb027e230 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C6.23.23532.720BDBB4; Thu, 8 Apr 2010 12:30:00 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Apr 2010 12:29:59 +0200 From: Christer Holmberg To: Hadriel Kaplan , "WORLEY, DALE R (DALE)" , Salvatore Loreto , "sipcore@ietf.org" Date: Thu, 8 Apr 2010 12:29:58 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrRbgd9b9IcvDpbTaqsmayh4rCRcAEVQJq3AAB0+5wAJP+7AAAq8GCA Message-ID: References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:30:06 -0000 Hi,=20 >>From my perspective, the main use-case is not to discover services,=20 >>but to discover capabilities in order to determine what services can be a= pplied. >>=20 >>The idea is also that the OPTIONS request would be sent prior to the=20 >>INVITE, to try to make sure that the returned contacts are actually=20 >>available. >=20 >But you know that would never work in practice/the-real-world. Think about= all the routing rules=20 >people have for INVITEs - in some cases *only* for INVITEs. =20 >And even if they route OPTIONS identically in the SIP domain,=20 >for any given AoR it'll go to any of: a SIP UA, or a PSTN=20 >gateway, or a H.323-gateway, or an MGCP call-agent, or an=20 >IP-PBX, or a foobar-protocol-gateway, or a vmail server, or=20 >an announcement server, or an app server, etc. Just because=20 >the OPTIONS reaches the end of the SIP domain, means nothing=20 >about whether an INVITE to the higher-layer target (which in=20 >practice is a E.164 number, that crosses from SIP into many=20 >other protocol domains) is actually available to receive a call. The assumption is that the OPTIONS request reaches the registrar, that retu= rns the registered contacts. It is never forwarded to any UAS. Then, at some point an INVITE is sent, and it is addressed to the same AOR = (the INVITE request might be routed differently than the OPTIONS request). = Based on the UAS information, the INVITE may now contain feature tags etc t= hat indicates a wish to reach an UAS with certain capabilities. Now, unless the INVITE is addressed to a specific UAS, it can of course not= be guranteed that the INVITE will actually reach such UAS. But, that is a = "feature" of RFC 3841, and it would be the case even if you had never sent = any OPTIONS. What OPTIONS allows provides you is capability information abo= ut the UAS(s) associated with the AOR, which might be useful when sending t= he INVITE. No, it does not guarantee that the user is available - it only provides you= with that same information as OPTIONS in a non-forking case does. Regards, Christer= From christer.holmberg@ericsson.com Thu Apr 8 03:31:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C293A67AD for ; Thu, 8 Apr 2010 03:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNVNsDRKoL4Q for ; Thu, 8 Apr 2010 03:31:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E44AE3A681F for ; Thu, 8 Apr 2010 03:31:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-62-4bbdb0954bba Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 24.E0.23740.590BDBB4; Thu, 8 Apr 2010 12:31:49 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 8 Apr 2010 12:31:49 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Adam Roach , SIPCORE Date: Thu, 8 Apr 2010 12:31:47 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAI9U2h9bTvlTTWR2RGyrmXE4gGJHj7AACmE4ZA= Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:31:54 -0000 Hi,=20 =09 >At the moment, my view is "Do nothing". The amount of resource needed for = this discussion does not justify the problem. > =20 >If someone wants to submit an author draft on a specific issue and fix, th= en fine, I'll reconsider. My intention has been to submit a draft that describes the OPTIONS 3xx mech= anism. Regards, Christer From christer.holmberg@ericsson.com Thu Apr 8 03:36:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18753A6948 for ; Thu, 8 Apr 2010 03:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O29bry5hwjCU for ; Thu, 8 Apr 2010 03:36:05 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id EECF33A67AD for ; Thu, 8 Apr 2010 03:35:51 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9b-4bbdb18380a6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9B.62.23740.381BDBB4; Thu, 8 Apr 2010 12:35:47 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 8 Apr 2010 12:35:47 +0200 From: Christer Holmberg To: Adam Roach , Hadriel Kaplan Date: Thu, 8 Apr 2010 12:35:45 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWYY0DnYgSpVwBTTS7GqyNunLkjAApTyGg Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> <4BBC9B6E.6000809@nostrum.com> In-Reply-To: <4BBC9B6E.6000809@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:36:06 -0000 Hi,=20 >The more I read through this thread, the more it looks like we're running = around with a hammer, desperately looking for nails to hit. Barring nails, = we'll settle for screws. Or bolts. Or maybe=20 >kittens, if it comes to that. >=09 >If you're trying to accomplish something, I would strongly recommend start= ing from the other end. Instead of saying "I have a tool, let's make a prob= lem for it to solve," let's concentrate on=20 >clearly defining existing problems. Once we agree on the problems, we can = talk about what tools make sense to solve them. That problem is that OPTIONS doesn't work in forking cases, which makes is = quite useless in those cases. Regards, Christer= From HKaplan@acmepacket.com Thu Apr 8 03:45:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84F13A68CC for ; Thu, 8 Apr 2010 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvoSeo4p03Gp for ; Thu, 8 Apr 2010 03:45:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6753B3A69A3 for ; Thu, 8 Apr 2010 03:44:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 06:44:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 06:44:41 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , Hans Erik van Elburg Date: Thu, 8 Apr 2010 06:44:40 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5AAAL6EcAAq+I2AAAGfQTA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D1E0@mail> References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:45:01 -0000 Hi Christer, I know you're frustrated we keep going back to a use-case, but you're askin= g for consensus on whether people are interested in working on the solution= . Without an actual use-case, how can we do that? Why would people agree = to spend time on something they don't see any use for solving? -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Thursday, April 08, 2010 6:13 AM > To: Elwell, John; Hans Erik van Elburg > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > Hi, >=20 > >[JRE] But even if you then target the INVITE request at the > >GRUU of the preferred user, there is no guarantee it will > >succeed (e.g., no media resources, UA has become busy in the > >meantime), and because it is targeted directly, you lose the > >opportunity to take alternative action, e.g., forwarding to > >voicemail or to another UA with similar capabilities. It is a > >case of the calling user trying to override policies > >associated with the called user, which I think is a bad > >thing. The result of the OPTIONS request can only ever act as > >a guideline - it is effectively no better than presence. > > > >It would be helpful to have a concrete example of something > >that could go into an INVITE request targeted at a particular > >UA known to have a particular capability, that could not go > >into an INVITE request targeted at the AOR and with caller > >preferences RECOMMENDING selection of a UA with that > >particular capability. Apologies if such an example has > >already been given earlier in the discussion. >=20 > I don't think I have said that the INVITE would necessarily be targeted t= o > a particular UA. There MAY of course be use-cases where you would target > also the INVITE to a specific UAS. For example, if an UAS supports a > specific capability, and you don't want the call to proceed unless that > UAS accepts the INVITE. Then, if the INVITE fails, it may still be > possible for the call to be forwarded to a voice mail etc, depending on > policies and service design in the network. >=20 > But, the main point of the O-3xx mechanisms is that it allows you to > target *OPTIONS* request to particular UAs, in order to get the > capabilities of those. >=20 > That is the only thing the mechanism is supposed to provide. What you the= n > do with that information is a separate issue, and that seems to be what > the discussion is now about. >=20 > Now, we can discuss use-cases etc, but I just want to make it clear that > the O-3xx mechanism itself does not make any assumptions regarding use- > cases. It only allows the usage of OPTIONS in forking scenarios - nothing > more, nothing less. Apart from providing a way to deal with the forking > issue, it does not solve any other issues, bugs or shortcomings there may > be with OPTIONS. >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Thu Apr 8 03:50:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889DF3A6882 for ; Thu, 8 Apr 2010 03:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAazatATvbnF for ; Thu, 8 Apr 2010 03:49:59 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4BE483A68D3 for ; Thu, 8 Apr 2010 03:49:57 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1482694; Thu, 8 Apr 2010 12:49:53 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id EBDD81EB82AE; Thu, 8 Apr 2010 12:49:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 8 Apr 2010 12:49:52 +0200 From: "Elwell, John" To: Christer Holmberg , Hans Erik van Elburg Date: Thu, 8 Apr 2010 12:49:51 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5AAAL6EcAAq+I2AAAFh9VA= Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:50:00 -0000 Christer, Thanks for that clarification - I wasn't certain about my interpretation. So we have the ability to target OPTIONS requests at individual UAs that ar= e contacts for a given AOR. From that I discover that UA N supports feature= X. I want to submit an INVITE request that uses feature X. If you say we d= on't target the INVITE request at UA N, then presumably I would target it a= t the AOR, which may or may not result in the request being forwarded to UA= N. I could use caller-prefs to indicate a preference for a UA that support= s feature X, and this will doubtless increase the chances that the INVITE r= equest will be forwarded to UA N. What exactly have I gained by compared with skipping OPTIONS and just sendi= ng an INVITE request to the AOR with a caller-pref for feature X? For examp= le, are you suggesting it would be harmful to send the INVITE request in a = case where no UA supports feature X? Note that in the typical SIP trapezoid, with 3 registered contacts, use of = OPTIONS would result in a significant amount of additional signalling traff= ic. Assuming the second proxy sends back 3xx with 3 contacts, resulting in = 3 further OPTIONS requests: - 1st OPTIONS request over two hops, with response: 4 message-hops - 2nd, 3rd and 4th OPTIONS requests, each over three hops, with responses: = 18 message-hops In other words, 22 additional SIP message hops (assuming the eventual INVIT= E request results in the same amount of signalling whether or not OPTIONS i= s used). So optimisation can hardly be claimed as a benefit. John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 08 April 2010 11:13 > To: Elwell, John; Hans Erik van Elburg > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > Hi, > =20 > >[JRE] But even if you then target the INVITE request at the=20 > >GRUU of the preferred user, there is no guarantee it will=20 > >succeed (e.g., no media resources, UA has become busy in the=20 > >meantime), and because it is targeted directly, you lose the=20 > >opportunity to take alternative action, e.g., forwarding to=20 > >voicemail or to another UA with similar capabilities. It is a=20 > >case of the calling user trying to override policies=20 > >associated with the called user, which I think is a bad=20 > >thing. The result of the OPTIONS request can only ever act as=20 > >a guideline - it is effectively no better than presence. > >=20 > >It would be helpful to have a concrete example of something=20 > >that could go into an INVITE request targeted at a particular=20 > >UA known to have a particular capability, that could not go=20 > >into an INVITE request targeted at the AOR and with caller=20 > >preferences RECOMMENDING selection of a UA with that=20 > >particular capability. Apologies if such an example has=20 > >already been given earlier in the discussion. >=20 > I don't think I have said that the INVITE would necessarily=20 > be targeted to a particular UA. There MAY of course be=20 > use-cases where you would target also the INVITE to a=20 > specific UAS. For example, if an UAS supports a specific=20 > capability, and you don't want the call to proceed unless=20 > that UAS accepts the INVITE. Then, if the INVITE fails, it=20 > may still be possible for the call to be forwarded to a voice=20 > mail etc, depending on policies and service design in the network. >=20 > But, the main point of the O-3xx mechanisms is that it allows=20 > you to target *OPTIONS* request to particular UAs, in order=20 > to get the capabilities of those. >=20 > That is the only thing the mechanism is supposed to provide.=20 > What you then do with that information is a separate issue,=20 > and that seems to be what the discussion is now about. >=20 > Now, we can discuss use-cases etc, but I just want to make it=20 > clear that the O-3xx mechanism itself does not make any=20 > assumptions regarding use-cases. It only allows the usage of=20 > OPTIONS in forking scenarios - nothing more, nothing less.=20 > Apart from providing a way to deal with the forking issue, it=20 > does not solve any other issues, bugs or shortcomings there=20 > may be with OPTIONS. >=20 > Regards, >=20 > Christer > = From ietf.hanserik@gmail.com Thu Apr 8 05:23:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EC63A6911 for ; Thu, 8 Apr 2010 05:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCBwpPz7MmD9 for ; Thu, 8 Apr 2010 05:23:09 -0700 (PDT) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by core3.amsl.com (Postfix) with ESMTP id D17F73A6A5D for ; Thu, 8 Apr 2010 05:22:58 -0700 (PDT) Received: by ewy21 with SMTP id 21so921559ewy.5 for ; Thu, 08 Apr 2010 05:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=GmTeLxKNI04EKkIcY2xr9UZhKiHOxs0rszbi/ZRJLY8=; b=hlL9md3hDA8hYb0vTKmQBlRAHOGpiuYO5ac8IGYLU38hsxcRVmgjzYX0cCnQPiVnp3 3tBRabo0CTzNSkFgKWdtqiCEhtljGn+vhF0Pqkc8N021fpfPIkyPCwwCXnhO6bT7b8PG 4XX/ePzSJTs9PSn7J9u0rDV6PvYczMmYHEmOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pE3CFtnZoG+a1PNQlAgHVAKMckPKbElirnKARchg4sGNSeR24CO0NdR5kJWjLC2A16 VEVKs/G8tBLO8n1TTnpKktj2Wmdn4k9RPWoHveQGnIROxHGZRIIxLChdkoeRk4CwoJgY ZuVXm8l/cPK6FJwJWN/6XNY7T4Pyn6n04m1Z8= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 05:22:52 -0700 (PDT) In-Reply-To: References: <4BB24B81.1050006@nostrum.com> Date: Thu, 8 Apr 2010 14:22:52 +0200 Received: by 10.213.77.203 with SMTP id h11mr33859ebk.51.1270729372782; Thu, 08 Apr 2010 05:22:52 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=00c09f8e6090ded22b0483b8bc8b Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 12:23:17 -0000 --00c09f8e6090ded22b0483b8bc8b Content-Type: text/plain; charset=ISO-8859-1 Hi John, But if you only want to probe the devices behind the AOR for some reason (knowing the limitations of the obtained information), then you do not want to use INVITE do you? /Hans Erik van Elburg On Thu, Apr 8, 2010 at 12:49 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Christer, > > Thanks for that clarification - I wasn't certain about my interpretation. > > So we have the ability to target OPTIONS requests at individual UAs that > are contacts for a given AOR. From that I discover that UA N supports > feature X. I want to submit an INVITE request that uses feature X. If you > say we don't target the INVITE request at UA N, then presumably I would > target it at the AOR, which may or may not result in the request being > forwarded to UA N. I could use caller-prefs to indicate a preference for a > UA that supports feature X, and this will doubtless increase the chances > that the INVITE request will be forwarded to UA N. > > What exactly have I gained by compared with skipping OPTIONS and just > sending an INVITE request to the AOR with a caller-pref for feature X? For > example, are you suggesting it would be harmful to send the INVITE request > in a case where no UA supports feature X? > > Note that in the typical SIP trapezoid, with 3 registered contacts, use of > OPTIONS would result in a significant amount of additional signalling > traffic. Assuming the second proxy sends back 3xx with 3 contacts, resulting > in 3 further OPTIONS requests: > - 1st OPTIONS request over two hops, with response: 4 message-hops > - 2nd, 3rd and 4th OPTIONS requests, each over three hops, with responses: > 18 message-hops > In other words, 22 additional SIP message hops (assuming the eventual > INVITE request results in the same amount of signalling whether or not > OPTIONS is used). So optimisation can hardly be claimed as a benefit. > > John > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 08 April 2010 11:13 > > To: Elwell, John; Hans Erik van Elburg > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > > Hi, > > > > >[JRE] But even if you then target the INVITE request at the > > >GRUU of the preferred user, there is no guarantee it will > > >succeed (e.g., no media resources, UA has become busy in the > > >meantime), and because it is targeted directly, you lose the > > >opportunity to take alternative action, e.g., forwarding to > > >voicemail or to another UA with similar capabilities. It is a > > >case of the calling user trying to override policies > > >associated with the called user, which I think is a bad > > >thing. The result of the OPTIONS request can only ever act as > > >a guideline - it is effectively no better than presence. > > > > > >It would be helpful to have a concrete example of something > > >that could go into an INVITE request targeted at a particular > > >UA known to have a particular capability, that could not go > > >into an INVITE request targeted at the AOR and with caller > > >preferences RECOMMENDING selection of a UA with that > > >particular capability. Apologies if such an example has > > >already been given earlier in the discussion. > > > > I don't think I have said that the INVITE would necessarily > > be targeted to a particular UA. There MAY of course be > > use-cases where you would target also the INVITE to a > > specific UAS. For example, if an UAS supports a specific > > capability, and you don't want the call to proceed unless > > that UAS accepts the INVITE. Then, if the INVITE fails, it > > may still be possible for the call to be forwarded to a voice > > mail etc, depending on policies and service design in the network. > > > > But, the main point of the O-3xx mechanisms is that it allows > > you to target *OPTIONS* request to particular UAs, in order > > to get the capabilities of those. > > > > That is the only thing the mechanism is supposed to provide. > > What you then do with that information is a separate issue, > > and that seems to be what the discussion is now about. > > > > Now, we can discuss use-cases etc, but I just want to make it > > clear that the O-3xx mechanism itself does not make any > > assumptions regarding use-cases. It only allows the usage of > > OPTIONS in forking scenarios - nothing more, nothing less. > > Apart from providing a way to deal with the forking issue, it > > does not solve any other issues, bugs or shortcomings there > > may be with OPTIONS. > > > > Regards, > > > > Christer > > > --00c09f8e6090ded22b0483b8bc8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,

But if you only want to probe the devices behind the AOR fo= r some reason (knowing the limitations of the obtained information), then y= ou do not want to use INVITE do you?

/Hans Erik van El= burg


On Thu, Apr 8, 2010 at 12:49 PM, Elwell,= John <john.elwell@siemens-enterprise.com> wrote:
Christer,

Thanks for that clarification - I wasn't certain about my interpretatio= n.

So we have the ability to target OPTIONS requests at individual UAs that ar= e contacts for a given AOR. From that I discover that UA N supports feature= X. I want to submit an INVITE request that uses feature X. If you say we d= on't target the INVITE request at UA N, then presumably I would target = it at the AOR, which may or may not result in the request being forwarded t= o UA N. I could use caller-prefs to indicate a preference for a UA that sup= ports feature X, and this will doubtless increase the chances that the INVI= TE request will be forwarded to UA N.

What exactly have I gained by compared with skipping OPTIONS and just sendi= ng an INVITE request to the AOR with a caller-pref for feature X? For examp= le, are you suggesting it would be harmful to send the INVITE request in a = case where no UA supports feature X?

Note that in the typical SIP trapezoid, with 3 registered contacts, use of = OPTIONS would result in a significant amount of additional signalling traff= ic. Assuming the second proxy sends back 3xx with 3 contacts, resulting in = 3 further OPTIONS requests:
- 1st OPTIONS request over two hops, with response: 4 message-hops
- 2nd, 3rd and 4th OPTIONS requests, each over three hops, with responses: = 18 message-hops
In other words, 22 additional SIP message hops (assuming the eventual INVIT= E request results in the same amount of signalling whether or not OPTIONS i= s used). So optimisation can hardly be claimed as a benefit.

John

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: 08 April 2010 11:13
> To: Elwell, John; Hans Erik van Elburg
> Cc: WORLEY, DALE R (DALE); sipcore= @ietf.org
> Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this?
>
>
> Hi,
>
> >[JRE] But even if you then target the INVITE request at the
> >GRUU of the preferred user, there is no guarantee it will
> >succeed (e.g., no media resources, UA has become busy in the
> >meantime), and because it is targeted directly, you lose the
> >opportunity to take alternative action, e.g., forwarding to
> >voicemail or to another UA with similar capabilities. It is a
> >case of the calling user trying to override policies
> >associated with the called user, which I think is a bad
> >thing. The result of the OPTIONS request can only ever act as
> >a guideline - it is effectively no better than presence.
> >
> >It would be helpful to have a concrete example of something
> >that could go into an INVITE request targeted at a particular
> >UA known to have a particular capability, that could not go
> >into an INVITE request targeted at the AOR and with caller
> >preferences RECOMMENDING selection of a UA with that
> >particular capability. Apologies if such an example has
> >already been given earlier in the discussion.
>
> I don't think I have said that the INVITE would necessarily
> be targeted to a particular UA. There MAY of course be
> use-cases where you would target also the INVITE to a
> specific UAS. For example, if an UAS supports a specific
> capability, and you don't want the call to proceed unless
> that UAS accepts the INVITE. Then, if the INVITE fails, it
> may still be possible for the call to be forwarded to a voice
> mail etc, depending on policies and service design in the network.
>
> But, the main point of the O-3xx mechanisms is that it allows
> you to target *OPTIONS* request to particular UAs, in order
> to get the capabilities of those.
>
> That is the only thing the mechanism is supposed to provide.
> What you then do with that information is a separate issue,
> and that seems to be what the discussion is now about.
>
> Now, we can discuss use-cases etc, but I just want to make it
> clear that the O-3xx mechanism itself does not make any
> assumptions regarding use-cases. It only allows the usage of
> OPTIONS in forking scenarios - nothing more, nothing less.
> Apart from providing a way to deal with the forking issue, it
> does not solve any other issues, bugs or shortcomings there
> may be with OPTIONS.
>
> Regards,
>
> Christer
>

--00c09f8e6090ded22b0483b8bc8b-- From brett@broadsoft.com Thu Apr 8 05:37:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66C028C131 for ; Thu, 8 Apr 2010 05:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJglnAggmYgk for ; Thu, 8 Apr 2010 05:37:41 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 622FB28C130 for ; Thu, 8 Apr 2010 05:37:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 8 Apr 2010 05:37:33 -0700 From: Brett Tate To: SIPCORE Date: Thu, 8 Apr 2010 05:36:42 -0700 Thread-Topic: RFC 4320: deprecation of non-INVITE 408 responses Thread-Index: AcrXGCR2YV2b3lCjSbqCYTTjO7gxHw== Message-ID: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> 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: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 12:37:42 -0000 Since it was raised within rfc3265bis discussion, I thought that I'd attemp= t to get clarity concerning RFC 4320's deprecation of non-INVITE 408 respon= ses in case errata should be opened against RFC 4320. RFC 4320 intentionally or unintentionally appears to have deprecated all no= n-INVITE 408 responses. However I thought that I'd still ask, is the depre= cation only applicable for Timer F expiration type situations (i.e. the rea= son for the deprecation)? If not limited to Timer F expiration type situations, such a deprecation ca= uses some ambiguity concerning shorter timeouts on other interfaces. For i= nstance, a received SUBSCRIBE is transformed into another protocol's FOO me= ssage. The FOO transaction delivery expires after 1 second. Can a 408 res= ponse (although 504 might be better per rfc3261) be sent for the SUBSCRIBE?= What about a B2BUA which using a short expiration (like 1 second) on the = send side; can it send a 408 response or must it really start sending 504 o= r other response instead?=20 Thanks, Brett From john.elwell@siemens-enterprise.com Thu Apr 8 06:39:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921DF3A63EB for ; Thu, 8 Apr 2010 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGOnvavQi7yF for ; Thu, 8 Apr 2010 06:39:57 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 209493A67EF for ; Thu, 8 Apr 2010 06:39:56 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1485053; Thu, 8 Apr 2010 15:39:53 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 40F6D1EB82AB; Thu, 8 Apr 2010 15:39:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 8 Apr 2010 15:39:53 +0200 From: "Elwell, John" To: Hans Erik van Elburg Date: Thu, 8 Apr 2010 15:39:52 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrXFjbGTbs2UDdYRCSyUs39tOdTQQACcSxQ Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:39:58 -0000 I thought we were talking about doing OPTIONS as a prelude to doing INVITE = (or SUBSCRIBE or MESSAGE or whatever), in which case you could just send th= e request concerned and see what happens - no need to bother with OPTIONS. = But you now seem to be suggesting the use of OPTIONS standalone. In either case, nobody seems to have given a convincing use case where prob= ing all the devices behind an AOR is of significant benefit, and if there i= s a significant benefit, why you can't just obtain the device contact URIs = using the reg event package and then send OPTIONS to each. John > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 08 April 2010 13:23 > To: Elwell, John > Cc: Christer Holmberg; WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 > Hi John, >=20 > But if you only want to probe the devices behind the AOR for=20 > some reason (knowing the limitations of the obtained=20 > information), then you do not want to use INVITE do you? >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Thu, Apr 8, 2010 at 12:49 PM, Elwell, John=20 > wrote: >=20 >=20 > Christer, > =09 > Thanks for that clarification - I wasn't certain about=20 > my interpretation. > =09 > So we have the ability to target OPTIONS requests at=20 > individual UAs that are contacts for a given AOR. From that I=20 > discover that UA N supports feature X. I want to submit an=20 > INVITE request that uses feature X. If you say we don't=20 > target the INVITE request at UA N, then presumably I would=20 > target it at the AOR, which may or may not result in the=20 > request being forwarded to UA N. I could use caller-prefs to=20 > indicate a preference for a UA that supports feature X, and=20 > this will doubtless increase the chances that the INVITE=20 > request will be forwarded to UA N. > =09 > What exactly have I gained by compared with skipping=20 > OPTIONS and just sending an INVITE request to the AOR with a=20 > caller-pref for feature X? For example, are you suggesting it=20 > would be harmful to send the INVITE request in a case where=20 > no UA supports feature X? > =09 > Note that in the typical SIP trapezoid, with 3=20 > registered contacts, use of OPTIONS would result in a=20 > significant amount of additional signalling traffic. Assuming=20 > the second proxy sends back 3xx with 3 contacts, resulting in=20 > 3 further OPTIONS requests: > - 1st OPTIONS request over two hops, with response: 4=20 > message-hops > - 2nd, 3rd and 4th OPTIONS requests, each over three=20 > hops, with responses: 18 message-hops > In other words, 22 additional SIP message hops=20 > (assuming the eventual INVITE request results in the same=20 > amount of signalling whether or not OPTIONS is used). So=20 > optimisation can hardly be claimed as a benefit. > =09 > John > =09 >=20 > > -----Original Message----- > > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > =09 > > Sent: 08 April 2010 11:13 > > To: Elwell, John; Hans Erik van Elburg > > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > > Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? > > > > > =09 > > Hi, > > > > >[JRE] But even if you then target the INVITE request at the > > >GRUU of the preferred user, there is no guarantee it will > > >succeed (e.g., no media resources, UA has become busy in the > > >meantime), and because it is targeted directly, you lose the > > >opportunity to take alternative action, e.g., forwarding to > > >voicemail or to another UA with similar capabilities. It is a > > >case of the calling user trying to override policies > > >associated with the called user, which I think is a bad > > >thing. The result of the OPTIONS request can only ever act as > > >a guideline - it is effectively no better than presence. > > > > > >It would be helpful to have a concrete example of something > > >that could go into an INVITE request targeted at a particular > > >UA known to have a particular capability, that could not go > > >into an INVITE request targeted at the AOR and with caller > > >preferences RECOMMENDING selection of a UA with that > > >particular capability. Apologies if such an example has > > >already been given earlier in the discussion. > > > > I don't think I have said that the INVITE would necessarily > > be targeted to a particular UA. There MAY of course be > > use-cases where you would target also the INVITE to a > > specific UAS. For example, if an UAS supports a specific > > capability, and you don't want the call to proceed unless > > that UAS accepts the INVITE. Then, if the INVITE fails, it > > may still be possible for the call to be forwarded to a voice > > mail etc, depending on policies and service design in=20 > the network. > > > > But, the main point of the O-3xx mechanisms is that it allows > > you to target *OPTIONS* request to particular UAs, in order > > to get the capabilities of those. > > > > That is the only thing the mechanism is supposed to provide. > > What you then do with that information is a separate issue, > > and that seems to be what the discussion is now about. > > > > Now, we can discuss use-cases etc, but I just want to make it > > clear that the O-3xx mechanism itself does not make any > > assumptions regarding use-cases. It only allows the usage of > > OPTIONS in forking scenarios - nothing more, nothing less. > > Apart from providing a way to deal with the forking issue, it > > does not solve any other issues, bugs or shortcomings there > > may be with OPTIONS. > > > > Regards, > > > > Christer > >=20 >=20 >=20 > = From pkyzivat@cisco.com Thu Apr 8 07:01:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D8B3A67EF for ; Thu, 8 Apr 2010 07:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ouqqgiueIVF for ; Thu, 8 Apr 2010 07:01:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BB0383A6804 for ; Thu, 8 Apr 2010 07:01:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAJ+vUutJV2b/2dsb2JhbACbMXGgHpkmglyCLQQ X-IronPort-AV: E=Sophos;i="4.52,170,1270425600"; d="scan'208";a="99903629" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2010 14:01:10 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o38E19kC027540; Thu, 8 Apr 2010 14:01:10 GMT Message-ID: <4BBDE1A0.5050603@cisco.com> Date: Thu, 08 Apr 2010 10:01:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:01:22 -0000 [as individual] It seems that Christer has come close to offering a use case, even if that was not his intent. And its still a little incomplete. I'll try to fill it out a bit: Alice wants to call Bob. Her phone app first queries Bob's AOR with OPTIONS. The response to that is a 3xx with Contact URIs for Bob's home phone and his mobile phone. So Alice's phone sends additional OPTIONS requests to each of those. From the responses it learns that Bob's mobile phone support audio and video, while his home phone (behind a pstn gateway) only supports audio. Alice has video support on her phone, and since Bob may be able to support video too, decides to make an audio+video call. The phone sends an INVITE with both, and caller preferences indicating a preference for audio+video. The INVITE reaches the server handling Bob's AOR. It processes the callerprefs, and so decides to initially send the invite to Bob's mobile phone. But there is no answer there, so the server forks the invite toward Bob's home phone. Bob answers that one, accepting the audio and rejecting the video. The result of this is exactly the same as if no OPTIONS was ever sent, and the INVITE was sent indicating Alice's own preferences. That is the point that John already made. The only "benefit" I can see from use of options here would be if it was discovered that Bob had no video support. In that case, the invite could have been sent without offering video. Is that advantageous? Does it cost more to initiate a call that offers video? Does it take more network resources to do so, even when ultimately the video is rejected? The only real benefit I can see to this is if the calling user is given an enhanced user interface - akin to what one gets with buddy lists - where there is a display showing that Bob has two devices with differing capabilities, with Alice having the option to choose one or allowing the phone to make the choice. To provide that feature, presence would be a much better choice. OPTIONS is in a sense "poor man's presence". Christer has mentioned that he considers presence to be too "heavy weight" for this, but I remain to be convinced of that. Perhaps maintaining persistent subscriptions to presence status of everyone you might possibly call is too heavy weight, but doing a polling subscription prior to a call won't be any heavier than all this options stuff. It may be that lots of devices don't publish presence state. But that can be solved in many ways. A registrar can synthesize basic presence state from registration data. And it could even use OPTIONS to refine that. I suspect the real hidden issue here is about presence, and so I'd prefer to see it addressed from that direction. If that in turn leads to a desire to use OPTIONS to get some degree of presence state from devices that don't otherwise publish it, then lets confront it in that context. And if the issue is that presence is typically not authorized for as many requesters as OPTIONS is, then lets look at possible policy recommendations in that regard. Thanks, Paul Christer Holmberg wrote: > Hi, > >> >From my perspective, the main use-case is not to discover services, >>> but to discover capabilities in order to determine what services can be applied. >>> >>> The idea is also that the OPTIONS request would be sent prior to the >>> INVITE, to try to make sure that the returned contacts are actually >>> available. >> But you know that would never work in practice/the-real-world. Think about all the routing rules >> people have for INVITEs - in some cases *only* for INVITEs. >> And even if they route OPTIONS identically in the SIP domain, >> for any given AoR it'll go to any of: a SIP UA, or a PSTN >> gateway, or a H.323-gateway, or an MGCP call-agent, or an >> IP-PBX, or a foobar-protocol-gateway, or a vmail server, or >> an announcement server, or an app server, etc. Just because >> the OPTIONS reaches the end of the SIP domain, means nothing >> about whether an INVITE to the higher-layer target (which in >> practice is a E.164 number, that crosses from SIP into many >> other protocol domains) is actually available to receive a call. > > The assumption is that the OPTIONS request reaches the registrar, that returns the registered contacts. It is never forwarded to any UAS. > > Then, at some point an INVITE is sent, and it is addressed to the same AOR (the INVITE request might be routed differently than the OPTIONS request). Based on the UAS information, the INVITE may now contain feature tags etc that indicates a wish to reach an UAS with certain capabilities. > > Now, unless the INVITE is addressed to a specific UAS, it can of course not be guranteed that the INVITE will actually reach such UAS. But, that is a "feature" of RFC 3841, and it would be the case even if you had never sent any OPTIONS. What OPTIONS allows provides you is capability information about the UAS(s) associated with the AOR, which might be useful when sending the INVITE. > > No, it does not guarantee that the user is available - it only provides you with that same information as OPTIONS in a non-forking case does. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Thu Apr 8 07:17:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D0B3A6926 for ; Thu, 8 Apr 2010 07:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCZMJPY3-Ru8 for ; Thu, 8 Apr 2010 07:17:51 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7878A3A67A7 for ; Thu, 8 Apr 2010 07:17:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALKCvUtAZnwN/2dsb2JhbACbMXGgSZklhQkE X-IronPort-AV: E=Sophos;i="4.52,170,1270425600"; d="scan'208";a="99908982" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2010 14:17:43 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o38EHgKL020967; Thu, 8 Apr 2010 14:17:42 GMT Message-ID: <4BBDE58B.6040100@cisco.com> Date: Thu, 08 Apr 2010 10:17:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:17:52 -0000 [as individual] Christer Holmberg wrote: > Hi, > > In the case of DE-subscriptions (which is just one variant of re-subscription), I still think there are some issues regarding whether the SUB 200 or the NOT req acknowledges the SUB req. > > Assuming the sub dialog is terminated when an entity receives a SUB 200 that contains 'Expires: 0'. > > Now, if there is then a NOT request (that contains 'Subscription-State: terminated'), won't it be treated as an out-of-dialog request, and rejected? That scenario has always bothered me. When my purpose is simply to request the termination of the existing dialog, and I have no further interest in the state, is there any reason for the NOTIFY? Can it be suppressed? Its especially a problem if I think the dialog is already broken, and I'm just trying to ensure its cleanly gone. Thanks, Paul > (Again, IF one is supposed to wait for the NOT req before terminating the dialog we again have a problem with the subnot draft.) > > Regards, > > Christer > > > > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 7. huhtikuuta 2010 9:21 >> To: Adam Roach; Brett Tate >> Cc: SIPCORE >> Subject: [sipcore] Rfc3265bis: NOTIFY request or response >> confirms (re-)subscription? [was rfc3265bis: SIP events redux >> [was Minutes Posted]] >> >> >> Hi, >> >> I haven't double checked whether it is said in 3265bis, but >> we also need to make clear whether it is the NOTIFY request, >> or the NOT 200 response, that "acknowledges" the (re-)subscription. >> >> Because, a NOTIFY request can also be rejected (e.g. due to >> overload), so in order to avoid sub state unsynch every >> entity in the path needs to know what a NOT non-200 response means. >> >> Regards, >> >> Christer >> >> >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach >>> Sent: 7. huhtikuuta 2010 2:37 >>> To: Brett Tate >>> Cc: SIPCORE >>> Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes >>> Posted] >>> >>> On 4/6/10 17:46, Apr 6, Brett Tate wrote: >>>>> Is there *any* problem here? This seems to be working >>> about as well >>>>> as anyone might hope. >>>>> >>>> It works okay excluding the non backward compatibility with >>> RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)... >>> >>> I don't think it's accurate to characterize the change as >>> non-backwards-compatible. The only wire-visible behavior that one >>> could conceivable observe is that a subscriber might make a >> different >>> decision about which subscription to accept if the >> SUBSCRIBE forks and >>> the subscriber wants only one subscription. >>> >>> What we *do* gain is a simplification for implementors. >>> Because the behavior of establishing the dialog when a >> NOTIFY shows up >>> (instead of "the first of a 2xx or a NOTIFY) is much easier >> to code, >>> people will make fewer mistakes, and have fewer bugs. But you'd be >>> hard pressed to see a difference on the wire. >>> >>>> The draft's Timer N (and lack of related NOTIFY) text is >>> potentially >>>> worded in a way which does not require the tear down (and non >>>> creation) of subscription. >>> Tear-down of existing dialogs is still an open issue, sure. I don't >>> get where you see any wiggle room in what happens if Timer >> N fires for >>> the first SUBSCRIBE/NOTIFY exchange. >>> >>> /a >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From keith.drage@alcatel-lucent.com Thu Apr 8 07:51:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0662E3A6828 for ; Thu, 8 Apr 2010 07:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.437 X-Spam-Level: X-Spam-Status: No, score=-5.437 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gM8V94mxBhU for ; Thu, 8 Apr 2010 07:51:08 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 9F2F03A6909 for ; Thu, 8 Apr 2010 07:50:53 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o38Emw06019938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Apr 2010 16:50:43 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 8 Apr 2010 16:49:18 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Thu, 8 Apr 2010 16:49:18 +0200 Thread-Topic: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] Thread-Index: AcrWzLlS4vJ4IL6IRB6Ju1YK1tNxvAAXOw5Q Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBCA20B.5040601@cisco.com> <4BBCCB52.7080302@nostrum.com> <4BBCCEEE.1050909@cisco.com> <4BBCD09E.8020403@nostrum.com> <4BBCD45F.6040405@cisco.com> <4BBD4F4A.7000009@nostrum.com> In-Reply-To: <4BBD4F4A.7000009@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE211CCDA0AFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:51:10 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE211CCDA0AFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your argument is accepted. That is an appropriate compatibility analysis. Keith ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, April 08, 2010 4:37 AM To: DRAGE, Keith (Keith) Cc: Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] On 4/7/10 20:16, Apr 7, DRAGE, Keith (Keith) wrote: While I accept that RFC 4320 is mandatory for all current implementations c= alling themselves SIP, we do need to deal with compatibility issues with de= ployments made before it was thought of and became an RFC. Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any ot= her implementation needs to be able to receive it. Be able to receive it, yes. But, as RFC 4321 explains, the local transactio= n timer will have already expired. The 408 will be treated as a stray respo= nse. A well-designed SIP stack will discard it before it even reaches the T= U. Even a poorly-designed but 3261-compliant application will ignore a 408 = for a non-INVITE, because the transaction is already gone. In other words, by the time the 408 arrives, it is thoroughly irrelevant. W= e don't need to talk about it in 3265bis, because something else will have = gone wrong first. And that situation is already covered: If the NOTIFY request fails due to expiration of SIP Timer F (transaction timeout), the notifier SHOULD remove the subscription. /a --_000_EDC0A1AE77C57744B664A310A0B23AE211CCDA0AFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Your argument is accepted.
 
That is an appropriate compatibility=20 analysis.

Keith

From: Adam Roach [mailto:adam@nostrum= .com]=20
Sent: Thursday, April 08, 2010 4:37 AM
To: DRAGE, Ke= ith=20 (Keith)
Cc: Paul Kyzivat; SIPCORE
Subject: Re: [sipco= re]=20 rfc3265bis: SIP events redux [was Minutes Posted]

On 4/7/10 20:16, Apr 7, DRAGE, Keith (Keith) wrote:=20 
While I accept that RFC 4320 is mandatory fo=
r all current implementations calling themselves SIP, we do need to deal wi=
th compatibility issues with deployments made before it was thought of and =
became an RFC.

Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any ot=
her implementation needs to be able to receive it.

Be able to receive it, yes. But, as RFC 4321=20 explains, the local transaction timer will have already expired. The 408 = will=20 be treated as a stray response. A well-designed SIP stack will discard it= =20 before it even reaches the TU. Even a poorly-designed but 3261-compliant= =20 application will ignore a 408 for a non-INVITE, because the transaction i= s=20 already gone.

In other words, by the time the 408 arrives, it is=20 thoroughly irrelevant. We don't need to talk about it in 3265bis, because= =20 something else will have gone wrong first.

And that situation is=20 already covered:
   If the NOTIFY request fails d=
ue to expiration of SIP Timer F
   (transaction timeout), the notifier SHOULD remove the subscription.

/a
--_000_EDC0A1AE77C57744B664A310A0B23AE211CCDA0AFRMRSSXCHMBSC3d_-- From salvatore.loreto@ericsson.com Thu Apr 8 08:09:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3953A6828 for ; Thu, 8 Apr 2010 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15xDao4j7x-e for ; Thu, 8 Apr 2010 08:09:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 19D7E3A68AC for ; Thu, 8 Apr 2010 08:09:43 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-52-4bbdf1b3bf98 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5B.56.23740.3B1FDBB4; Thu, 8 Apr 2010 17:09:39 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 17:09:39 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 17:09:37 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E21DD2462; Thu, 8 Apr 2010 18:09:34 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9C6954F3D9; Thu, 8 Apr 2010 18:09:34 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0EC3F4F3BC; Thu, 8 Apr 2010 18:09:14 +0300 (EEST) Message-ID: <4BBDF184.6060806@ericsson.com> Date: Thu, 08 Apr 2010 17:08:52 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <4BBDE1A0.5050603@cisco.com> In-Reply-To: <4BBDE1A0.5050603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 08 Apr 2010 15:09:37.0690 (UTC) FILETIME=[815657A0:01CAD72D] X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:09:46 -0000 Hi Paul, the use case you have written down is exactly the one I have in mind and was going to send to this ml. I want add one more benefit in knowing all the capabilities of the different Bob devices in advance and not just of one device. An OPTIONS response (or another mechanism!) that contains a level of granularity that let Alice (or rather Alices device) know that Bob can take only audio on one device, but audio/video/text/picture on his other device (as describe in Paul use case), would help Alice's device understand that starting a voice session with only voice Bob device, there is no way a re-INVITE to add video would work; so if she thinks that a voice call could be then transformed in a voice+video, she knows that should contact directly the audio/video/text/picture device. cheers Sal On 4/8/10 4:01 PM, Paul Kyzivat wrote: > [as individual] > > It seems that Christer has come close to offering a use case, even if > that was not his intent. And its still a little incomplete. I'll try to > fill it out a bit: > > Alice wants to call Bob. > Her phone app first queries Bob's AOR with OPTIONS. > The response to that is a 3xx with Contact URIs for > Bob's home phone and his mobile phone. So Alice's phone > sends additional OPTIONS requests to each of those. > From the responses it learns that Bob's mobile phone support > audio and video, while his home phone (behind a pstn gateway) > only supports audio. > > Alice has video support on her phone, and since Bob may be able to > support video too, decides to make an audio+video call. The > phone sends an INVITE with both, and caller preferences indicating > a preference for audio+video. > > The INVITE reaches the server handling Bob's AOR. > It processes the callerprefs, and so decides to initially send the > invite to Bob's mobile phone. But there is no answer there, so > the server forks the invite toward Bob's home phone. Bob answers that > one, accepting the audio and rejecting the video. > > The result of this is exactly the same as if no OPTIONS was ever sent, > and the INVITE was sent indicating Alice's own preferences. That is the > point that John already made. > > The only "benefit" I can see from use of options here would be if it was > discovered that Bob had no video support. In that case, the invite could > have been sent without offering video. Is that advantageous? Does it > cost more to initiate a call that offers video? Does it take more > network resources to do so, even when ultimately the video is rejected? > > The only real benefit I can see to this is if the calling user is given > an enhanced user interface - akin to what one gets with buddy lists - > where there is a display showing that Bob has two devices with differing > capabilities, with Alice having the option to choose one or allowing the > phone to make the choice. > > To provide that feature, presence would be a much better choice. > OPTIONS is in a sense "poor man's presence". Christer has mentioned that > he considers presence to be too "heavy weight" for this, but I remain to > be convinced of that. Perhaps maintaining persistent subscriptions to > presence status of everyone you might possibly call is too heavy weight, > but doing a polling subscription prior to a call won't be any heavier > than all this options stuff. > > It may be that lots of devices don't publish presence state. But that > can be solved in many ways. A registrar can synthesize basic presence > state from registration data. And it could even use OPTIONS to refine that. > > I suspect the real hidden issue here is about presence, and so I'd > prefer to see it addressed from that direction. If that in turn leads to > a desire to use OPTIONS to get some degree of presence state from > devices that don't otherwise publish it, then lets confront it in that > context. And if the issue is that presence is typically not authorized > for as many requesters as OPTIONS is, then lets look at possible policy > recommendations in that regard. > > Thanks, > Paul > > Christer Holmberg wrote: > >> Hi, >> >> >>> > From my perspective, the main use-case is not to discover services, >>> >>>> but to discover capabilities in order to determine what services can be applied. >>>> >>>> The idea is also that the OPTIONS request would be sent prior to the >>>> INVITE, to try to make sure that the returned contacts are actually >>>> available. >>>> >>> But you know that would never work in practice/the-real-world. Think about all the routing rules >>> people have for INVITEs - in some cases *only* for INVITEs. >>> And even if they route OPTIONS identically in the SIP domain, >>> for any given AoR it'll go to any of: a SIP UA, or a PSTN >>> gateway, or a H.323-gateway, or an MGCP call-agent, or an >>> IP-PBX, or a foobar-protocol-gateway, or a vmail server, or >>> an announcement server, or an app server, etc. Just because >>> the OPTIONS reaches the end of the SIP domain, means nothing >>> about whether an INVITE to the higher-layer target (which in >>> practice is a E.164 number, that crosses from SIP into many >>> other protocol domains) is actually available to receive a call. >>> >> The assumption is that the OPTIONS request reaches the registrar, that returns the registered contacts. It is never forwarded to any UAS. >> >> Then, at some point an INVITE is sent, and it is addressed to the same AOR (the INVITE request might be routed differently than the OPTIONS request). Based on the UAS information, the INVITE may now contain feature tags etc that indicates a wish to reach an UAS with certain capabilities. >> >> Now, unless the INVITE is addressed to a specific UAS, it can of course not be guranteed that the INVITE will actually reach such UAS. But, that is a "feature" of RFC 3841, and it would be the case even if you had never sent any OPTIONS. What OPTIONS allows provides you is capability information about the UAS(s) associated with the AOR, which might be useful when sending the INVITE. >> >> No, it does not guarantee that the user is available - it only provides you with that same information as OPTIONS in a non-forking case does. >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> -- Salvatore Loreto www.sloreto.com From stpeter@stpeter.im Thu Apr 8 08:13:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CDC3A67A6 for ; Thu, 8 Apr 2010 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H5rTVRtFiiM for ; Thu, 8 Apr 2010 08:13:11 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B5B0B3A6A87 for ; Thu, 8 Apr 2010 08:13:10 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2DEE140E15 for ; Thu, 8 Apr 2010 09:13:07 -0600 (MDT) Message-ID: <4BBDF280.6090201@stpeter.im> Date: Thu, 08 Apr 2010 09:13:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <4BBDE1A0.5050603@cisco.com> <4BBDF184.6060806@ericsson.com> In-Reply-To: <4BBDF184.6060806@ericsson.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030704030301010902060607" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:13:13 -0000 This is a cryptographically signed message in MIME format. --------------ms030704030301010902060607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, this is exactly what we do in XMPP. On 4/8/10 9:08 AM, Salvatore Loreto wrote: > Hi Paul, >=20 > the use case you have written down is exactly the one I have in mind an= d > was going to send to this ml. >=20 > I want add one more benefit in knowing all the capabilities of the > different Bob devices in advance and > not just of one device. > An OPTIONS response (or another mechanism!) that contains a level of > granularity that let Alice (or rather Alices device) > know that Bob can take only audio on one device, but > audio/video/text/picture on his other device (as describe in Paul use > case), > would help Alice's device understand that starting a voice session with= > only voice Bob device, there is no way a re-INVITE to add video would w= ork; > so if she thinks that a voice call could be then transformed in a > voice+video, she knows that should contact directly the > audio/video/text/picture device. >=20 > cheers > Sal >=20 >=20 > On 4/8/10 4:01 PM, Paul Kyzivat wrote: >> [as individual] >> >> It seems that Christer has come close to offering a use case, even if >> that was not his intent. And its still a little incomplete. I'll try t= o >> fill it out a bit: >> >> Alice wants to call Bob. >> Her phone app first queries Bob's AOR with OPTIONS. >> The response to that is a 3xx with Contact URIs for >> Bob's home phone and his mobile phone. So Alice's phone >> sends additional OPTIONS requests to each of those. >> From the responses it learns that Bob's mobile phone support >> audio and video, while his home phone (behind a pstn gateway) >> only supports audio. >> >> Alice has video support on her phone, and since Bob may be able to >> support video too, decides to make an audio+video call. The >> phone sends an INVITE with both, and caller preferences indicating >> a preference for audio+video. >> >> The INVITE reaches the server handling Bob's AOR. >> It processes the callerprefs, and so decides to initially send the >> invite to Bob's mobile phone. But there is no answer there, so >> the server forks the invite toward Bob's home phone. Bob answers that >> one, accepting the audio and rejecting the video. >> >> The result of this is exactly the same as if no OPTIONS was ever sent,= >> and the INVITE was sent indicating Alice's own preferences. That is th= e >> point that John already made. >> >> The only "benefit" I can see from use of options here would be if it w= as >> discovered that Bob had no video support. In that case, the invite cou= ld >> have been sent without offering video. Is that advantageous? Does it >> cost more to initiate a call that offers video? Does it take more >> network resources to do so, even when ultimately the video is rejected= ? >> >> The only real benefit I can see to this is if the calling user is give= n >> an enhanced user interface - akin to what one gets with buddy lists - >> where there is a display showing that Bob has two devices with differi= ng >> capabilities, with Alice having the option to choose one or allowing t= he >> phone to make the choice. >> >> To provide that feature, presence would be a much better choice. >> OPTIONS is in a sense "poor man's presence". Christer has mentioned th= at >> he considers presence to be too "heavy weight" for this, but I remain = to >> be convinced of that. Perhaps maintaining persistent subscriptions to >> presence status of everyone you might possibly call is too heavy weigh= t, >> but doing a polling subscription prior to a call won't be any heavier >> than all this options stuff. >> >> It may be that lots of devices don't publish presence state. But that >> can be solved in many ways. A registrar can synthesize basic presence >> state from registration data. And it could even use OPTIONS to refine >> that. >> >> I suspect the real hidden issue here is about presence, and so I'd >> prefer to see it addressed from that direction. If that in turn leads = to >> a desire to use OPTIONS to get some degree of presence state from >> devices that don't otherwise publish it, then lets confront it in that= >> context. And if the issue is that presence is typically not authorized= >> for as many requesters as OPTIONS is, then lets look at possible polic= y >> recommendations in that regard. >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >> =20 >>> Hi, >>> >>> =20 >>>> > From my perspective, the main use-case is not to discover services= , >>>> =20 >>>>> but to discover capabilities in order to determine what services >>>>> can be applied. >>>>> >>>>> The idea is also that the OPTIONS request would be sent prior to th= e >>>>> INVITE, to try to make sure that the returned contacts are actually= >>>>> available. >>>>> =20 >>>> But you know that would never work in practice/the-real-world. Think= >>>> about all the routing rules >>>> people have for INVITEs - in some cases *only* for INVITEs. >>>> And even if they route OPTIONS identically in the SIP domain, >>>> for any given AoR it'll go to any of: a SIP UA, or a PSTN >>>> gateway, or a H.323-gateway, or an MGCP call-agent, or an >>>> IP-PBX, or a foobar-protocol-gateway, or a vmail server, or >>>> an announcement server, or an app server, etc. Just because >>>> the OPTIONS reaches the end of the SIP domain, means nothing >>>> about whether an INVITE to the higher-layer target (which in >>>> practice is a E.164 number, that crosses from SIP into many >>>> other protocol domains) is actually available to receive a call. >>>> =20 >>> The assumption is that the OPTIONS request reaches the registrar, >>> that returns the registered contacts. It is never forwarded to any UA= S. >>> >>> Then, at some point an INVITE is sent, and it is addressed to the >>> same AOR (the INVITE request might be routed differently than the >>> OPTIONS request). Based on the UAS information, the INVITE may now >>> contain feature tags etc that indicates a wish to reach an UAS with >>> certain capabilities. >>> >>> Now, unless the INVITE is addressed to a specific UAS, it can of >>> course not be guranteed that the INVITE will actually reach such UAS.= >>> But, that is a "feature" of RFC 3841, and it would be the case even >>> if you had never sent any OPTIONS. What OPTIONS allows provides you >>> is capability information about the UAS(s) associated with the AOR, >>> which might be useful when sending the INVITE. >>> >>> No, it does not guarantee that the user is available - it only >>> provides you with that same information as OPTIONS in a non-forking >>> case does. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> --------------ms030704030301010902060607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwODE1MTMwNFowIwYJKoZIhvcNAQkEMRYEFKkBTij1RoQhZb9lhBKF 6BWhz2L8MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAL//DsaIU0eKzyXiK6XkHbgDYWgLVpInyHmFTeDNy rXD1PY4mNaLYde8f8gRY+ULknbRdLTJ+Fcwn5Y12pTcwb8AaX49mQk3JANxoAXbbNEltNWJg VbrwRz33eF+rfwixddJHNAOc0z9t5R/rsaa7+QxU7rXzykxJhHLHTuFz0CEE37QgwZ8cT7qQ UD0qBVsx/uqDHCDxYwJTuYisHRMCUDzye/09EAjwfTchBHZizM8MYS6mGXDfS75F4hqc5aPK T28ax+Dy2zbRuIeILS41y3vpqUbQ/nv29j0ysB/NoPzoEiGKSlLQHJqwnCZdMVZu4kfDNIIF 4XouUt+5FowyjQAAAAAAAA== --------------ms030704030301010902060607-- From pkyzivat@cisco.com Thu Apr 8 08:37:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A363E3A6AB0 for ; Thu, 8 Apr 2010 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIY959bEZQKO for ; Thu, 8 Apr 2010 08:37:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 167433A6AB5 for ; Thu, 8 Apr 2010 08:36:22 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABCUvUtAZnwM/2dsb2JhbACbNHGgcpksglwOCIIXBA X-IronPort-AV: E=Sophos;i="4.52,171,1270425600"; d="scan'208";a="100072301" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2010 15:36:18 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o38FaIee002496; Thu, 8 Apr 2010 15:36:18 GMT Message-ID: <4BBDF7EE.2050204@cisco.com> Date: Thu, 08 Apr 2010 11:36:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Salvatore Loreto References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <4BBDE1A0.5050603@cisco.com> <4BBDF184.6060806@ericsson.com> In-Reply-To: <4BBDF184.6060806@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:37:05 -0000 [as individual] Salvatore Loreto wrote: > Hi Paul, > > the use case you have written down is exactly the one I have in mind and > was going to send to this ml. > > I want add one more benefit in knowing all the capabilities of the > different Bob devices in advance and > not just of one device. > An OPTIONS response (or another mechanism!) that contains a level of > granularity that let Alice (or rather Alices device) > know that Bob can take only audio on one device, but > audio/video/text/picture on his other device (as describe in Paul use > case), > would help Alice's device understand that starting a voice session with > only voice Bob device, there is no way a re-INVITE to add video would work; > so if she thinks that a voice call could be then transformed in a > voice+video, she knows that should contact directly the > audio/video/text/picture device. If this kind of feature is desired, then lets spell that out and discuss alternative ways of achieving that result. The original sip philosophy was that choice of device to respond to a request is a policy decision to be made by the server responsible for the AOR. It might take the wishes of the caller into account but that is still based on callee policy. Presence turns that on its head. In the presence model, the "caller" is given a menu by the callee, and allowed to choose. Since that is what you seem to wish, I think presence is where to start in looking for a solution. As an aside, if I have a video device that can be added into the current (audio) call, then *I* want to be the one that makes that decision. I find the idea of having the caller do it a bit creepy. Thanks, Paul > cheers > Sal > > > On 4/8/10 4:01 PM, Paul Kyzivat wrote: >> [as individual] >> >> It seems that Christer has come close to offering a use case, even if >> that was not his intent. And its still a little incomplete. I'll try to >> fill it out a bit: >> >> Alice wants to call Bob. >> Her phone app first queries Bob's AOR with OPTIONS. >> The response to that is a 3xx with Contact URIs for >> Bob's home phone and his mobile phone. So Alice's phone >> sends additional OPTIONS requests to each of those. >> From the responses it learns that Bob's mobile phone support >> audio and video, while his home phone (behind a pstn gateway) >> only supports audio. >> >> Alice has video support on her phone, and since Bob may be able to >> support video too, decides to make an audio+video call. The >> phone sends an INVITE with both, and caller preferences indicating >> a preference for audio+video. >> >> The INVITE reaches the server handling Bob's AOR. >> It processes the callerprefs, and so decides to initially send the >> invite to Bob's mobile phone. But there is no answer there, so >> the server forks the invite toward Bob's home phone. Bob answers that >> one, accepting the audio and rejecting the video. >> >> The result of this is exactly the same as if no OPTIONS was ever sent, >> and the INVITE was sent indicating Alice's own preferences. That is the >> point that John already made. >> >> The only "benefit" I can see from use of options here would be if it was >> discovered that Bob had no video support. In that case, the invite could >> have been sent without offering video. Is that advantageous? Does it >> cost more to initiate a call that offers video? Does it take more >> network resources to do so, even when ultimately the video is rejected? >> >> The only real benefit I can see to this is if the calling user is given >> an enhanced user interface - akin to what one gets with buddy lists - >> where there is a display showing that Bob has two devices with differing >> capabilities, with Alice having the option to choose one or allowing the >> phone to make the choice. >> >> To provide that feature, presence would be a much better choice. >> OPTIONS is in a sense "poor man's presence". Christer has mentioned that >> he considers presence to be too "heavy weight" for this, but I remain to >> be convinced of that. Perhaps maintaining persistent subscriptions to >> presence status of everyone you might possibly call is too heavy weight, >> but doing a polling subscription prior to a call won't be any heavier >> than all this options stuff. >> >> It may be that lots of devices don't publish presence state. But that >> can be solved in many ways. A registrar can synthesize basic presence >> state from registration data. And it could even use OPTIONS to refine >> that. >> >> I suspect the real hidden issue here is about presence, and so I'd >> prefer to see it addressed from that direction. If that in turn leads to >> a desire to use OPTIONS to get some degree of presence state from >> devices that don't otherwise publish it, then lets confront it in that >> context. And if the issue is that presence is typically not authorized >> for as many requesters as OPTIONS is, then lets look at possible policy >> recommendations in that regard. >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >> >>> Hi, >>> >>> >>>> > From my perspective, the main use-case is not to discover services, >>>> >>>>> but to discover capabilities in order to determine what services >>>>> can be applied. >>>>> >>>>> The idea is also that the OPTIONS request would be sent prior to the >>>>> INVITE, to try to make sure that the returned contacts are actually >>>>> available. >>>>> >>>> But you know that would never work in practice/the-real-world. Think >>>> about all the routing rules >>>> people have for INVITEs - in some cases *only* for INVITEs. >>>> And even if they route OPTIONS identically in the SIP domain, >>>> for any given AoR it'll go to any of: a SIP UA, or a PSTN >>>> gateway, or a H.323-gateway, or an MGCP call-agent, or an >>>> IP-PBX, or a foobar-protocol-gateway, or a vmail server, or >>>> an announcement server, or an app server, etc. Just because >>>> the OPTIONS reaches the end of the SIP domain, means nothing >>>> about whether an INVITE to the higher-layer target (which in >>>> practice is a E.164 number, that crosses from SIP into many >>>> other protocol domains) is actually available to receive a call. >>>> >>> The assumption is that the OPTIONS request reaches the registrar, >>> that returns the registered contacts. It is never forwarded to any UAS. >>> >>> Then, at some point an INVITE is sent, and it is addressed to the >>> same AOR (the INVITE request might be routed differently than the >>> OPTIONS request). Based on the UAS information, the INVITE may now >>> contain feature tags etc that indicates a wish to reach an UAS with >>> certain capabilities. >>> >>> Now, unless the INVITE is addressed to a specific UAS, it can of >>> course not be guranteed that the INVITE will actually reach such UAS. >>> But, that is a "feature" of RFC 3841, and it would be the case even >>> if you had never sent any OPTIONS. What OPTIONS allows provides you >>> is capability information about the UAS(s) associated with the AOR, >>> which might be useful when sending the INVITE. >>> >>> No, it does not guarantee that the user is available - it only >>> provides you with that same information as OPTIONS in a non-forking >>> case does. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> > > From HKaplan@acmepacket.com Thu Apr 8 10:33:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20153A68B6 for ; Thu, 8 Apr 2010 10:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEN+FNgVBqIH for ; Thu, 8 Apr 2010 10:33:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4C9BE3A6A81 for ; Thu, 8 Apr 2010 10:31:22 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 13:31:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 13:31:18 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Christer Holmberg Date: Thu, 8 Apr 2010 13:31:17 -0400 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrXI/xHOtx7tuH6QfuclQUbyZMgQQAHG34A Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D2E4@mail> References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <4BBDE1A0.5050603@cisco.com> In-Reply-To: <4BBDE1A0.5050603@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: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:33:32 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 08, 2010 10:01 AM >=20 > The only "benefit" I can see from use of options here would be if it was > discovered that Bob had no video support. In that case, the invite could > have been sent without offering video. Is that advantageous? Does it > cost more to initiate a call that offers video? Does it take more > network resources to do so, even when ultimately the video is rejected? Well... when you put it that way, there is actually a small advantage. In = many resource reservation deployments the INVITE would be rejected if there= isn't sufficient bandwidth for the highest-bitrate codec or the aggregate = of all offered medias. Afaict this is due to either bad design, or the pro= tocols being used to policy servers which can't really handle an if-else-el= se type reservation model. So in theory the INVITE would succeed had Alice only asked for audio. But there are so many other policy decisions involved that it's a crap-shoo= t anyway, no matter how much info you give the UAC. -hadriel From adam@nostrum.com Thu Apr 8 11:07:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FE83A69C7 for ; Thu, 8 Apr 2010 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLn65dJdY2wu for ; Thu, 8 Apr 2010 11:07:01 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0CEC53A694A for ; Thu, 8 Apr 2010 11:06:59 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38I6rPh080139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 13:06:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE1B3D.5090602@nostrum.com> Date: Thu, 08 Apr 2010 13:06:53 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brett Tate References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480C55EB5@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C55EB5@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:07:02 -0000 On 4/7/10 7:08 AM, Brett Tate wrote: > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, April 06, 2010 7:37 PM >> To: Brett Tate >> Cc: Paul Kyzivat; SIPCORE >> Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes >> Posted] >> >> On 4/6/10 17:46, Apr 6, Brett Tate wrote: >> >>>> Is there *any* problem here? This seems to be working about >>>> as well as anyone might hope. >>>> >>>> >>> It works okay excluding the non backward compatibility with RFC 3265 >>> >> (concerning SUBSCRIBE's 2xx response impacts)... >> >> I don't think it's accurate to characterize the change as >> non-backwards-compatible. >> > RFC 3265 section 3.3.4 indicates that 2xx "creates a new subscription and a new dialog"; rfc3265bis does not allow such a thing. > Yes, it's a *change*, but it's a *backwards* *compatible* change. /a From adam@nostrum.com Thu Apr 8 11:11:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEC23A69C5 for ; Thu, 8 Apr 2010 11:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcsKyC88MV5q for ; Thu, 8 Apr 2010 11:11:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 08DCB3A68F1 for ; Thu, 8 Apr 2010 11:11:08 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38IB0Xq080496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 13:11:01 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE1C34.10105@nostrum.com> Date: Thu, 08 Apr 2010 13:11:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brett Tate References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC1CB.4050501@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55EC4@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C55EC4@EXMBXCLUS01.citservers.local> Content-Type: multipart/alternative; boundary="------------060405030809060004080001" Cc: SIPCORE Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:11:14 -0000 This is a multi-part message in MIME format. --------------060405030809060004080001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/7/10 7:26 AM, Brett Tate wrote: >> Then what would happen in a polling subscribe (Expires:0) if >> the 200 is received and the NOTIFY is not received? How long >> should you wait before giving up? ISTM you still need timer-N >> to tell you it failed, so you can give up waiting. >> > I agree that you need a Timer N (or something like it); however Timer N should not be restricted to 64*T1. The rfc3265bis should accommodate other Timer N values instead being restricted to 64*T1 for all event packages, deployments, situations, etcetera. > Sure, we can enter into a discussion of how to set Timer N. But, to fix the problems that we had in 3265, any changes really need to be predicated on two qualities: 1. Everyone involved in the transaction needs to know what value Timer N has -- otherwise, you can easily end up with differing ideas of dialog and subscription state. 2. Variation in Timer N can't be based on a mechanism to withhold the initial NOTIFY message for an arbitrary (or even a relatively long) period of time. NOTIFY is an important part of the 3-way handshake used to set up a dialog, and extensions can reasonable make assumptions around this completing in a reasonable amount of time (3265 defines this as "immediately"). /a --------------060405030809060004080001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/7/10 7:26 AM, Brett Tate wrote: 
Then what would happen in a polling subscribe (Expires:0) if 
the 200 is received and the NOTIFY is not received? How long 
should you wait before giving up? ISTM you still need timer-N 
to tell you it failed, so you can give up waiting.
    
I agree that you need a Timer N (or something like it); however Timer N should not be restricted to 64*T1.  The rfc3265bis should accommodate other Timer N values instead being restricted to 64*T1 for all event packages, deployments, situations, etcetera.

Sure, we can enter into a discussion of how to set Timer N. But, to fix the problems that we had in 3265, any changes really need to be predicated on two qualities:
  1. Everyone involved in the transaction needs to know what value Timer N has -- otherwise, you can easily end up with differing ideas of dialog and subscription state.

  2. Variation in Timer N can't be based on a mechanism to withhold the initial NOTIFY message for an arbitrary (or even a relatively long) period of time. NOTIFY is an important part of the 3-way handshake used to set up a dialog, and extensions can reasonable make assumptions around this completing in a reasonable amount of time (3265 defines this as "immediately").
/a
--------------060405030809060004080001-- From adam@nostrum.com Thu Apr 8 11:14:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAF33A695B for ; Thu, 8 Apr 2010 11:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t88O5gpbM2eR for ; Thu, 8 Apr 2010 11:14:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8915E3A6930 for ; Thu, 8 Apr 2010 11:14:49 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38IEgc4080734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 13:14:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE1D12.5090509@nostrum.com> Date: Thu, 08 Apr 2010 13:14:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:14:51 -0000 On 4/8/10 1:48 AM, Christer Holmberg wrote: > Hi, > > Also, both 3265 and 3265bis contains the following text: > > "A subscriber may send a SUBSCRIBE request with an "Expires" header > field of 0 in order to trigger the sending of such a NOTIFY > request; however, for the purposes of subscription and dialog > lifetime, the subscription is not considered terminated until the > NOTIFY transaction with a "Subscription-State" of "terminated" > completes." > Yes. The fixes to specifically accommodate subnot-etags are not in the current version of the document. This will all be addressed in a future version of the draft. /a From adam@nostrum.com Thu Apr 8 11:22:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF7B3A69B6 for ; Thu, 8 Apr 2010 11:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+2uo6Ty9ANS for ; Thu, 8 Apr 2010 11:22:24 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5FD7A3A67EF for ; Thu, 8 Apr 2010 11:21:45 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38ILdiE081275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 13:21:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE1EB3.7060302@nostrum.com> Date: Thu, 08 Apr 2010 13:21:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brett Tate References: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:22:28 -0000 [as chair] On 4/8/10 7:36 AM, Brett Tate wrote: > Since it was raised within rfc3265bis discussion, I thought that I'd attempt to get clarity concerning RFC 4320's deprecation of non-INVITE 408 responses in case errata should be opened against RFC 4320. > > RFC 4320 intentionally or unintentionally appears to have deprecated all non-INVITE 408 responses. It was intentional, AFAIK. > However I thought that I'd still ask, is the deprecation only applicable for Timer F expiration type situations (i.e. the reason for the deprecation)? > That's a good question -- perhaps Robert can weigh in on this. > If not limited to Timer F expiration type situations, such a deprecation causes some ambiguity concerning shorter timeouts on other interfaces. For instance, a received SUBSCRIBE is transformed into another protocol's FOO message. The FOO transaction delivery expires after 1 second. Can a 408 response (although 504 might be better per rfc3261) be sent for the SUBSCRIBE? What about a B2BUA which using a short expiration (like 1 second) on the send side; can it send a 408 response or must it really start sending 504 or other response instead? > /a From adam@nostrum.com Thu Apr 8 11:27:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B203A696D for ; Thu, 8 Apr 2010 11:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1iLDLEYfVzA for ; Thu, 8 Apr 2010 11:27:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 147053A69DC for ; Thu, 8 Apr 2010 11:27:26 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38IRBK3081774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 13:27:11 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE1FFF.3090507@nostrum.com> Date: Thu, 08 Apr 2010 13:27:11 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <4BBDE1A0.5050603@cisco.com> In-Reply-To: <4BBDE1A0.5050603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:27:32 -0000 [as individual] On 4/8/10 9:01 AM, Paul Kyzivat wrote: > [as individual] > > It seems that Christer has come close to offering a use case, even if > that was not his intent. And its still a little incomplete. I'll try > to fill it out a bit: > > ... > > To provide that feature, presence would be a much better choice. *ding* *ding* *ding* We have an answer! That's why I'm asking for use cases. Every use case *I* can come up with is better suited for something like presence, callerprefs, etc. Now, Christer clearly has some problem he's trying to solve. If he'd just describe the problem in terms of a use case (instead of "forking breaks OPTIONS"), then I think we could make some progress. I'm not saying that the answer won't be OPTIONS, simply that a concise statement of the use case(s) that need to be supported is likely to make it clearer to everyone what kind of solution is actually called for. /a From adam@nostrum.com Thu Apr 8 11:29:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3DD3A69B6 for ; Thu, 8 Apr 2010 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbDrLSq+0nHP for ; Thu, 8 Apr 2010 11:29:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7316D3A6930 for ; Thu, 8 Apr 2010 11:29:28 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38ITE8F081918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 13:29:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE207A.2020704@nostrum.com> Date: Thu, 08 Apr 2010 13:29:14 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com> In-Reply-To: <4BBDE58B.6040100@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:29:39 -0000 [as individual] On 4/8/10 9:17 AM, Paul Kyzivat wrote: > [as individual] > > Christer Holmberg wrote: >> Hi, >> >> In the case of DE-subscriptions (which is just one variant of >> re-subscription), I still think there are some issues regarding >> whether the SUB 200 or the NOT req acknowledges the SUB req. >> >> Assuming the sub dialog is terminated when an entity receives a SUB >> 200 that contains 'Expires: 0'. >> >> Now, if there is then a NOT request (that contains >> 'Subscription-State: terminated'), won't it be treated as an >> out-of-dialog request, and rejected? > > That scenario has always bothered me. When my purpose is simply to > request the termination of the existing dialog, and I have no further > interest in the state, is there any reason for the NOTIFY? Can it be > suppressed? Yes. RFC 5839 (which will be published shortly) -- more widely known as subnot-etags -- will provide exactly the mechanism to perform this suppression. /a From rjsparks@nostrum.com Thu Apr 8 11:52:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E369F3A6AB8 for ; Thu, 8 Apr 2010 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcnMJzrCXZsV for ; Thu, 8 Apr 2010 11:52:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B229B3A6AB2 for ; Thu, 8 Apr 2010 11:52:57 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-51-142.dllstx.fios.verizon.net [173.71.51.142]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38IqovV083696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Apr 2010 13:52:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-26-387794322 From: Robert Sparks In-Reply-To: <4BBE1EB3.7060302@nostrum.com> Date: Thu, 8 Apr 2010 13:52:50 -0500 Message-Id: <9B2142E4-E751-459F-B4A6-A16F8C4F2A89@nostrum.com> References: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> <4BBE1EB3.7060302@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: SIPCORE Subject: Re: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:52:59 -0000 --Apple-Mail-26-387794322 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 8, 2010, at 1:21 PM, Adam Roach wrote: > [as chair] >=20 > On 4/8/10 7:36 AM, Brett Tate wrote: >> Since it was raised within rfc3265bis discussion, I thought that I'd = attempt to get clarity concerning RFC 4320's deprecation of non-INVITE = 408 responses in case errata should be opened against RFC 4320. >>=20 >> RFC 4320 intentionally or unintentionally appears to have deprecated = all non-INVITE 408 responses. >=20 > It was intentional, AFAIK. It was quite intentional. >=20 >> However I thought that I'd still ask, is the deprecation only = applicable for Timer F expiration type situations (i.e. the reason for = the deprecation)? >> =20 >=20 > That's a good question -- perhaps Robert can weigh in on this. 408's semantics in 3261 are clearly bound to the transaction machinery. = The other cases you are describing should use a different response code. >=20 >=20 >=20 >> If not limited to Timer F expiration type situations, such a = deprecation causes some ambiguity concerning shorter timeouts on other = interfaces. For instance, a received SUBSCRIBE is transformed into = another protocol's FOO message. The FOO transaction delivery expires = after 1 second. Can a 408 response (although 504 might be better per = rfc3261) be sent for the SUBSCRIBE? What about a B2BUA which using a = short expiration (like 1 second) on the send side; can it send a 408 = response or must it really start sending 504 or other response instead? >> =20 >=20 >=20 > /a --Apple-Mail-26-387794322 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[as = chair]

On 4/8/10 7:36 AM, Brett Tate wrote:
Since it was raised within rfc3265bis discussion, I = thought that I'd attempt to get clarity concerning RFC 4320's = deprecation of non-INVITE 408 responses in case errata should be opened = against RFC 4320.

RFC 4320 = intentionally or unintentionally appears to have deprecated all = non-INVITE 408 responses.

It was intentional, = AFAIK.

It was quite = intentional.


  However I thought that I'd still ask, is the = deprecation only applicable for Timer F expiration type situations (i.e. = the reason for the deprecation)?
  

That's a good question = -- perhaps Robert can weigh in on this.
408's = semantics in 3261 are clearly bound to the transaction machinery. The = other cases you are describing should use a different response = code.




If not = limited to Timer F expiration type situations, such a deprecation causes = some ambiguity concerning shorter timeouts on other interfaces. =  For instance, a received SUBSCRIBE is transformed into another = protocol's FOO message.  The FOO transaction delivery expires after = 1 second.  Can a 408 response (although 504 might be better per = rfc3261) be sent for the SUBSCRIBE?  What about a B2BUA which using = a short expiration (like 1 second) on the send side; can it send a 408 = response or must it really start sending 504 or other response = instead?
=   


/a

= --Apple-Mail-26-387794322-- From christer.holmberg@ericsson.com Thu Apr 8 12:32:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A303A67E7 for ; Thu, 8 Apr 2010 12:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df0X9zm3MKIW for ; Thu, 8 Apr 2010 12:32:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C4AFD3A6B1E for ; Thu, 8 Apr 2010 12:31:59 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-21-4bbe2f2af000 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DA.63.23740.A2F2EBB4; Thu, 8 Apr 2010 21:31:55 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 8 Apr 2010 21:31:54 +0200 From: Christer Holmberg To: Adam Roach , Paul Kyzivat Date: Thu, 8 Apr 2010 21:31:54 +0200 Thread-Topic: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] Thread-Index: AcrXSW28l1Tx7NZPSkmmML/nkDAWUAABuWXk Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com>,<4BBE207A.2020704@nostrum.com> In-Reply-To: <4BBE207A.2020704@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:32:18 -0000 Hi, >>> In the case of DE-subscriptions (which is just one variant of >>> re-subscription), I still think there are some issues regarding >>> whether the SUB 200 or the NOT req acknowledges the SUB req. >>> >>> Assuming the sub dialog is terminated when an entity receives a SUB >>> 200 that contains 'Expires: 0'. >>> >>> Now, if there is then a NOT request (that contains >>> 'Subscription-State: terminated'), won't it be treated as an >>> out-of-dialog request, and rejected? >> >> That scenario has always bothered me. When my purpose is simply to >> request the termination of the existing dialog, and I have no further >> interest in the state, is there any reason for the NOTIFY? Can it be >> suppressed? > >Yes. RFC 5839 (which will be published shortly) -- more widely known as >subnot-etags -- will provide exactly the mechanism to perform this >suppression. But again, stateful intermediaries that do not support subnot will wait for= the NOTIFY. Regards, Christer= From christer.holmberg@ericsson.com Thu Apr 8 12:34:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297253A6943 for ; Thu, 8 Apr 2010 12:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.324 X-Spam-Level: X-Spam-Status: No, score=-5.324 tagged_above=-999 required=5 tests=[AWL=1.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc-tbmPdo-28 for ; Thu, 8 Apr 2010 12:34:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BF40F3A6B13 for ; Thu, 8 Apr 2010 12:34:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-9c-4bbe2fc8501e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 75.A6.23532.8CF2EBB4; Thu, 8 Apr 2010 21:34:32 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Apr 2010 21:34:31 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , Hans Erik van Elburg Date: Thu, 8 Apr 2010 21:32:22 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrWM0qiApcMRDWjQ9KlnT8XmUciDwACStoAAAFSI4AAAChPQAADmpJgAABcR5AAAL6EcAAq+I2AAAGfQTAAEqhj5w== Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> , <430FC6BDED356B4C8498F634416644A91A79F3D1E0@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D1E0@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:34:40 -0000 Hi Hadriel, I don't think documenting the O-3xx mechanism would require much work. And,= as some have indicated, it might even be done as an individual draft. Then, if we don't think OPTIONS is good enough in the first place, and want= to define some other procedure, which actually requires some work, the sit= uation is different. But, I have not suggested that. Regards, Christer ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] Sent: Thursday, April 08, 2010 1:44 PM To: Christer Holmberg; Elwell, John; Hans Erik van Elburg Cc: WORLEY, DALE R (DALE); sipcore@ietf.org Subject: RE: [sipcore] SIP OPTIONS: Shall we work on this? Hi Christer, I know you're frustrated we keep going back to a use-case, but you're askin= g for consensus on whether people are interested in working on the solution= . Without an actual use-case, how can we do that? Why would people agree = to spend time on something they don't see any use for solving? -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Thursday, April 08, 2010 6:13 AM > To: Elwell, John; Hans Erik van Elburg > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? > > > Hi, > > >[JRE] But even if you then target the INVITE request at the > >GRUU of the preferred user, there is no guarantee it will > >succeed (e.g., no media resources, UA has become busy in the > >meantime), and because it is targeted directly, you lose the > >opportunity to take alternative action, e.g., forwarding to > >voicemail or to another UA with similar capabilities. It is a > >case of the calling user trying to override policies > >associated with the called user, which I think is a bad > >thing. The result of the OPTIONS request can only ever act as > >a guideline - it is effectively no better than presence. > > > >It would be helpful to have a concrete example of something > >that could go into an INVITE request targeted at a particular > >UA known to have a particular capability, that could not go > >into an INVITE request targeted at the AOR and with caller > >preferences RECOMMENDING selection of a UA with that > >particular capability. Apologies if such an example has > >already been given earlier in the discussion. > > I don't think I have said that the INVITE would necessarily be targeted t= o > a particular UA. There MAY of course be use-cases where you would target > also the INVITE to a specific UAS. For example, if an UAS supports a > specific capability, and you don't want the call to proceed unless that > UAS accepts the INVITE. Then, if the INVITE fails, it may still be > possible for the call to be forwarded to a voice mail etc, depending on > policies and service design in the network. > > But, the main point of the O-3xx mechanisms is that it allows you to > target *OPTIONS* request to particular UAs, in order to get the > capabilities of those. > > That is the only thing the mechanism is supposed to provide. What you the= n > do with that information is a separate issue, and that seems to be what > the discussion is now about. > > Now, we can discuss use-cases etc, but I just want to make it clear that > the O-3xx mechanism itself does not make any assumptions regarding use- > cases. It only allows the usage of OPTIONS in forking scenarios - nothing > more, nothing less. Apart from providing a way to deal with the forking > issue, it does not solve any other issues, bugs or shortcomings there may > be with OPTIONS. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore= From brett@broadsoft.com Thu Apr 8 12:46:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084EC28C121 for ; Thu, 8 Apr 2010 12:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOKQOaSebU3S for ; Thu, 8 Apr 2010 12:46:58 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 390BA28C10F for ; Thu, 8 Apr 2010 12:46:58 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 8 Apr 2010 12:46:54 -0700 From: Brett Tate To: Robert Sparks , Adam Roach , SIPCORE Date: Thu, 8 Apr 2010 12:46:06 -0700 Thread-Topic: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses Thread-Index: AcrXTLLR88dfcytIRX672c7n3piHdwAAYpDA Message-ID: <747A6506A991724FB09B129B79D5FEB61480CDBE4D@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> <4BBE1EB3.7060302@nostrum.com> <9B2142E4-E751-459F-B4A6-A16F8C4F2A89@nostrum.com> In-Reply-To: <9B2142E4-E751-459F-B4A6-A16F8C4F2A89@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:46:59 -0000 > 408's semantics in 3261 are clearly bound to the transaction=20 > machinery. The other cases you are describing should use a=20 > different response code. If 408's semantics were so clear, I'd think RFC 3398, B2BUAs, and etcetera = would not have generated or documented to generate a 408 response based upo= n another interfaces timeouts or receipt of 408. Should errata be opened against RFC 3398? Thanks for the response, Brett From pkyzivat@cisco.com Thu Apr 8 12:57:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EC428C168 for ; Thu, 8 Apr 2010 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.347 X-Spam-Level: X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzRa1f6dp8Lg for ; Thu, 8 Apr 2010 12:57:37 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C2BC33A698D for ; Thu, 8 Apr 2010 12:57:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGPSvUtAZnwN/2dsb2JhbACbOHGiJpk1hQkE X-IronPort-AV: E=Sophos;i="4.52,172,1270425600"; d="scan'208";a="100152853" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2010 19:57:33 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o38JvXYx019475; Thu, 8 Apr 2010 19:57:33 GMT Message-ID: <4BBE3533.7010402@cisco.com> Date: Thu, 08 Apr 2010 15:57:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com> <4BBE207A.2020704@nostrum.com> In-Reply-To: <4BBE207A.2020704@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:57:37 -0000 [as individual] Its good that subnot-etags will help with this. But support for that will be optional, and it may not even make sense for some event packages. Yet not wanting the notify when ending the subscription can make sense for all event packages. Is there a way that packages that support subnot-etags just for the "I don't want to see anything" case, without the complexity and bother of supporting for anything else? Thanks, Paul Adam Roach wrote: > [as individual] > > On 4/8/10 9:17 AM, Paul Kyzivat wrote: >> [as individual] >> >> Christer Holmberg wrote: >>> Hi, >>> >>> In the case of DE-subscriptions (which is just one variant of >>> re-subscription), I still think there are some issues regarding >>> whether the SUB 200 or the NOT req acknowledges the SUB req. >>> >>> Assuming the sub dialog is terminated when an entity receives a SUB >>> 200 that contains 'Expires: 0'. >>> >>> Now, if there is then a NOT request (that contains >>> 'Subscription-State: terminated'), won't it be treated as an >>> out-of-dialog request, and rejected? >> >> That scenario has always bothered me. When my purpose is simply to >> request the termination of the existing dialog, and I have no further >> interest in the state, is there any reason for the NOTIFY? Can it be >> suppressed? > > Yes. RFC 5839 (which will be published shortly) -- more widely known as > subnot-etags -- will provide exactly the mechanism to perform this > suppression. > > /a > From adam@nostrum.com Thu Apr 8 13:02:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBCB3A6A10 for ; Thu, 8 Apr 2010 13:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfSDEV8-fIx4 for ; Thu, 8 Apr 2010 13:02:33 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D45583A6A16 for ; Thu, 8 Apr 2010 13:02:32 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38K2OB5088340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 15:02:25 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBE3650.4090908@nostrum.com> Date: Thu, 08 Apr 2010 15:02:24 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com> <4BBE207A.2020704@nostrum.com> <4BBE3533.7010402@cisco.com> In-Reply-To: <4BBE3533.7010402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:02:34 -0000 [as individual] On 4/8/10 2:57 PM, Paul Kyzivat wrote: > [as individual] > > Its good that subnot-etags will help with this. > But support for that will be optional... Which is pretty much true of anything we define after the fact. Horses have left the barn, etc. > ...and it may not even make sense for some event packages. I think you'll have a hard time coming up with an example of an entire event package for which etags doesn't make sense. > Is there a way that packages that support subnot-etags just for the "I > don't want to see anything" case, without the complexity and bother of > supporting for anything else? Not for the server. The client can blindly do a "Suppress-If-Match: *" on unsubscribe and not worry about the etag mechanism otherwise. /a From pkyzivat@cisco.com Thu Apr 8 13:13:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130BA3A687B for ; Thu, 8 Apr 2010 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.362 X-Spam-Level: X-Spam-Status: No, score=-10.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4flM0k5EofV9 for ; Thu, 8 Apr 2010 13:13:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A38423A6A93 for ; Thu, 8 Apr 2010 13:13:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPLVvUtAZnwN/2dsb2JhbACbOXGiRpkzhQkE X-IronPort-AV: E=Sophos;i="4.52,172,1270425600"; d="scan'208";a="100019056" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2010 20:13:29 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o38KDT8h025075; Thu, 8 Apr 2010 20:13:29 GMT Message-ID: <4BBE38F3.3010101@cisco.com> Date: Thu, 08 Apr 2010 16:13:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com>, <4BBE207A.2020704@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:13:56 -0000 [as individual] Christer Holmberg wrote: > But again, stateful intermediaries that do not support subnot will wait for the NOTIFY. Are you aware of any *proxies* that are dialog stateful for sub/not? (Its not an issue for B2BUAs since they must support it for the two ends to use it.) If so, is there really some good reason for them to be doing so? Thanks, Paul From christer.holmberg@ericsson.com Thu Apr 8 13:14:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF55D3A6942 for ; Thu, 8 Apr 2010 13:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yz6t8-N+Ohm for ; Thu, 8 Apr 2010 13:14:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 502BF3A6AB9 for ; Thu, 8 Apr 2010 13:13:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-5f-4bbe38f9c988 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9A.08.23532.9F83EBB4; Thu, 8 Apr 2010 22:13:45 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 8 Apr 2010 22:13:45 +0200 From: Christer Holmberg To: Adam Roach , Paul Kyzivat Date: Thu, 8 Apr 2010 22:13:45 +0200 Thread-Topic: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] Thread-Index: AcrXVmunzYfkhF6IT7OfaeIejb03UgAAN2E9 Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com> <4BBE207A.2020704@nostrum.com> <4BBE3533.7010402@cisco.com>,<4BBE3650.4090908@nostrum.com> In-Reply-To: <4BBE3650.4090908@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:14:20 -0000 Hi, IF we in 3265bis are going to say (see earlier discussion) that the SUB 200= (rather than the NOT) acknowledges a RE-subscription, is there are reason = why we can't say the same thing for a DE-subscription? Regards, Christer ________________________________________ From: Adam Roach [adam@nostrum.com] Sent: Thursday, April 08, 2010 11:02 PM To: Paul Kyzivat Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-= )subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] [as individual] On 4/8/10 2:57 PM, Paul Kyzivat wrote: > [as individual] > > Its good that subnot-etags will help with this. > But support for that will be optional... Which is pretty much true of anything we define after the fact. Horses have left the barn, etc. > ...and it may not even make sense for some event packages. I think you'll have a hard time coming up with an example of an entire event package for which etags doesn't make sense. > Is there a way that packages that support subnot-etags just for the "I > don't want to see anything" case, without the complexity and bother of > supporting for anything else? Not for the server. The client can blindly do a "Suppress-If-Match: *" on unsubscribe and not worry about the etag mechanism otherwise. /a= From christer.holmberg@ericsson.com Thu Apr 8 13:21:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694B73A6942 for ; Thu, 8 Apr 2010 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqIDkprw5HHy for ; Thu, 8 Apr 2010 13:21:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4690F3A6917 for ; Thu, 8 Apr 2010 13:21:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-77-4bbe3ab400c0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 44.48.23532.4BA3EBB4; Thu, 8 Apr 2010 22:21:09 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Apr 2010 22:21:08 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 8 Apr 2010 22:21:08 +0200 Thread-Topic: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] Thread-Index: AcrXV/g/97K1wGc+R8Cj1Kb1ZjieAwAAB7Q9 Message-ID: References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com>,<4BBE207A.2020704@nostrum.com> , <4BBE38F3.3010101@cisco.com> In-Reply-To: <4BBE38F3.3010101@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: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:21:31 -0000 Hi, >>But again, stateful intermediaries that do not support subnot will wait f= or the NOTIFY. > >Are you aware of any *proxies* that are dialog stateful for sub/not? Yes, I am. They insert Record-Route (which is explicitly allowed), and main= tain the subscription dialog state. >(Its not an issue for B2BUAs since they must support it for the two ends t= o use it.) Correct. I am talking about proxies. >If so, is there really some good reason for them to be doing so? That information I unfortunately don't have at the moment. Regards, Christer= From pkyzivat@cisco.com Thu Apr 8 13:24:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB823A6965 for ; Thu, 8 Apr 2010 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1p9LTijPXq5 for ; Thu, 8 Apr 2010 13:24:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AEC043A6850 for ; Thu, 8 Apr 2010 13:24:45 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFbYvUtAaMHG/2dsb2JhbACbOXGiRJk2hQkE X-IronPort-AV: E=Sophos;i="4.52,172,1270425600"; d="scan'208";a="180330717" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2010 20:24:22 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o38KOJUN005409; Thu, 8 Apr 2010 20:24:20 GMT Message-ID: <4BBE3B78.9090305@cisco.com> Date: Thu, 08 Apr 2010 16:24:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <4BB9E74E.2050209@cisco.com> <4BB9FC8C.5040600@nostrum.com>, <747A6506A991724FB09B129B79D5FEB61480C559F6@EXMBXCLUS01.citservers.local> <4BBBAC6C.6070103@cisco.com> <747A6506A991724FB09B129B79D5FEB61480C55D4C@EXMBXCLUS01.citservers.local> <4BBBC58A.10407@nostrum.com> <4BBDE58B.6040100@cisco.com> <4BBE207A.2020704@nostrum.com> <4BBE3533.7010402@cisco.com> <4BBE3650.4090908@nostrum.com> In-Reply-To: <4BBE3650.4090908@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:24:50 -0000 Adam Roach wrote: > [as individual] > > On 4/8/10 2:57 PM, Paul Kyzivat wrote: >> [as individual] >> >> Its good that subnot-etags will help with this. >> But support for that will be optional... > > Which is pretty much true of anything we define after the fact. Horses > have left the barn, etc. > >> ...and it may not even make sense for some event packages. > > I think you'll have a hard time coming up with an example of an entire > event package for which etags doesn't make sense. I'm no expert on this, but its my impression that it is *work* for the server developer to assign etags and then handle the suppression based on them. I'm thinking a lot of implementors would rather not bother to do that, and will only do so if the event package spec says they must. (Which none of the current ones do.) Can a server never send etags in NOTIFY, yet still support "Suppress-If-Match: *" in SUBSCRIBE? Thanks, Paul >> Is there a way that packages that support subnot-etags just for the "I >> don't want to see anything" case, without the complexity and bother of >> supporting for anything else? > > Not for the server. The client can blindly do a "Suppress-If-Match: *" > on unsubscribe and not worry about the etag mechanism otherwise. > > /a > From rjsparks@nostrum.com Thu Apr 8 13:33:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3B23A6B11 for ; Thu, 8 Apr 2010 13:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbxPOaAFOZXt for ; Thu, 8 Apr 2010 13:33:07 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 447063A6B0D for ; Thu, 8 Apr 2010 13:33:05 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-51-142.dllstx.fios.verizon.net [173.71.51.142]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o38KWtrP036486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Apr 2010 15:32:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480CDBE4D@EXMBXCLUS01.citservers.local> Date: Thu, 8 Apr 2010 15:32:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> <4BBE1EB3.7060302@nostrum.com> <9B2142E4-E751-459F-B4A6-A16F8C4F2A89@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480CDBE4D@EXMBXCLUS01.citservers.local> To: Brett Tate X-Mailer: Apple Mail (2.1078) Cc: SIPCORE Subject: Re: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:33:08 -0000 We're talking about the non-INVITE transaction. I think what you're looking at in 3398 is INVITE oriented (408's for = INVITE have a broader meaning). RjS On Apr 8, 2010, at 2:46 PM, Brett Tate wrote: >> 408's semantics in 3261 are clearly bound to the transaction=20 >> machinery. The other cases you are describing should use a=20 >> different response code. >=20 > If 408's semantics were so clear, I'd think RFC 3398, B2BUAs, and = etcetera would not have generated or documented to generate a 408 = response based upon another interfaces timeouts or receipt of 408. >=20 > Should errata be opened against RFC 3398? >=20 > Thanks for the response, >=20 > Brett >=20 From dean.willis@softarmor.com Thu Apr 8 15:42:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4610D3A6897 for ; Thu, 8 Apr 2010 15:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny1F+r6Bcd9R for ; Thu, 8 Apr 2010 15:42:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4D2663A686A for ; Thu, 8 Apr 2010 15:42:13 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o38Mg3ed001597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Apr 2010 17:42:04 -0500 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Apr 2010 17:41:58 -0500 References: <4BB24B81.1050006@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 22:42:14 -0000 On Apr 8, 2010, at 8:39 AM, Elwell, John wrote: > > In either case, nobody seems to have given a convincing use case > where probing all the devices behind an AOR is of significant benefit, That's indeed the question. What would you do differently if you knew about the capabilities of all the potential responding UAs before sending an INVITE? Our traditional logic has been "put everything YOU support in the offer, and let the combination of RFC 3840/3841 working in the proxy pick a UA that best-matches what you have. Of course, this can sometimes lead to requests getting sent to the phone that is the closest feature match rather than the one that's closest to the called party. Another alternative is to make an INVITE that offers only the bare minimum, then explore upgrading the call once it is established to engage additional features. But perhaps we have a problem. I want to offer a "rich" INVITE, but the low-end client with no features keeps answering before the "better" box. Now, we need to know the "best" set of capabilities, so that we can construct an INVITE that only the "right" UA is going to answer. > and if there is a significant benefit, why you can't just obtain the > device contact URIs using the reg event package and then send > OPTIONS to each. That one's easy. I'm not letting you subscribe to my reg-event information. I don't even HAVE reg-event information, as my registrar doesn't do it. -- Dean From fluffy@cisco.com Thu Apr 8 17:00:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0EB3A67D7 for ; Thu, 8 Apr 2010 17:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.37 X-Spam-Level: X-Spam-Status: No, score=-110.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQSchOj22ZpA for ; Thu, 8 Apr 2010 17:00:42 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 82F2D3A67B2 for ; Thu, 8 Apr 2010 17:00:42 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACsKvkurR7Ht/2dsb2JhbACbO3GiR5k0hQkEgyQ X-IronPort-AV: E=Sophos;i="4.52,173,1270425600"; d="scan'208";a="112622114" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Apr 2010 00:00:39 +0000 Received: from dhcp-171-68-21-196.cisco.com (dhcp-171-68-21-196.cisco.com [171.68.21.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3900SwJ002630; Fri, 9 Apr 2010 00:00:39 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4BBC9B6E.6000809@nostrum.com> Date: Thu, 8 Apr 2010 17:00:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> <4BBC9B6E.6000809@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 00:00:43 -0000 On Apr 7, 2010, at 7:49 , Adam Roach wrote: > I think Hadriel is right. >=20 > The more I read through this thread, the more it looks like we're = running around with a hammer, desperately looking for nails to hit. = Barring nails, we'll settle for screws. Or bolts. Or maybe kittens, if = it comes to that. +1 - I have a potato peeler and I'm not afraid to use it. But I'm not = seeing a problem here that OPTIONS looks like it solves.=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Thu Apr 8 17:00:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0233A6852 for ; Thu, 8 Apr 2010 17:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.447 X-Spam-Level: X-Spam-Status: No, score=-110.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyhe5GGIq-I9 for ; Thu, 8 Apr 2010 17:00:56 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3D92B3A67B2 for ; Thu, 8 Apr 2010 17:00:56 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOcKvkurR7Ht/2dsb2JhbACbO3GiSZk0hQkEgyQ X-IronPort-AV: E=Sophos;i="4.52,173,1270425600"; d="scan'208";a="180415676" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2010 00:00:28 +0000 Received: from dhcp-171-68-21-196.cisco.com (dhcp-171-68-21-196.cisco.com [171.68.21.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3900SwI002630; Fri, 9 Apr 2010 00:00:28 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 8 Apr 2010 17:00:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB24B81.1050006@nostrum.com> To: Dean Willis X-Mailer: Apple Mail (2.1078) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 00:00:57 -0000 On Apr 8, 2010, at 15:41 , Dean Willis wrote: >=20 > What would you do differently if you knew about the capabilities of = all the potential responding UAs before sending an INVITE? Well, one things I might do if I knew the capability of the far end = before the INVITE is not do Offer/answer and instead just tell the far = end what to do. More like how SDP is used in RTSP. All this offer answer = stuff is hard to get right. Some times I wonder if the use case is = actually it's hard to get offer / answer right so really what people = want to send is an "offer you can't refuse" in the INVITE and are trying = to discover capability's to make that possible. All a very interesting = discussion but none of this has inspired me to start work on anything to = do with OPTIONS.=20 From pkyzivat@cisco.com Thu Apr 8 17:06:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F123A6ABB for ; Thu, 8 Apr 2010 17:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf1nqu2prrSy for ; Thu, 8 Apr 2010 17:06:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 24B3D3A696B for ; Thu, 8 Apr 2010 17:06:54 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPsMvktAZnwM/2dsb2JhbACbO3GiNpk2hQkE X-IronPort-AV: E=Sophos;i="4.52,173,1270425600"; d="scan'208";a="100215058" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2010 00:06:50 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3906o5O019378; Fri, 9 Apr 2010 00:06:50 GMT Message-ID: <4BBE6FA3.6060903@cisco.com> Date: Thu, 08 Apr 2010 20:06:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 00:06:55 -0000 Dean Willis wrote: > > But perhaps we have a problem. I want to offer a "rich" INVITE, but the > low-end client with no features keeps answering before the "better" box. > Now, we need to know the "best" set of capabilities, so that we can > construct an INVITE that only the "right" UA is going to answer. I would recommend that you then set up callerprefs to *prefer* (but not require) the "rich" capabilities. With luck the call will be offered to the rich device first, and if that one doesn't answer then the dumber ones will still be tried. Thanks, Paul From pkyzivat@cisco.com Thu Apr 8 17:11:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483223A6811 for ; Thu, 8 Apr 2010 17:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnWeVdvhEPxD for ; Thu, 8 Apr 2010 17:11:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 988EA3A67C2 for ; Thu, 8 Apr 2010 17:11:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,173,1270425600"; d="scan'208";a="100215650" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2010 00:11:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o390BE8w027112; Fri, 9 Apr 2010 00:11:14 GMT Message-ID: <4BBE70AC.5060001@cisco.com> Date: Thu, 08 Apr 2010 20:11:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <4BB24B81.1050006@nostrum.com> <4BB44CE6.2070402@ericsson.com> <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <430FC6BDED356B4C8498F634416644A91A79F3CFE9@mail> <4BBC9B6E.6000809@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 00:11:20 -0000 Cullen Jennings wrote: > On Apr 7, 2010, at 7:49 , Adam Roach wrote: > >> I think Hadriel is right. >> >> The more I read through this thread, the more it looks like we're running around with a hammer, desperately looking for nails to hit. Barring nails, we'll settle for screws. Or bolts. Or maybe kittens, if it comes to that. > > > +1 - I have a potato peeler and I'm not afraid to use it. But I'm not seeing a problem here that OPTIONS looks like it solves. Maybe we could find a kitten for you to peel with it. :-) Thanks, Paul From dean.willis@softarmor.com Thu Apr 8 22:28:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68463A6966 for ; Thu, 8 Apr 2010 22:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izseZ0OqQEbi for ; Thu, 8 Apr 2010 22:28:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E1FE53A6B2B for ; Thu, 8 Apr 2010 22:27:47 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o395Rd5k003908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Apr 2010 00:27:41 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BBE6FA3.6060903@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Apr 2010 00:27:33 -0500 References: <4BB24B81.1050006@nostrum.com> <4BBE6FA3.6060903@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 05:28:19 -0000 On Apr 8, 2010, at 7:06 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> But perhaps we have a problem. I want to offer a "rich" INVITE, but >> the low-end client with no features keeps answering before the >> "better" box. Now, we need to know the "best" set of capabilities, >> so that we can construct an INVITE that only the "right" UA is >> going to answer. > > I would recommend that you then set up callerprefs to *prefer* (but > not require) the "rich" capabilities. With luck the call will be > offered to the rich device first, and if that one doesn't answer > then the dumber ones will still be tried. > Do you feel lucky? -- Dean From john.elwell@siemens-enterprise.com Thu Apr 8 23:24:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9F93A6928 for ; Thu, 8 Apr 2010 23:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hn31jg0yzJY for ; Thu, 8 Apr 2010 23:24:21 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 318AA3A687C for ; Thu, 8 Apr 2010 23:24:20 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1493007; Fri, 9 Apr 2010 08:24:17 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id ECBEA1EB82AB; Fri, 9 Apr 2010 08:24:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Apr 2010 08:24:17 +0200 From: "Elwell, John" To: Dean Willis Date: Fri, 9 Apr 2010 08:24:15 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrXbOuWhaqIIMEZSTWzvnEAYSZewAAP78kw Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 06:24:22 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 08 April 2010 23:42 > To: Elwell, John > Cc: Hans Erik van Elburg; WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > On Apr 8, 2010, at 8:39 AM, Elwell, John wrote: > > > > In either case, nobody seems to have given a convincing use case =20 > > where probing all the devices behind an AOR is of=20 > significant benefit, >=20 > That's indeed the question. >=20 > What would you do differently if you knew about the capabilities of =20 > all the potential responding UAs before sending an INVITE? >=20 > Our traditional logic has been "put everything YOU support in the =20 > offer, and let the combination of RFC 3840/3841 working in the proxy =20 > pick a UA that best-matches what you have. Of course, this can =20 > sometimes lead to requests getting sent to the phone that is the =20 > closest feature match rather than the one that's closest to=20 > the called =20 > party. >=20 > Another alternative is to make an INVITE that offers only the bare =20 > minimum, then explore upgrading the call once it is established to =20 > engage additional features. >=20 >=20 > But perhaps we have a problem. I want to offer a "rich" INVITE, but =20 > the low-end client with no features keeps answering before the =20 > "better" box. Now, we need to know the "best" set of=20 > capabilities, so =20 > that we can construct an INVITE that only the "right" UA is going to =20 > answer. >=20 >=20 > > and if there is a significant benefit, why you can't just=20 > obtain the =20 > > device contact URIs using the reg event package and then send =20 > > OPTIONS to each. >=20 > That one's easy. I'm not letting you subscribe to my reg-event =20 > information.=20 [JRE] If my policy is not to let you subscribe to reg-event, I would antici= pate having a similar policy not to reveal my registered contacts through 3= xx to OPTIONS. > I don't even HAVE reg-event information, as my=20 > registrar =20 > doesn't do it. [JRE] Equally, I don't support 3xx to OPTIONS because my proxy doesn't do i= t. I agree that 3xx to OPTIONS might be easier to implement than reg-event,= but you still need all the authentication/authorisation stuff. John From salvatore.loreto@ericsson.com Fri Apr 9 01:43:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDA53A6A88 for ; Fri, 9 Apr 2010 01:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwGfVGxWWnSv for ; Fri, 9 Apr 2010 01:43:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 80CB33A69CB for ; Fri, 9 Apr 2010 01:43:02 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-d4-4bbee891368d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 06.02.23740.198EEBB4; Fri, 9 Apr 2010 10:42:57 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 10:42:57 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 10:42:57 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 35B342725 for ; Fri, 9 Apr 2010 11:42:57 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EC37C4F465 for ; Fri, 9 Apr 2010 11:42:56 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 60F034F464 for ; Fri, 9 Apr 2010 11:42:51 +0300 (EEST) Message-ID: <4BBEE88B.6080103@ericsson.com> Date: Fri, 09 Apr 2010 10:42:51 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <4BB24B81.1050006@nostrum.com>, <4BB44CE6.2070402@ericsson.com>, <430FC6BDED356B4C8498F634416644A91A79F3CFC6@mail> <4BBDE1A0.5050603@cisco.com> <4BBDF184.6060806@ericsson.com> <4BBDF280.6090201@stpeter.im> In-Reply-To: <4BBDF280.6090201@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Apr 2010 08:42:57.0418 (UTC) FILETIME=[A74F86A0:01CAD7C0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:43:33 -0000 IMO it would be useful having in SIP a similar mechanism to the one used in XMPP as an alternative way to do OPTIONS /Sal On 4/8/10 5:13 PM, Peter Saint-Andre wrote: > FWIW, this is exactly what we do in XMPP. > > On 4/8/10 9:08 AM, Salvatore Loreto wrote: > >> Hi Paul, >> >> the use case you have written down is exactly the one I have in mind and >> was going to send to this ml. >> >> I want add one more benefit in knowing all the capabilities of the >> different Bob devices in advance and >> not just of one device. >> An OPTIONS response (or another mechanism!) that contains a level of >> granularity that let Alice (or rather Alices device) >> know that Bob can take only audio on one device, but >> audio/video/text/picture on his other device (as describe in Paul use >> case), >> would help Alice's device understand that starting a voice session with >> only voice Bob device, there is no way a re-INVITE to add video would work; >> so if she thinks that a voice call could be then transformed in a >> voice+video, she knows that should contact directly the >> audio/video/text/picture device. >> >> cheers >> Sal >> >> >> On 4/8/10 4:01 PM, Paul Kyzivat wrote: >> >>> [as individual] >>> >>> It seems that Christer has come close to offering a use case, even if >>> that was not his intent. And its still a little incomplete. I'll try to >>> fill it out a bit: >>> >>> Alice wants to call Bob. >>> Her phone app first queries Bob's AOR with OPTIONS. >>> The response to that is a 3xx with Contact URIs for >>> Bob's home phone and his mobile phone. So Alice's phone >>> sends additional OPTIONS requests to each of those. >>> From the responses it learns that Bob's mobile phone support >>> audio and video, while his home phone (behind a pstn gateway) >>> only supports audio. >>> >>> Alice has video support on her phone, and since Bob may be able to >>> support video too, decides to make an audio+video call. The >>> phone sends an INVITE with both, and caller preferences indicating >>> a preference for audio+video. >>> >>> The INVITE reaches the server handling Bob's AOR. >>> It processes the callerprefs, and so decides to initially send the >>> invite to Bob's mobile phone. But there is no answer there, so >>> the server forks the invite toward Bob's home phone. Bob answers that >>> one, accepting the audio and rejecting the video. >>> >>> The result of this is exactly the same as if no OPTIONS was ever sent, >>> and the INVITE was sent indicating Alice's own preferences. That is the >>> point that John already made. >>> >>> The only "benefit" I can see from use of options here would be if it was >>> discovered that Bob had no video support. In that case, the invite could >>> have been sent without offering video. Is that advantageous? Does it >>> cost more to initiate a call that offers video? Does it take more >>> network resources to do so, even when ultimately the video is rejected? >>> >>> The only real benefit I can see to this is if the calling user is given >>> an enhanced user interface - akin to what one gets with buddy lists - >>> where there is a display showing that Bob has two devices with differing >>> capabilities, with Alice having the option to choose one or allowing the >>> phone to make the choice. >>> >>> To provide that feature, presence would be a much better choice. >>> OPTIONS is in a sense "poor man's presence". Christer has mentioned that >>> he considers presence to be too "heavy weight" for this, but I remain to >>> be convinced of that. Perhaps maintaining persistent subscriptions to >>> presence status of everyone you might possibly call is too heavy weight, >>> but doing a polling subscription prior to a call won't be any heavier >>> than all this options stuff. >>> >>> It may be that lots of devices don't publish presence state. But that >>> can be solved in many ways. A registrar can synthesize basic presence >>> state from registration data. And it could even use OPTIONS to refine >>> that. >>> >>> I suspect the real hidden issue here is about presence, and so I'd >>> prefer to see it addressed from that direction. If that in turn leads to >>> a desire to use OPTIONS to get some degree of presence state from >>> devices that don't otherwise publish it, then lets confront it in that >>> context. And if the issue is that presence is typically not authorized >>> for as many requesters as OPTIONS is, then lets look at possible policy >>> recommendations in that regard. >>> >>> Thanks, >>> Paul >>> >>> Christer Holmberg wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>>>> From my perspective, the main use-case is not to discover services, >>>>>> >>>>> >>>>> >>>>>> but to discover capabilities in order to determine what services >>>>>> can be applied. >>>>>> >>>>>> The idea is also that the OPTIONS request would be sent prior to the >>>>>> INVITE, to try to make sure that the returned contacts are actually >>>>>> available. >>>>>> >>>>>> >>>>> But you know that would never work in practice/the-real-world. Think >>>>> about all the routing rules >>>>> people have for INVITEs - in some cases *only* for INVITEs. >>>>> And even if they route OPTIONS identically in the SIP domain, >>>>> for any given AoR it'll go to any of: a SIP UA, or a PSTN >>>>> gateway, or a H.323-gateway, or an MGCP call-agent, or an >>>>> IP-PBX, or a foobar-protocol-gateway, or a vmail server, or >>>>> an announcement server, or an app server, etc. Just because >>>>> the OPTIONS reaches the end of the SIP domain, means nothing >>>>> about whether an INVITE to the higher-layer target (which in >>>>> practice is a E.164 number, that crosses from SIP into many >>>>> other protocol domains) is actually available to receive a call. >>>>> >>>>> >>>> The assumption is that the OPTIONS request reaches the registrar, >>>> that returns the registered contacts. It is never forwarded to any UAS. >>>> >>>> Then, at some point an INVITE is sent, and it is addressed to the >>>> same AOR (the INVITE request might be routed differently than the >>>> OPTIONS request). Based on the UAS information, the INVITE may now >>>> contain feature tags etc that indicates a wish to reach an UAS with >>>> certain capabilities. >>>> >>>> Now, unless the INVITE is addressed to a specific UAS, it can of >>>> course not be guranteed that the INVITE will actually reach such UAS. >>>> But, that is a "feature" of RFC 3841, and it would be the case even >>>> if you had never sent any OPTIONS. What OPTIONS allows provides you >>>> is capability information about the UAS(s) associated with the AOR, >>>> which might be useful when sending the INVITE. >>>> >>>> No, it does not guarantee that the user is available - it only >>>> provides you with that same information as OPTIONS in a non-forking >>>> case does. >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> > -- Salvatore Loreto www.sloreto.com From brett@broadsoft.com Fri Apr 9 02:28:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F8C3A696A for ; Fri, 9 Apr 2010 02:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5cEm0IQFvRh for ; Fri, 9 Apr 2010 02:28:24 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 72AEE3A689C for ; Fri, 9 Apr 2010 02:28:18 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 9 Apr 2010 02:28:14 -0700 From: Brett Tate To: Robert Sparks , Adam Roach , SIPCORE Date: Fri, 9 Apr 2010 02:27:26 -0700 Thread-Topic: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses Thread-Index: AcrXWq7qpbqwJgq1TXCdOOEi77Y2NwAZsSmQ Message-ID: <747A6506A991724FB09B129B79D5FEB61480D0FF4E@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61480C56865@EXMBXCLUS01.citservers.local> <4BBE1EB3.7060302@nostrum.com> <9B2142E4-E751-459F-B4A6-A16F8C4F2A89@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480CDBE4D@EXMBXCLUS01.citservers.local> 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: [sipcore] RFC 4320: deprecation of non-INVITE 408 responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 09:28:25 -0000 I am indicating that the logic that used to dismiss my concern over depreca= ting all non-INVITE 408 responses is incorrect. Per RFC 3261, a 408 Request Timeout response to INVITE has no different mea= ning from a 408 Request Timeout to non-INVITE. A request timeout is a requ= est timeout.=20 RFC 3261 section 21.4.9: "The server could not produce a response within a = suitable amount of time, for example, if it could not determine the locatio= n of the user in time. The client MAY repeat the request without modificat= ions at any later time." RFC 4320 unfortunately deprecated all 408 responses to non-INVITE instead o= f only the use case where sending the 408 isn't desirable. Since RFC 4320 unfortunately deprecated 408 Request Timeout responses to no= n-INVITE, what response does the working group want to be sent to indicate = "Request Timeout" when the timeout occurs quickly (like after 1 second) ins= tead of after long delay associated with rfc4320/rfc4321's use case? Is 50= 4 Server Time-out the best alternative to indicate Request Timeout? I would rather see RFC 4320's 408 deprecation be limited to appropriate use= case instead of defining or using another response code to indicate Reques= t Timeout. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Thursday, April 08, 2010 4:33 PM > To: Brett Tate > Cc: Adam Roach; SIPCORE > Subject: Re: [sipcore] RFC 4320: deprecation of non-INVITE 408 > responses >=20 > We're talking about the non-INVITE transaction. > I think what you're looking at in 3398 is INVITE oriented (408's for > INVITE have a broader meaning). >=20 > RjS >=20 > On Apr 8, 2010, at 2:46 PM, Brett Tate wrote: >=20 > >> 408's semantics in 3261 are clearly bound to the transaction > >> machinery. The other cases you are describing should use a > >> different response code. > > > > If 408's semantics were so clear, I'd think RFC 3398, B2BUAs, and > etcetera would not have generated or documented to generate a 408 > response based upon another interfaces timeouts or receipt of 408. > > > > Should errata be opened against RFC 3398? > > > > Thanks for the response, > > > > Brett > > From pkyzivat@cisco.com Fri Apr 9 06:16:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A2028C0F0 for ; Fri, 9 Apr 2010 06:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.404 X-Spam-Level: X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkkkHrOHie62 for ; Fri, 9 Apr 2010 06:16:19 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 05BB328C0FE for ; Fri, 9 Apr 2010 06:16:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfEvktAZnwN/2dsb2JhbACbO3GhMpkyhQkE X-IronPort-AV: E=Sophos;i="4.52,177,1270425600"; d="scan'208";a="100368977" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2010 13:16:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o39DGEx0019646; Fri, 9 Apr 2010 13:16:14 GMT Message-ID: <4BBF28AE.70105@cisco.com> Date: Fri, 09 Apr 2010 09:16:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <4BB24B81.1050006@nostrum.com> <4BBE6FA3.6060903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 13:16:20 -0000 Dean Willis wrote: > > On Apr 8, 2010, at 7:06 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >>> But perhaps we have a problem. I want to offer a "rich" INVITE, but >>> the low-end client with no features keeps answering before the >>> "better" box. Now, we need to know the "best" set of capabilities, so >>> that we can construct an INVITE that only the "right" UA is going to >>> answer. >> >> I would recommend that you then set up callerprefs to *prefer* (but >> not require) the "rich" capabilities. With luck the call will be >> offered to the rich device first, and if that one doesn't answer then >> the dumber ones will still be tried. >> > > Do you feel lucky? Never. I'm definitely a "glass half empty" person. OTOH, if it doesn't work, its the callee's fault, not mine. If he wants his "rich" devices to be useful he ought to get a smarter proxy. Thanks, Paul From dean.willis@softarmor.com Fri Apr 9 08:47:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73DC3A696F for ; Fri, 9 Apr 2010 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaTV-XYRStUQ for ; Fri, 9 Apr 2010 08:47:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C55653A6967 for ; Fri, 9 Apr 2010 08:47:45 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o39FlYPk009279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Apr 2010 10:47:35 -0500 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Apr 2010 10:47:28 -0500 References: <4BB24B81.1050006@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 15:47:46 -0000 On Apr 9, 2010, at 1:24 AM, Elwell, John wrote: >>> That one's easy. I'm not letting you subscribe to my reg-event >> information. > [JRE] If my policy is not to let you subscribe to reg-event, I would > anticipate having a similar policy not to reveal my registered > contacts through 3xx to OPTIONS. > >> I don't even HAVE reg-event information, as my >> registrar >> doesn't do it. > [JRE] Equally, I don't support 3xx to OPTIONS because my proxy > doesn't do it. I agree that 3xx to OPTIONS might be easier to > implement than reg-event, but you still need all the authentication/ > authorisation stuff. > Both good arguments. I'm inclined more than ever to suggest that proxies should just never fork OPTIONS. Besides using it as a very inefficient PING, what do we really use OPTIONS for in the real world? Even when used as a "ping", what does it mean to fork it? Does contact-routing of OPTIONS (including forking) create a security hole? If we suggest proxies don't fork OPTIONs, how should they respond to an OPTIONS request for an AOR for which they are responsible? With their own capabilities? Perhaps with a 302 listing the public GRUUs, if any? -- Dean From john.elwell@siemens-enterprise.com Fri Apr 9 09:40:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AB33A680E for ; Fri, 9 Apr 2010 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EfbAk2Pt9-W for ; Fri, 9 Apr 2010 09:40:42 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2D20F3A6838 for ; Fri, 9 Apr 2010 09:40:41 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1502089; Fri, 9 Apr 2010 18:40:35 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9358D23F028E; Fri, 9 Apr 2010 18:40:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Apr 2010 18:40:35 +0200 From: "Elwell, John" To: Dean Willis Date: Fri, 9 Apr 2010 18:40:33 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrX+/+UBeSDDuDRSF2OUcXmu+KzYwABwPJw Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 16:40:43 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 09 April 2010 16:47 > To: Elwell, John > Cc: Hans Erik van Elburg; WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > On Apr 9, 2010, at 1:24 AM, Elwell, John wrote: > >>> That one's easy. I'm not letting you subscribe to my reg-event > >> information. > > [JRE] If my policy is not to let you subscribe to=20 > reg-event, I would =20 > > anticipate having a similar policy not to reveal my registered =20 > > contacts through 3xx to OPTIONS. > > > >> I don't even HAVE reg-event information, as my > >> registrar > >> doesn't do it. > > [JRE] Equally, I don't support 3xx to OPTIONS because my proxy =20 > > doesn't do it. I agree that 3xx to OPTIONS might be easier to =20 > > implement than reg-event, but you still need all the=20 > authentication/=20 > > authorisation stuff. > > >=20 > Both good arguments. I'm inclined more than ever to suggest that =20 > proxies should just never fork OPTIONS. >=20 > Besides using it as a very inefficient PING, what do we really use =20 > OPTIONS for in the real world? Even when used as a "ping", what does =20 > it mean to fork it? Does contact-routing of OPTIONS (including =20 > forking) create a security hole? >=20 > If we suggest proxies don't fork OPTIONs, how should they respond to =20 > an OPTIONS request for an AOR for which they are responsible? With =20 > their own capabilities? Perhaps with a 302 listing the public GRUUs, =20 > if any? [JRE] I think this misses my point. If the proxy returns a 302 with all my = contacts (GRUUs), I have revealed to the caller how many devices I have and= their individual addresses, i.e., basically the same information as reg-ev= ent would give the caller. So similar authorisation policies should apply. John >=20 > -- > Dean >=20 >=20 > = From dean.willis@softarmor.com Fri Apr 9 12:18:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0BD3A69A2 for ; Fri, 9 Apr 2010 12:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhEo7VXp9AEp for ; Fri, 9 Apr 2010 12:18:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 78B9A3A6936 for ; Fri, 9 Apr 2010 12:18:42 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o39JIX7p010842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Apr 2010 14:18:34 -0500 Message-Id: <9C241824-40EA-42CF-8FE0-CCBE197A2CA7@softarmor.com> From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Apr 2010 14:18:28 -0500 References: <4BB24B81.1050006@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 19:18:45 -0000 On Apr 9, 2010, at 11:40 AM, Elwell, John wrote: >> >> If we suggest proxies don't fork OPTIONs, how should they respond to >> an OPTIONS request for an AOR for which they are responsible? With >> their own capabilities? Perhaps with a 302 listing the public GRUUs, >> if any? > [JRE] I think this misses my point. If the proxy returns a 302 with > all my contacts (GRUUs), I have revealed to the caller how many > devices I have and their individual addresses, i.e., basically the > same information as reg-event would give the caller. So similar > authorisation policies should apply. Well, the public GRUUs do list the different devices, but not their IP Addresses, per se. One could also use temp-gruu for the same function. I like the idea of returning some sort of "OPTIONS aggregate", but this leads to questions of disjoint feature sets across devices. For example what happens if one picks two "must" features out of the aggregate and constructs a request around them, when in reality there are two different devices, each of which has only one of the features? -- Dean From paulej@packetizer.com Sat Apr 10 16:53:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5153A67E6 for ; Sat, 10 Apr 2010 16:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1icbXqFtMNY for ; Sat, 10 Apr 2010 16:53:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 45BC63A67AE for ; Sat, 10 Apr 2010 16:53:58 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3ANrhKR028968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Apr 2010 19:53:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270943629; bh=aySC96Q2SG8HWVAkNt2F6hNh2hb5lyosLxuWydkmsL8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bS1tMf6Fwqj8hTBJEjxwgSXoJpKphXwRk38JeR2bT9wN9j5K8K5JCG1Mgs+joQVun VpaOYabaQn6fv14DvKfY1pNK1u0fDVCDG9iCLpSKcEKs3Cj9Ej7DW5APqJNvW2M98z 6J8fUV2EBVNo+bb64FZhsAHYx8kGkSBwomlwWvWQ= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3ANrfAh017504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Apr 2010 19:53:42 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Brett Tate'" , , , References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> <430FC6BDED356B4C8498F634416644A91A79E93292@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E93292@mail> Date: Sat, 10 Apr 2010 19:53:21 -0400 Message-ID: <002301cad909$00ce17c0$026a4740$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrTUFoHoG3kmE8PR8OP/TTMdPkytQASKuTAAAUuvZABVpZe0A== Content-Language: en-us Subject: Re: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 23:53:59 -0000 Hadriel, Sorry for the belated reply. I was on vacation this past week (and still am), and wasn't able to respond to everything this week. > I was worried about this too ('cause I also suggested option-tags and > was worried about code-changes), but ISTM this is basically already the > case: unless most folks do exactly what this doc says today, they're > non-compliant and would require changing either code or config. I don't know what percentage of devices would be compliant vs. non-compliant. However, unless we stick a stake in the ground somewhere, it will continue to be rather messy. > The thing is, afaict, many folks DON'T do what the doc says. Not > exactly, which is the same thing (right?). For example, of three > rather popular vendors I just looked at OPTION-ping traces of, none > used the 486 for anything. I don't know what they'd do if they got > one. All 3 of the vendors use 503 to signal "out-of-service" back, but > at least 2 of them still allow (and want/expect to receive) in-dialog > messages - I can't tell with the 3rd. And one of them still _sent_ all > messages even if it got a 503. Note that in the language of the draft, I often use the word "should" for things, including the 486. We could mandate strict behavior in some cases (and should), but "guidance" is all that is necessary in some instances. If a device wishes to keep responding until it drops deaf entirely, that's OK. But, we ought to encourage the use of a different response code, in my opinion. In any case, the fact that OPTIONS is used for a "ping" so widely and there are so many variations on the usage suggests we really need to reach some agreement on something. I'm certainly open to input, but we're not going to be able to accommodate every implementation. Paul From paulej@packetizer.com Sat Apr 10 17:00:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7F23A67AE for ; Sat, 10 Apr 2010 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWYBNQRXp5y9 for ; Sat, 10 Apr 2010 17:00:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id B0A933A67A4 for ; Sat, 10 Apr 2010 17:00:36 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3B00MTF029265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Apr 2010 20:00:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270944028; bh=s6jAuAEDX2KYiZqahoiR5+nRSZl2Fdqq1EAqH3KHBxc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U99nNqSW1ECsKVK77R3n2bPm+zOrABu+152Yi1aLfnshe4XYpwYIZiKwfb2X+foYf ijU2ziTXBbtwYqNxPJ2t1pMwNJIiN760skzJq4FyQhNxzDyPzWeKLuKP1TzL3tiYos Edh/fAB11juTd2RRIEXHoXeuA+NAEuiyUVi5hFd8= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3B00LBV017517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Apr 2010 20:00:21 -0400 From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Hadriel Kaplan'" , References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> In-Reply-To: Date: Sat, 10 Apr 2010 20:00:01 -0400 Message-ID: <002601cad909$eebf7be0$cc3e73a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAEMQfAAVWaKLA= Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:00:37 -0000 Christer, > >>But more importantly because it conflicts with two other pieces of > >>work being done in the IETF: > >>1) The keep-alive portion, which is done by RFC 5626 and also being > >>worked on in draft-ietf-sipcore-keep. > > > >That document covers a different problem that's not related to an > application "ping" between two devices. One could view it as such for > active sessions, I suppose, but it really has a different focus. > > That is not true. > > If you negotiate the keep-alive as part of the registration procedure, > the "pings" will be sent during the duration of the registration - no > matter whether you have active sessions or not. True, but this draft is not focused on places where a REGISTER message is sent between a UA and a Registrar. Rather, the draft is focused on places where a REGISTER is not likely used, such as between two peer SBCs. > Now, that of course only applies to nodes that are involved in > registration, and the keep draft currently says that keep alives > negotiated during session setup are only valid for that session. > However, I think that at some point there was a comment that it should > also be allowed to negotiate to longer keep-alive durations during the > session setup, for proxy-to-proxy "pings" etc. I guess we'll get back > to that discussion once we get the keep discussion up again (next week, > according to my plans). We also need a solution for when there are no active sessions and haven't been for hours, for example. OPTIONS "pings" have been serving this role for a while. OPTIONS "pings" can also be used by diagnostic equipment to alert admins that a device is down. Paul From paulej@packetizer.com Sat Apr 10 17:04:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D18B3A6810 for ; Sat, 10 Apr 2010 17:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6stb9EWRG++E for ; Sat, 10 Apr 2010 17:04:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 14B323A680D for ; Sat, 10 Apr 2010 17:04:09 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3B03u49029433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Apr 2010 20:04:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270944242; bh=1AIcgiJRnG2orjXhMHk0OxmxD24qnpEeYZp5Mp9zai8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=F+CN/xdvESYvDIi2Unfn3vQ5GJeOseTy1SpTiRoonwayLmgMLsRr6hRrC+doB8Lxc ybksOHFpiJ8pKAdAad27rzLhzp7by6rafwNiXj3KPOqsktzAQWnhjq/I3d+WCQB9FX xek4+BCVyzqsiLQ/st+RReZocC2VmkEerLIkLUsU= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3B03tAU017537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Apr 2010 20:03:56 -0400 From: "Paul E. Jones" To: "'Brett Tate'" , References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> Date: Sat, 10 Apr 2010 20:03:35 -0400 Message-ID: <002901cad90a$6e6fee10$4b4fca30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAXhQZAAUKMgJA= Content-Language: en-us Cc: 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:04:10 -0000 Brett, I guess I'm still a bit confused. What in this draft violates the rule? I think we're in agreement here, but apparently the text of the draft isn't quite as clear as it ought to be, I guess. Paul > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Sunday, April 04, 2010 10:23 AM > To: Paul E. Jones; sipcore@ietf.org > Cc: 'Hadriel Kaplan' > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > As for the meaning, I'm confused with your question. > > The intent is to obey the Retry-After header. If the > > reply to the OPTIONS has a Retry-After header, then > > don't send another OPTIONS until that time expires. > > Your response is appropriate for responses like 486 and 500 with Retry- > After; however a 503 with Retry-After applies to more than OPTIONS. > Per RFC 3261 section 21.5.4, it means you SHOULD NOT send any requests > (INVITE, BYE, ACK, CANCEL, REGISTER, ...) during that interval. > From paulej@packetizer.com Sat Apr 10 17:08:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2197B3A680D for ; Sat, 10 Apr 2010 17:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG+rd71dRGjh for ; Sat, 10 Apr 2010 17:08:30 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 0E0993A67A4 for ; Sat, 10 Apr 2010 17:08:29 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3B08IQj029629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Apr 2010 20:08:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270944503; bh=XeZp5y+8n/0iBp+MA9LQ3XgWB6INA+xOBLAMMJCRz64=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OH3bWR3iKMRlu2Ezy1Hd1mBVfBQm9X7Yk/9rl9njj/Rmk1qk6OQCqnavNj0HJ3GuK SRv7FNKE40irUXO3tSeCXHyGZQNFZXl6dGAJnNarFpCTIinx84eSE72g7J04Z3bsrt NzNf9GiGBs5cscWYjAIm4b4CZWWRqdwTvFpvOWDs= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3B08HoE017552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Apr 2010 20:08:18 -0400 From: "Paul E. Jones" To: "'Brett Tate'" , References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> <747A6506A991724FB09B129B79D5FEB61480BBFAD1@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480BBFAD1@EXMBXCLUS01.citservers.local> Date: Sat, 10 Apr 2010 20:07:57 -0400 Message-ID: <002c01cad90b$0a9c17f0$1fd447d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrTUFoHoG3kmE8PR8OP/TTMdPkytQASKuTAABp9kuABQeVeIA== Content-Language: en-us Subject: Re: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:08:31 -0000 Brett, > The current wording requires honoring the 503 with Retry-After overload > mechanism. RFC 3261 section 21.5.4 is at the SHOULD level instead of a > MUST. > > If you only intended the Retry-After to apply to OPTIONS (instead of > all requests), you can't use a 503 response (unless maybe you used an > option-tag or something to indicate a meaning other than RFC 3261 > section 21.5.4). Ah, I think this was your point. I believe a 503 would apply to the entire server, just as 3261 says. So, a device might return a 503 or 486. In both cases, the Retry-After header should be honored and these procedures do not change the intent of 3261 -- at least not intentionally. > I'm referring to devices with multiple ip-addresses such as 1 or more > IPv4 addresses and/or 1 or more IPv6 addresses. Thus the source ip- > address of 503 response may be different from where UAC sent the > OPTIONS; and the sender of 503 may have additional ip-addresses used > for SIP communication between these two servers. Since rfc3261 was > somewhat vague, I'm attempting to ensure the draft is clear since it is > requiring or recommending the use of 503 with Retry-After. This is a problem general for SIP, since there is no way for a SIP entity to know that a DNS query that returns 4 replies relates to the same or different servers. I can't fix that problem in this draft :-) Paul From paulej@packetizer.com Sat Apr 10 17:16:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067593A67E6 for ; Sat, 10 Apr 2010 17:16:17 -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.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m66-5QWU1C2 for ; Sat, 10 Apr 2010 17:16:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 3754B3A67A4 for ; Sat, 10 Apr 2010 17:16:15 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3B0G2tV029895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Apr 2010 20:16:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1270944968; bh=GBZJP8iJA1CHCquTRS7ytvdHUmJAQ4/LgqQfU1qwsDQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UGZudX1vGtQ8h2aWZCjSYj0t7oQWWnMLr4RKBXKcRksapkfWkyC5bvTh2ubP3ly50 6kMNgBi5IxXCr06Bu+lt5xLJLPtx1hTBoczfaZzmRx3zyDPZ4p/tUPLZoiYb0YTm1I eWU0vvsdrFQPby11kNhuqYxRrUmHcLzdYOyzAQYc= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3B0G13H017573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Apr 2010 20:16:01 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> Date: Sat, 10 Apr 2010 20:15:41 -0400 Message-ID: <003d01cad90c$1ef46ad0$5cdd4070$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/A= Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:16:19 -0000 Hadriel, Yeah, I think that's OK, too. And, it's one reason for recommending setting the Max-Forwards header. These procedures really are intended for use between two devices that have some kind of established relationship. I would not expect them to be used between any two devices on the Internet, nor would I expect all devices to support an OPTIONS "ping". We might see service providers require this support at peer interconnection points or perhaps between an enterprise or service provider. We might also see this kind of support required inside an enterprise or carrier network for monitoring purposes. But, such requirements would be explicit, manufacturers would build accordingly, and things should work. What we need, I think, are the basic guidelines to help ensure (what I've unfortunately seen) where all kinds of different response codes more-or-less equate to a 503. Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 05, 2010 5:32 PM > To: Paul Kyzivat; Paul E. Jones > Cc: sipcore@ietf.org; 'Vivek Bhargava (vbharga)'; 'Gonzalo Salgueiro' > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > One problem I've seen is when something like a UA or IP-PBX is OPTIONS > pinging "sip:sip.ssp.com" - that will resolve in DNS to an ingress > proxy, which actually is the real target of the ping request - but the > ingress proxy itself may think the OPTIONS needs to get routed to the > authoritative server for sip.ssp.com, which may well be something > _after_ the proxy. > > Setting max-forwards to 1 helps avoid that, but in some proxies that > will get back a 483 too many hops, which is actually ok in my book - > after all you know its alive and processing requests - but in some > devices that increments error counters which people don't like. > > -hadriel > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, April 05, 2010 8:52 AM > > To: Paul E. Jones > > Cc: Hadriel Kaplan; sipcore@ietf.org; 'Vivek Bhargava (vbharga)'; > 'Gonzalo > > Salgueiro' > > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > > [as an individual] > > > > Paul E. Jones wrote: > > > > >> Other, specific comments on the draft: > > >> 0) You might want to consider specifying what the To/From-URIs > should > > >> be sent as, and that a receiver should be lenient. We've seen > interop > > >> problems with those URIs for OPTIONS pings. > > > > > > I wanted to be rather strict in saying that only sip:192.168.4.56 > was > > > acceptable, for example, but others I consulted with thought that > was > > too > > > restrictive. So, the language is soft here. > > > > I believe I was one of the "others". > > > > My personal concern was that making such a mandate starts to > interfere > > with the layering of the sip stack. If you "know" your neighbors via > DNS > > names, then the translation to ip addresses occurs in the code that > > implements 3263, which is way below where you construct, send, and > > receive responses to messages. > > > > I didn't want to see a set of recommendations that require violation > of > > such layering. > > > > But I'd be interested in hearing other points of view on this. > > > > Thanks, > > Paul > From HKaplan@acmepacket.com Sat Apr 10 19:52:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9893A6876 for ; Sat, 10 Apr 2010 19:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leCAWsaQLJZv for ; Sat, 10 Apr 2010 19:52:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E4BAB3A681C for ; Sat, 10 Apr 2010 19:52:30 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 10 Apr 2010 22:52:25 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 10 Apr 2010 22:52:23 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Christer Holmberg' , "sipcore@ietf.org" Date: Sat, 10 Apr 2010 22:52:00 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAEMQfAAVWaKLAABQzFQA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D65F@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <002601cad909$eebf7be0$cc3e73a0$@com> In-Reply-To: <002601cad909$eebf7be0$cc3e73a0$@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: "'Vivek Bhargava \(vbharga\)'" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 02:52:32 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, April 10, 2010 8:00 PM >=20 > We also need a solution for when there are no active sessions and haven't > been for hours, for example. =20 It was my impression draft-sip-core-keep was also supposed to support that.= I agree that its current wording is wrong, imo, but when it started out m= y impression was it could be used for permanent proxy-to-proxy (or b2bua-to= -b2bua, etc.) connections/associations, regardless of there being an active= dialog between the two. Without that I agree with you that it's not as us= eful. > OPTIONS "pings" have been serving this role > for a while. OPTIONS "pings" can also be used by diagnostic equipment to > alert admins that a device is down. The draft-keep does that (detect device failure), but what it doesn't do is= tell you when it's getting too busy. I liked it over OPTIONS-pings becaus= e draft-keep's a lot lighter-weight/more-efficient, trivial to implement, e= xplicit in its purpose, and unavoidably single-hop. In other words it woul= d *replace* OPTIONS pings. But if we go fix OPTIONS-pings, would we need d= raft-keep anymore? Would people implement it? -hadriel From HKaplan@acmepacket.com Sat Apr 10 20:13:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01703A681C for ; Sat, 10 Apr 2010 20:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAEoCF782gnb for ; Sat, 10 Apr 2010 20:13:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7C3B73A6765 for ; Sat, 10 Apr 2010 20:13:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 10 Apr 2010 23:13:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 10 Apr 2010 23:13:30 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Sat, 10 Apr 2010 23:13:30 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABchqcA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D660@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com> In-Reply-To: <003d01cad90c$1ef46ad0$5cdd4070$@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: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 03:13:37 -0000 Hi Paul, Inline... > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, April 10, 2010 8:16 PM >=20 > Yeah, I think that's OK, too. And, it's one reason for recommending > setting > the Max-Forwards header. These procedures really are intended for use > between two devices that have some kind of established relationship. I > would not expect them to be used between any two devices on the Internet, > nor would I expect all devices to support an OPTIONS "ping". =20 I'm not sure what comment I made elicited the second sentence. You mean my= concern for error logs due to max-forwards=3D1? I.e., you're saying that = since these devices "know" they're doing it, they shouldn't log errors? Su= re. But it's kinda hard to know the OPTIONS is for ping and not just some = other OPTIONS that happens to have looped around enough to get down to a Ma= x-Forwards of 1.=20 That's one of the reasons it would be nice if the OPTIONS actually had some= way to say "I'm a ping". For example, my company's systems set the To/Fro= m username to "ping" (e.g., "sip:ping@192.1.2.3") by default. > We might see > service providers require this support at peer interconnection points or > perhaps between an enterprise or service provider. =20 That's already the case. -hadriel > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 05, 2010 5:32 PM > > To: Paul Kyzivat; Paul E. Jones > > Cc: sipcore@ietf.org; 'Vivek Bhargava (vbharga)'; 'Gonzalo Salgueiro' > > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > > 00.txt > > > > > > One problem I've seen is when something like a UA or IP-PBX is OPTIONS > > pinging "sip:sip.ssp.com" - that will resolve in DNS to an ingress > > proxy, which actually is the real target of the ping request - but the > > ingress proxy itself may think the OPTIONS needs to get routed to the > > authoritative server for sip.ssp.com, which may well be something > > _after_ the proxy. > > > > Setting max-forwards to 1 helps avoid that, but in some proxies that > > will get back a 483 too many hops, which is actually ok in my book - > > after all you know its alive and processing requests - but in some > > devices that increments error counters which people don't like. > > > > -hadriel From HKaplan@acmepacket.com Sat Apr 10 20:16:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFDB3A6896 for ; Sat, 10 Apr 2010 20:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZrIm-HtSUrZ for ; Sat, 10 Apr 2010 20:16:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6C8943A681C for ; Sat, 10 Apr 2010 20:16:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 10 Apr 2010 23:16:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 10 Apr 2010 23:16:18 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Sat, 10 Apr 2010 23:16:16 -0400 Thread-Topic: Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABlp9gA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D662@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com> In-Reply-To: <003d01cad90c$1ef46ad0$5cdd4070$@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: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 03:16:27 -0000 Hi Paul, I suppose there's no real point in arguing over the nitty-gritty details ri= ght now. Let's assume whatever this turns out to be isn't 100% backwards-c= ompatible with your or some people's implementations of OPTIONS-pings, and = thus requires code changes for some or even many folks. The big question i= n my mind is: should we do this, or should we do draft-keep? -hadriel > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, April 10, 2010 8:16 PM > > These procedures really are intended for use > between two devices that have some kind of established relationship. I > would not expect them to be used between any two devices on the Internet, > nor would I expect all devices to support an OPTIONS "ping". We might se= e > service providers require this support at peer interconnection points or > perhaps between an enterprise or service provider. We might also see thi= s > kind of support required inside an enterprise or carrier network for > monitoring purposes. But, such requirements would be explicit, > manufacturers would build accordingly, and things should work. What we > need, I think, are the basic guidelines to help ensure (what I've > unfortunately seen) where all kinds of different response codes more-or- > less > equate to a 503. >=20 > Paul >=20 From christer.holmberg@ericsson.com Sun Apr 11 05:05:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82073A6903 for ; Sun, 11 Apr 2010 05:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDoPx9tk4Dty for ; Sun, 11 Apr 2010 05:05:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E5A953A68D6 for ; Sun, 11 Apr 2010 05:05:38 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-f0-4bc1bb0bf304 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DF.47.23740.B0BB1CB4; Sun, 11 Apr 2010 14:05:31 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 11 Apr 2010 14:05:31 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Paul E. Jones" , 'Paul Kyzivat' Date: Sun, 11 Apr 2010 14:05:30 +0200 Thread-Topic: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABlp9gAASOCNa Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com>, <430FC6BDED356B4C8498F634416644A91A79F3D662@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D662@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 12:05:40 -0000 Hi, Keep in mind that the keep-draft does not define a keep-alive/ping mechanis= m - it defines a mechanism to negotiate the mechanism already defined in Ou= tbound. Now, the keep-draft also supports negotiation of "keep-alives" between prox= ies, where the "keep-alive" is more likely to be used as a ping, so I guess= your question is whether you want to replace THAT part with options-ping?= =20 Or, are you also saying that we should do NAT keep-alives using options-pin= g??? I really hope not... :) Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadr= iel Kaplan [HKaplan@acmepacket.com] Sent: Sunday, April 11, 2010 6:16 AM To: Paul E. Jones; 'Paul Kyzivat' Cc: 'Vivek Bhargava (vbharga)'; sipcore@ietf.org; 'Gonzalo Salgueiro' Subject: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options= -ping-00.txt) Hi Paul, I suppose there's no real point in arguing over the nitty-gritty details ri= ght now. Let's assume whatever this turns out to be isn't 100% backwards-c= ompatible with your or some people's implementations of OPTIONS-pings, and = thus requires code changes for some or even many folks. The big question i= n my mind is: should we do this, or should we do draft-keep? -hadriel > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, April 10, 2010 8:16 PM > > These procedures really are intended for use > between two devices that have some kind of established relationship. I > would not expect them to be used between any two devices on the Internet, > nor would I expect all devices to support an OPTIONS "ping". We might se= e > service providers require this support at peer interconnection points or > perhaps between an enterprise or service provider. We might also see thi= s > kind of support required inside an enterprise or carrier network for > monitoring purposes. But, such requirements would be explicit, > manufacturers would build accordingly, and things should work. What we > need, I think, are the basic guidelines to help ensure (what I've > unfortunately seen) where all kinds of different response codes more-or- > less > equate to a 503. > > Paul > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Sun Apr 11 06:04:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157483A69A5 for ; Sun, 11 Apr 2010 06:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEINlgVyYDVt for ; Sun, 11 Apr 2010 06:04:23 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 3C2603A699C for ; Sun, 11 Apr 2010 06:04:23 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 11 Apr 2010 06:04:18 -0700 From: Brett Tate To: "Paul E. Jones" , "sipcore@ietf.org" Date: Sun, 11 Apr 2010 06:03:26 -0700 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAXhQZAAUKMgJAAGZRFgA== Message-ID: <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> In-Reply-To: <002901cad90a$6e6fee10$4b4fca30$@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: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 13:04:24 -0000 > What in this draft violates the rule? The draft is currently upgrading rfc3261's honoring Retry-After requirement= s from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to MUST (MUST NOT) leve= ls. Thus it is preventing the UAC from making appropriate/configurable dec= isions concerning if/how it is willing to honor/apply the reception of 503 = with Retry-After. For instance, the draft doesn't allow UAC to reduce the honoring of 503 wit= h Retry-After value of 1 year to only apply for 30 seconds. For instance, the draft doesn't allow UAC to avoid applying the 503 with Re= try-After value to sending requests associated with emergency calls. For instance, the draft doesn't allow UAC to avoid applying the 503 with Re= try-After to sending requests within dialog. For instance, the draft doesn't allow UAC to avoid honoring a 503 with Retr= y-After when response source ip-address is not equivalent to where the requ= est was sent. Concerning their not matching, the draft currently does not = mention it from a security risk or otherwise. For instance, the draft doesn't allow UAC to only apply the 503 with Retry-= After to specific interfaces. More specifically if a UAC knows it should n= ot trust/honor the 503 Retry-After value (because of a proxy rfc3261/draft = non compliance or an insecure interface), the draft doesn't allow the devic= e to instead not honor the 503 with Retry-After. From HKaplan@acmepacket.com Sun Apr 11 08:02:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8B83A6804 for ; Sun, 11 Apr 2010 08:02:52 -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=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se4StlRWhfXE for ; Sun, 11 Apr 2010 08:02:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4CCB73A676A for ; Sun, 11 Apr 2010 08:02:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 11 Apr 2010 11:02:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 11 Apr 2010 11:02:43 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Paul E. Jones" , 'Paul Kyzivat' Date: Sun, 11 Apr 2010 11:02:41 -0400 Thread-Topic: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABlp9gAASOCNaAAYIh5A= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D66D@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com>, <430FC6BDED356B4C8498F634416644A91A79F3D662@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 15:02:53 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, April 11, 2010 8:06 AM > To: Hadriel Kaplan; Paul E. Jones; 'Paul Kyzivat' >=20 > Keep in mind that the keep-draft does not define a keep-alive/ping > mechanism - it defines a mechanism to negotiate the mechanism already > defined in Outbound. >=20 > Now, the keep-draft also supports negotiation of "keep-alives" between > proxies, where the "keep-alive" is more likely to be used as a ping, so I > guess your question is whether you want to replace THAT part with options= - > ping? Right, I'm questioning if we need to standardize a way to negotiate "keep-a= lives" between proxies, if we decide to go and fix OPTIONS-pings. =20 Today OPTIONS-pings are already used as keep-alives between proxies, but th= ey have interop and operational issues. I had assumed that draft-keep woul= d help us avoid those issues, and would be the "standard" way to do it. It doesn't make much sense to run *both* between proxies, for example. I do= n't think having two ways to solve the same problems is a good idea. I don't much care which one it is - I think the stun/crlf method is better = from a technical perspective, but OPTIONS would probably get wider adoption= faster. =20 > Or, are you also saying that we should do NAT keep-alives using options- > ping??? I really hope not... :) Definitely not. :) -hadriel From paulej@packetizer.com Sun Apr 11 14:31:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DBF3A68CB for ; Sun, 11 Apr 2010 14:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYpo7evipmpP for ; Sun, 11 Apr 2010 14:31:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 6D5AB3A6888 for ; Sun, 11 Apr 2010 14:31:44 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3BLVUAR024620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Apr 2010 17:31:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271021496; bh=+eOmSCwFbrdvR0obKeATydXSGsxYpWclB+EhLeMOUmA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HWLeKH8Cb2gTyGxMF7EWbKbjIRrqruWe1KeDv7SNyLAYAUiV/nn7viNar1r8H+YQO 1CfklzdTwfD1CuWOuJ2zoaqpR45VQ4WGuBIVFTwCzjp5YhZ7uqPpKUhwvkSpJTA/1c /E4DI9nI1dm9JrEcrhMKfAWo54/vy5rWaMQBDdrU= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3BLVTPR031214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Apr 2010 17:31:30 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com> <430FC6BDED356B4C8498F634416644A91A79F3D660@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D660@mail> Date: Sun, 11 Apr 2010 17:31:28 -0400 Message-ID: <00d401cad9be$591a4d30$0b4ee790$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABchqcAAmxjeg Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 21:31:45 -0000 > > Yeah, I think that's OK, too. And, it's one reason for recommending > > setting > > the Max-Forwards header. These procedures really are intended for > use > > between two devices that have some kind of established relationship. > I > > would not expect them to be used between any two devices on the > Internet, > > nor would I expect all devices to support an OPTIONS "ping". > > I'm not sure what comment I made elicited the second sentence. You > mean my concern for error logs due to max-forwards=1? I.e., you're > saying that since these devices "know" they're doing it, they shouldn't > log errors? Oh, it was nothing you said. I'm just adding more commentary :) > Sure. But it's kinda hard to know the OPTIONS is for ping > and not just some other OPTIONS that happens to have looped around > enough to get down to a Max-Forwards of 1. I would expect it to know that it's an options ping based on the address to which it is directed. For example, sip:192.168.2.34 would suggest it's destined for the particular device. Perhaps one might also use sip:ping@192.168.2.34 for this purpose. I think each box that supports an options ping ought to have a defined ping "address", with the IP address of the machine serving as a reasonable default. (That might not make sense for IP phones, but I think it makes sense for B2BUAs.) > That's one of the reasons it would be nice if the OPTIONS actually had > some way to say "I'm a ping". For example, my company's systems set > the To/From username to "ping" (e.g., "sip:ping@192.1.2.3") by default. And I'd say that's reasonable to do. > > We might see > > service providers require this support at peer interconnection points > or > > perhaps between an enterprise or service provider. > > That's already the case. Indeed :) And, that's why I thought it would be reasonable to put this draft out there. Paul From paulej@packetizer.com Sun Apr 11 14:45:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8003F3A6927 for ; Sun, 11 Apr 2010 14:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g6L2GS-Tn5N for ; Sun, 11 Apr 2010 14:45:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 60B8E3A6809 for ; Sun, 11 Apr 2010 14:45:09 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3BLiuqn025235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Apr 2010 17:45:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271022302; bh=u6EuWUMcy3kr5e/54siXP9dyiFtFIr+vl9skIhbtB0k=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZWwbjgvFZQ1WF5MS+uKj4ejsrVZLV7Q+voXEXS5nEaMgUeV7RimvU81RIAf3xcgtV uOf7v2jbRqzUG4TjIYfKlV3Alvh3IQkq4gZF5TXsrKzYEXtBZLsYLepLIldb94rcLW c2eHgyyUqYKPwmUQoAQkVQ5uvYNrzj2SNO0mpmkc= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3BLit5N031247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Apr 2010 17:44:56 -0400 From: "Paul E. Jones" To: "'Brett Tate'" , References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> Date: Sun, 11 Apr 2010 17:44:54 -0400 Message-ID: <00d701cad9c0$394a0160$abde0420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrSdU2yxJMjseD6QPuhNjrqBMaZcAAMAkqAACsDRxAAFCIpcAAXhQZAAUKMgJAAGZRFgAAT4a+g Content-Language: en-us Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 21:45:10 -0000 Brett, So, I think the only change we need in the draft is to change the word "MUST" to "SHOULD" in the paragraph just before Section 8? Paul > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Sunday, April 11, 2010 9:03 AM > To: Paul E. Jones; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > What in this draft violates the rule? > > The draft is currently upgrading rfc3261's honoring Retry-After > requirements from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to MUST > (MUST NOT) levels. Thus it is preventing the UAC from making > appropriate/configurable decisions concerning if/how it is willing to > honor/apply the reception of 503 with Retry-After. > > For instance, the draft doesn't allow UAC to reduce the honoring of 503 > with Retry-After value of 1 year to only apply for 30 seconds. > > For instance, the draft doesn't allow UAC to avoid applying the 503 > with Retry-After value to sending requests associated with emergency > calls. > > For instance, the draft doesn't allow UAC to avoid applying the 503 > with Retry-After to sending requests within dialog. > > For instance, the draft doesn't allow UAC to avoid honoring a 503 with > Retry-After when response source ip-address is not equivalent to where > the request was sent. Concerning their not matching, the draft > currently does not mention it from a security risk or otherwise. > > For instance, the draft doesn't allow UAC to only apply the 503 with > Retry-After to specific interfaces. More specifically if a UAC knows > it should not trust/honor the 503 Retry-After value (because of a proxy > rfc3261/draft non compliance or an insecure interface), the draft > doesn't allow the device to instead not honor the 503 with Retry-After. > From HKaplan@acmepacket.com Sun Apr 11 15:21:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF8D3A6800 for ; Sun, 11 Apr 2010 15:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMoHCC2jReLW for ; Sun, 11 Apr 2010 15:21:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 92CEE3A67A6 for ; Sun, 11 Apr 2010 15:21:56 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 11 Apr 2010 18:21:48 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 11 Apr 2010 18:21:45 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Paul E. Jones" Date: Sun, 11 Apr 2010 18:21:45 -0400 Thread-Topic: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABlp9gAASOCNaAAYIh5AADw/o8A== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D682@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com>, <430FC6BDED356B4C8498F634416644A91A79F3D662@mail> <430FC6BDED356B4C8498F634416644A91A79F3D66D@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D66D@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 22:21:59 -0000 Oh wait, I totally misunderstood what you were saying. You're saying "draf= t-keep is just a negotiation mechanism, so it could negotiate to use option= s-pings". Right, so what's the value in that? We needed an indication of support for= stun/crlf, because there was no way to indicate it between two proxies - e= xcept of course them sending an OPTIONS to each other. :) I guess in my mind the main use-case for draft-keep was for inter-proxy (or= inter-b2bua/etc.) on a permanent basis, and I was trying to avoid yet one = more set of things to be configured/provisioned/get-wrong on systems. =20 So I was thinking "Great, let's do this simple indication on the wire, and = if the next-hop does it I'll use the stun/crlf which is better anyway, othe= rwise I'll use OPTIONS pings and hope for the best". As an example, my system has half a dozen configurable settings for OPTIONS= -pings, on a per next-hop basis, just to get it to work right with differen= t vendors. :( =20 I'd like the next setting to be the Staples "Easy" button. :) -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Hadriel Kaplan > Sent: Sunday, April 11, 2010 11:03 AM >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Sunday, April 11, 2010 8:06 AM > > To: Hadriel Kaplan; Paul E. Jones; 'Paul Kyzivat' > > > > Keep in mind that the keep-draft does not define a keep-alive/ping > > mechanism - it defines a mechanism to negotiate the mechanism already > > defined in Outbound. > > > > Now, the keep-draft also supports negotiation of "keep-alives" between > > proxies, where the "keep-alive" is more likely to be used as a ping, so > I > > guess your question is whether you want to replace THAT part with > options- > > ping? >=20 > Right, I'm questioning if we need to standardize a way to negotiate "keep= - > alives" between proxies, if we decide to go and fix OPTIONS-pings. >=20 > Today OPTIONS-pings are already used as keep-alives between proxies, but > they have interop and operational issues. I had assumed that draft-keep > would help us avoid those issues, and would be the "standard" way to do i= t. >=20 > It doesn't make much sense to run *both* between proxies, for example. I > don't think having two ways to solve the same problems is a good idea. >=20 > I don't much care which one it is - I think the stun/crlf method is bette= r > from a technical perspective, but OPTIONS would probably get wider > adoption faster. >=20 >=20 > > Or, are you also saying that we should do NAT keep-alives using options= - > > ping??? I really hope not... :) >=20 > Definitely not. :) >=20 > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Apr 12 00:24:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C423A6978 for ; Mon, 12 Apr 2010 00:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUWupMpgEpuR for ; Mon, 12 Apr 2010 00:24:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5E7723A692E for ; Mon, 12 Apr 2010 00:24:43 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-8f-4bc2cab43adc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5B.C7.23740.4BAC2CB4; Mon, 12 Apr 2010 09:24:37 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 12 Apr 2010 09:24:33 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Paul E. Jones" Date: Mon, 12 Apr 2010 09:24:32 +0200 Thread-Topic: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) Thread-Index: AcrUvsixUtI00N+AT8i4auhXnRrh7AAQMANQAQMBi/AABlp9gAASOCNaAAYIh5AADw/o8AATe7Dw Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com>, <430FC6BDED356B4C8498F634416644A91A79F3D662@mail> <430FC6BDED356B4C8498F634416644A91A79F3D66D@mail> <430FC6BDED356B4C8498F634416644A91A79F3D682@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D682@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'Vivek Bhargava \(vbharga\)'" , "sipcore@ietf.org" , 'Gonzalo Salgueiro' Subject: Re: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 07:24:58 -0000 Hi,=20 >Oh wait, I totally misunderstood what you were saying. =20 >You're saying "draft-keep is just a negotiation mechanism, so=20 >it could negotiate to use options-pings". That is not what I am saying :) I am saying that the draft is used to negotiate the mechanism defined in Ou= tbound. >Right, so what's the value in that? We needed an indication=20 >of support for stun/crlf, because there was no way to=20 >indicate it between two proxies - except of course them=20 >sending an OPTIONS to each other. :) That is what the keep-draft provides. >I guess in my mind the main use-case for draft-keep was for=20 >inter-proxy (or inter-b2bua/etc.) on a permanent basis, and I=20 >was trying to avoid yet one more set of things to be=20 >configured/provisioned/get-wrong on systems. =20 Permanent proxy-to-proxy was not the main use-case of the keep-draft (at le= ast not initially). The main use-cases were UA-to-proxy, to: 1. Allow negotiation of keep-alives during registration without having to s= upport Outbound; and 2. Allow negotiation of keep-alives during session establishment The inter-proxy was added later, since there were requests to do so. The question is now whether we should REMOVE the inter-proxy case from the = keep-draft all together, and ONLY use options-ping instead. >So I was thinking "Great, let's do this simple indication on=20 >the wire, and if the next-hop does it I'll use the stun/crlf=20 >which is better anyway, otherwise I'll use OPTIONS pings and=20 >hope for the best". Yes. Regards, Christer =20 >As an example, my system has half a dozen configurable=20 >settings for OPTIONS-pings, on a per next-hop basis, just to=20 >get it to work right with different vendors. :( =20 >=20 >I'd like the next setting to be the Staples "Easy" button. :) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Hadriel Kaplan > > Sent: Sunday, April 11, 2010 11:03 AM > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Sunday, April 11, 2010 8:06 AM > > > To: Hadriel Kaplan; Paul E. Jones; 'Paul Kyzivat' > > > > > > Keep in mind that the keep-draft does not define a=20 > keep-alive/ping=20 > > > mechanism - it defines a mechanism to negotiate the mechanism=20 > > > already defined in Outbound. > > > > > > Now, the keep-draft also supports negotiation of "keep-alives"=20 > > > between proxies, where the "keep-alive" is more likely to=20 > be used as=20 > > > a ping, so > > I > > > guess your question is whether you want to replace THAT part with > > options- > > > ping? > >=20 > > Right, I'm questioning if we need to standardize a way to negotiate=20 > > "keep- alives" between proxies, if we decide to go and fix=20 > OPTIONS-pings. > >=20 > > Today OPTIONS-pings are already used as keep-alives between=20 > proxies,=20 > > but they have interop and operational issues. I had assumed that=20 > > draft-keep would help us avoid those issues, and would be=20 > the "standard" way to do it. > >=20 > > It doesn't make much sense to run *both* between proxies,=20 > for example.=20 > > I don't think having two ways to solve the same problems is=20 > a good idea. > >=20 > > I don't much care which one it is - I think the stun/crlf method is=20 > > better from a technical perspective, but OPTIONS would probably get=20 > > wider adoption faster. > >=20 > >=20 > > > Or, are you also saying that we should do NAT keep-alives using=20 > > > options- ping??? I really hope not... :) > >=20 > > Definitely not. :) > >=20 > > -hadriel > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Mon Apr 12 00:45:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43633A69F3 for ; Mon, 12 Apr 2010 00:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLrO20xbe04q for ; Mon, 12 Apr 2010 00:45:24 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 237AC3A681F for ; Mon, 12 Apr 2010 00:45:06 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1512347; Mon, 12 Apr 2010 09:44:59 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 05EFD23F0278; Mon, 12 Apr 2010 09:44:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 12 Apr 2010 09:44:59 +0200 From: "Elwell, John" To: Dean Willis Date: Mon, 12 Apr 2010 09:44:54 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrYGXcIIdE9ZQBxTmGbR1HzkV7L6gB+j4Dw Message-ID: References: <4BB24B81.1050006@nostrum.com> <9C241824-40EA-42CF-8FE0-CCBE197A2CA7@softarmor.com> In-Reply-To: <9C241824-40EA-42CF-8FE0-CCBE197A2CA7@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 07:45:24 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 09 April 2010 20:18 > To: Elwell, John > Cc: Hans Erik van Elburg; WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > On Apr 9, 2010, at 11:40 AM, Elwell, John wrote: >=20 > >> > >> If we suggest proxies don't fork OPTIONs, how should they=20 > respond to > >> an OPTIONS request for an AOR for which they are responsible? With > >> their own capabilities? Perhaps with a 302 listing the=20 > public GRUUs, > >> if any? > > [JRE] I think this misses my point. If the proxy returns a=20 > 302 with =20 > > all my contacts (GRUUs), I have revealed to the caller how many =20 > > devices I have and their individual addresses, i.e., basically the =20 > > same information as reg-event would give the caller. So similar =20 > > authorisation policies should apply. >=20 > Well, the public GRUUs do list the different devices, but not=20 > their IP =20 > Addresses, per se. One could also use temp-gruu for the same function. [JRE] In fact RFC 5628 considers temp-gruu to be a bigger security risk, an= d states in section 5: "This element SHOULD NOT be included if the subscriber is not authorized to register to the AOR, unless there is an explicitly configured policy directing that it be included." So if 3xx to OPTIONS reveals temp-gruus, this should be subject to the same= authorisation policy as reg-event. John From christer.holmberg@ericsson.com Mon Apr 12 06:23:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B523A6A3B for ; Mon, 12 Apr 2010 06:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVFlKirFaIX1 for ; Mon, 12 Apr 2010 06:23:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 06EAE3A688B for ; Mon, 12 Apr 2010 06:23:06 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-1b-4bc31eb41308 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8D.0E.23740.4BE13CB4; Mon, 12 Apr 2010 15:23:00 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 12 Apr 2010 15:23:00 +0200 From: Christer Holmberg To: Dean Willis , "Elwell, John" Date: Mon, 12 Apr 2010 15:22:57 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrYGXk8a+mfaJwVTvOlzPHXCUZ4kwCKVoMw Message-ID: References: <4BB24B81.1050006@nostrum.com> <9C241824-40EA-42CF-8FE0-CCBE197A2CA7@softarmor.com> In-Reply-To: <9C241824-40EA-42CF-8FE0-CCBE197A2CA7@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "WORLEY, DALE R \(DALE\)" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:23:09 -0000 Hi, As has been said, there can always be policies regarding what is returned -= no matter what mechanism is used. So, in the case of OPTIONS, if there is a policy to not return the contacts= , the proxy might return some kind of "OPTIONS aggregate".=20 We don't need to define those policies, we just say how things are done if = applied. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 9. huhtikuuta 2010 22:18 > To: Elwell, John > Cc: WORLEY, DALE R (DALE); sipcore@ietf.org > Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? >=20 >=20 > On Apr 9, 2010, at 11:40 AM, Elwell, John wrote: >=20 > >> > >> If we suggest proxies don't fork OPTIONs, how should they=20 > respond to=20 > >> an OPTIONS request for an AOR for which they are responsible? With=20 > >> their own capabilities? Perhaps with a 302 listing the=20 > public GRUUs,=20 > >> if any? > > [JRE] I think this misses my point. If the proxy returns a 302 with=20 > > all my contacts (GRUUs), I have revealed to the caller how many=20 > > devices I have and their individual addresses, i.e., basically the=20 > > same information as reg-event would give the caller. So similar=20 > > authorisation policies should apply. >=20 > Well, the public GRUUs do list the different devices, but not=20 > their IP Addresses, per se. One could also use temp-gruu for=20 > the same function. >=20 > I like the idea of returning some sort of "OPTIONS=20 > aggregate", but this leads to questions of disjoint feature=20 > sets across devices. For example what happens if one picks=20 > two "must" features out of the aggregate and constructs a=20 > request around them, when in reality there are two different=20 > devices, each of which has only one of the features? >=20 > -- > Dean >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Mon Apr 12 06:59:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A0F3A67E3 for ; Mon, 12 Apr 2010 06:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.426 X-Spam-Level: X-Spam-Status: No, score=-10.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tblhLTg-t88d for ; Mon, 12 Apr 2010 06:59:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 605E53A6A51 for ; Mon, 12 Apr 2010 06:59:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD/EwktAZnwM/2dsb2JhbACbMnGiTJhPhQwE X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="100857209" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 13:59:29 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CDxSWe013348; Mon, 12 Apr 2010 13:59:28 GMT Message-ID: <4BC3273D.7090902@cisco.com> Date: Mon, 12 Apr 2010 09:59:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> In-Reply-To: <00d701cad9c0$394a0160$abde0420$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:59:40 -0000 [as individual] Paul E. Jones wrote: > Brett, > > So, I think the only change we need in the draft is to change the word > "MUST" to "SHOULD" in the paragraph just before Section 8? Let me just interject here that in the past we have frequently gotten into trouble by using SHOULD without qualification of what constitutes a valid reason for going against the SHOULD. Without actual text that clarifies that, SHOULD is often treated as if it said "you can claim conformance without implementing this." Thanks, Paul > Paul > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: Sunday, April 11, 2010 9:03 AM >> To: Paul E. Jones; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >> >>> What in this draft violates the rule? >> The draft is currently upgrading rfc3261's honoring Retry-After >> requirements from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to MUST >> (MUST NOT) levels. Thus it is preventing the UAC from making >> appropriate/configurable decisions concerning if/how it is willing to >> honor/apply the reception of 503 with Retry-After. >> >> For instance, the draft doesn't allow UAC to reduce the honoring of 503 >> with Retry-After value of 1 year to only apply for 30 seconds. >> >> For instance, the draft doesn't allow UAC to avoid applying the 503 >> with Retry-After value to sending requests associated with emergency >> calls. >> >> For instance, the draft doesn't allow UAC to avoid applying the 503 >> with Retry-After to sending requests within dialog. >> >> For instance, the draft doesn't allow UAC to avoid honoring a 503 with >> Retry-After when response source ip-address is not equivalent to where >> the request was sent. Concerning their not matching, the draft >> currently does not mention it from a security risk or otherwise. >> >> For instance, the draft doesn't allow UAC to only apply the 503 with >> Retry-After to specific interfaces. More specifically if a UAC knows >> it should not trust/honor the 503 Retry-After value (because of a proxy >> rfc3261/draft non compliance or an insecure interface), the draft >> doesn't allow the device to instead not honor the 503 with Retry-After. >> > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From paulej@packetizer.com Mon Apr 12 07:13:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BFB3A699E for ; Mon, 12 Apr 2010 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoPkCHdEMqiR for ; Mon, 12 Apr 2010 07:13:27 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 6D0373A68C5 for ; Mon, 12 Apr 2010 07:13:27 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3CED7i6006201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Apr 2010 10:13:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271081593; bh=HDeOG7BRDfkmkQufk6BINeVqxqtzLRUJ8Ba5J0+kLC0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=eUs4hLAN7ho/Iehlia9JrZ7x9zb9hn3YrcFSHQvwXCh9M2sThjXfYkr30Xx8iq9/X ytIx4S15o55QgCj6KLXDb0tSev0Ew7tqV6qwDM5vi9p52b//U47RrEFtALOkFY6xq/ EQjD902txWFlVmoI3qiLow9CITpgtpWn8J31ezeY= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3CED6uv001958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Apr 2010 10:13:06 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> In-Reply-To: <4BC3273D.7090902@cisco.com> Date: Mon, 12 Apr 2010 10:13:04 -0400 Message-ID: <003501cada4a$44b220c0$ce166240$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcraSGMuQ+1rDdDZROal0aZIc9Nh2QAAZJ1w Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:13:29 -0000 Paul, > > So, I think the only change we need in the draft is to change the > word > > "MUST" to "SHOULD" in the paragraph just before Section 8? > > Let me just interject here that in the past we have frequently gotten > into trouble by using SHOULD without qualification of what constitutes > a > valid reason for going against the SHOULD. Without actual text that > clarifies that, SHOULD is often treated as if it said "you can claim > conformance without implementing this." I think that's OK here, since what Brett was suggesting was that it is already a SHOULD in effect in 3261. In any case, the worst thing that happens here is that a device ignores the Retry-After header and claims compliance. Apparently, some feel there are plenty of good reasons to do so. Paul From pkyzivat@cisco.com Mon Apr 12 07:17:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F1C3A6A45 for ; Mon, 12 Apr 2010 07:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEvtE0GcGswo for ; Mon, 12 Apr 2010 07:17:14 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1D7443A699E for ; Mon, 12 Apr 2010 07:17:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="101002799" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2010 14:17:08 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CEH8SK029935; Mon, 12 Apr 2010 14:17:08 GMT Message-ID: <4BC32B5E.1070208@cisco.com> Date: Mon, 12 Apr 2010 10:17:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com> In-Reply-To: <003d01cad90c$1ef46ad0$5cdd4070$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:17:16 -0000 Paul, Paul E. Jones wrote: > Hadriel, > > Yeah, I think that's OK, too. And, it's one reason for recommending setting > the Max-Forwards header. These procedures really are intended for use > between two devices that have some kind of established relationship. I > would not expect them to be used between any two devices on the Internet, > nor would I expect all devices to support an OPTIONS "ping". We might see > service providers require this support at peer interconnection points or > perhaps between an enterprise or service provider. We might also see this > kind of support required inside an enterprise or carrier network for > monitoring purposes. But, such requirements would be explicit, > manufacturers would build accordingly, and things should work. What we > need, I think, are the basic guidelines to help ensure (what I've > unfortunately seen) where all kinds of different response codes more-or-less > equate to a 503. I don't understand how you envision this working. Would you expect that in those places where this mechanism is to be used that the policy to do so will be explicitly configured mutually on both of the peers, and that support for this draft would then be required of both? (As opposed to a situation where a particular device just has a policy of using this mechanism with all peers that meet some generic criterion for their role, and that are discovered to support the mechanism.) Thanks, Paul > Paul > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Monday, April 05, 2010 5:32 PM >> To: Paul Kyzivat; Paul E. Jones >> Cc: sipcore@ietf.org; 'Vivek Bhargava (vbharga)'; 'Gonzalo Salgueiro' >> Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >> >> >> One problem I've seen is when something like a UA or IP-PBX is OPTIONS >> pinging "sip:sip.ssp.com" - that will resolve in DNS to an ingress >> proxy, which actually is the real target of the ping request - but the >> ingress proxy itself may think the OPTIONS needs to get routed to the >> authoritative server for sip.ssp.com, which may well be something >> _after_ the proxy. >> >> Setting max-forwards to 1 helps avoid that, but in some proxies that >> will get back a 483 too many hops, which is actually ok in my book - >> after all you know its alive and processing requests - but in some >> devices that increments error counters which people don't like. >> >> -hadriel >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Monday, April 05, 2010 8:52 AM >>> To: Paul E. Jones >>> Cc: Hadriel Kaplan; sipcore@ietf.org; 'Vivek Bhargava (vbharga)'; >> 'Gonzalo >>> Salgueiro' >>> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >>> [as an individual] >>> >>> Paul E. Jones wrote: >>> >>>>> Other, specific comments on the draft: >>>>> 0) You might want to consider specifying what the To/From-URIs >> should >>>>> be sent as, and that a receiver should be lenient. We've seen >> interop >>>>> problems with those URIs for OPTIONS pings. >>>> I wanted to be rather strict in saying that only sip:192.168.4.56 >> was >>>> acceptable, for example, but others I consulted with thought that >> was >>> too >>>> restrictive. So, the language is soft here. >>> I believe I was one of the "others". >>> >>> My personal concern was that making such a mandate starts to >> interfere >>> with the layering of the sip stack. If you "know" your neighbors via >> DNS >>> names, then the translation to ip addresses occurs in the code that >>> implements 3263, which is way below where you construct, send, and >>> receive responses to messages. >>> >>> I didn't want to see a set of recommendations that require violation >> of >>> such layering. >>> >>> But I'd be interested in hearing other points of view on this. >>> >>> Thanks, >>> Paul > > > From paulej@packetizer.com Mon Apr 12 07:35:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D079428C107 for ; Mon, 12 Apr 2010 07:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjh8Mh7mFh-L for ; Mon, 12 Apr 2010 07:35:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 806023A6A57 for ; Mon, 12 Apr 2010 07:35:17 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3CEZ37X008547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Apr 2010 10:35:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271082909; bh=KX9kgh2cWGArzWnzUOochpZWaSuJkFTCaBrOqXhEhdw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=r9tsycY+CoCa/MsgTYFNogYufWwDs3jtw8bM1JOc1LkNyubgAZRczW/SQqtFuIi3Y ni+rQ/f9+ASCcbIj19I9EwlKZ/IqjO9filCrC++pa5+5++9pIWg7UphbDQTkn0qLEl KyLLZsXhEc4gBRfmVMCZvS09FdqLtPgeIXmOSK0k= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3CEZ1oq002005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Apr 2010 10:35:01 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <4BB9DCE4.4070502@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CCD8@mail> <003d01cad90c$1ef46ad0$5cdd4070$@com> <4BC32B5E.1070208@cisco.com> In-Reply-To: <4BC32B5E.1070208@cisco.com> Date: Mon, 12 Apr 2010 10:35:00 -0400 Message-ID: <004b01cada4d$550a8450$ff1f8cf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcraStplpu5Hae31SQiT56An6g4ggQAAerEQ Content-Language: en-us Cc: "'Vivek Bhargava \(vbharga\)'" , sipcore@ietf.org, 'Gonzalo Salgueiro' , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:35:23 -0000 Paul, > I don't understand how you envision this working. > Would you expect that in those places where this mechanism is to be > used > that the policy to do so will be explicitly configured mutually on both > of the peers, and that support for this draft would then be required of > both? That is my expectation. It's not really different from today, except today we have a variety of OPTIONS "ping" approaches and I'd like to narrow those down to one, if possible. Paul From pkyzivat@cisco.com Mon Apr 12 08:15:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976853A6781 for ; Mon, 12 Apr 2010 08:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.443 X-Spam-Level: X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVZNY5jXcxUY for ; Mon, 12 Apr 2010 08:15:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CD0323A6A46 for ; Mon, 12 Apr 2010 08:15:08 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANTVwktAZnwN/2dsb2JhbACbNHGiYphlhQwE X-IronPort-AV: E=Sophos;i="4.52,191,1270425600"; d="scan'208";a="100880899" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 15:15:03 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CFF3i5019457; Mon, 12 Apr 2010 15:15:03 GMT Message-ID: <4BC338F9.80604@cisco.com> Date: Mon, 12 Apr 2010 11:15:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> In-Reply-To: <003501cada4a$44b220c0$ce166240$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:15:53 -0000 Paul E. Jones wrote: > Paul, > >>> So, I think the only change we need in the draft is to change the >> word >>> "MUST" to "SHOULD" in the paragraph just before Section 8? >> Let me just interject here that in the past we have frequently gotten >> into trouble by using SHOULD without qualification of what constitutes >> a >> valid reason for going against the SHOULD. Without actual text that >> clarifies that, SHOULD is often treated as if it said "you can claim >> conformance without implementing this." > > I think that's OK here, since what Brett was suggesting was that it is > already a SHOULD in effect in 3261. In any case, the worst thing that > happens here is that a device ignores the Retry-After header and claims > compliance. Apparently, some feel there are plenty of good reasons to do > so. I don't think that lets you off the hook. We've learned from experience that we were too vague in the past. So I would expect you to be less vague here - being more explicit about what conditions justify violating the SHOULD. Thanks, Paul From HKaplan@acmepacket.com Mon Apr 12 09:27:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B133A6A7D for ; Mon, 12 Apr 2010 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjoTefZi3uPQ for ; Mon, 12 Apr 2010 09:27:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 285593A6AAC for ; Mon, 12 Apr 2010 09:22:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 12:22:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 12:22:05 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Paul E. Jones" Date: Mon, 12 Apr 2010 12:22:04 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcraUzbHPnp8UFzsQzyVq0ow7aee1AACPTvA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> In-Reply-To: <4BC338F9.80604@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: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:27:06 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat >=20 > I don't think that lets you off the hook. > We've learned from experience that we were too vague in the past. > So I would expect you to be less vague here - being more explicit about > what conditions justify violating the SHOULD. And really using "MUST..., unless..." instead. -hadriel From brett@broadsoft.com Mon Apr 12 10:14:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D1A3A6A89 for ; Mon, 12 Apr 2010 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOjZPz3g810a for ; Mon, 12 Apr 2010 10:14:30 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 1ECC73A6A8F for ; Mon, 12 Apr 2010 10:11:28 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([0000:0000:0000:0000:0000:0000:0.0.0.1]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 12 Apr 2010 10:11:22 -0700 From: Brett Tate To: Hadriel Kaplan , Paul Kyzivat , "Paul E. Jones" , "sipcore@ietf.org" Date: Mon, 12 Apr 2010 10:10:31 -0700 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcraUzbHPnp8UFzsQzyVq0ow7aee1AACPTvAAAFCx3A= Message-ID: <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 17:14:31 -0000 > > I don't think that lets you off the hook. > > We've learned from experience that we were too vague in=20 > > the past. So I would expect you to be less vague here -=20 > > being more explicit about what conditions justify violating=20 > > the SHOULD. >=20 > And really using "MUST..., unless..." instead. Is making 503 with Retry-After usable (i.e. so it does more good than harm)= something that should be done within this draft and in this working group?= Or is that something that should be addressed within the hopefully dispat= ched overload working group? From victor.pascual.avila@gmail.com Mon Apr 12 10:48:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16B428C110 for ; Mon, 12 Apr 2010 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mKs45JQ+V+a for ; Mon, 12 Apr 2010 10:48:17 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 337273A6990 for ; Mon, 12 Apr 2010 10:47:57 -0700 (PDT) Received: by bwz9 with SMTP id 9so4853771bwz.29 for ; Mon, 12 Apr 2010 10:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MBhZGTc87dtYhOhsKwmPecxXMDAOw8slAuXaDUOv7WU=; b=vWj5ZUpVkKav0rz4ddlwLue/v0UKbUNLJrIoy0m5J2jhknNjp5Sjzp05sMEDmO7CUw /c34TtnF6+u3iPxVu8u3rEb/GxxWaaxLNi3J2eFjM390CejvpS01K/vG6Q6d6xILDthU GTtOtyw//tRo0akpy3lg00ncBcTdjCz8RpK2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MTPn9pDaNh5E8UGDLtN2UaoXgOwcHdY6Rk8RktepY3/ISwgrsLoMoRKxPbn/J6vS9I q6T7OcX7N/dTFiBXRdniRGAHzV5nBwL5wjjviHWR5t2tko2fWLViEzrG9Ex9eISFmCai FPu7GTgQrd5YbmxbNeTqJQpVVri18etJQdi5E= MIME-Version: 1.0 Received: by 10.204.66.73 with HTTP; Mon, 12 Apr 2010 10:47:47 -0700 (PDT) In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> Date: Mon, 12 Apr 2010 19:47:47 +0200 Received: by 10.204.74.77 with SMTP id t13mr5016632bkj.7.1271094467824; Mon, 12 Apr 2010 10:47:47 -0700 (PDT) Message-ID: From: Victor Pascual Avila To: Brett Tate Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 17:48:17 -0000 On Mon, Apr 12, 2010 at 7:10 PM, Brett Tate wrote: >> > I don't think that lets you off the hook. >> > We've learned from experience that we were too vague in >> > the past. =C2=A0So I would expect you to be less vague here - >> > being more explicit about what conditions justify violating >> > the SHOULD. >> >> And really using "MUST..., unless..." instead. > > Is making 503 with Retry-After usable (i.e. so it does more good than har= m) something that should be done within this draft and in this working grou= p? =C2=A0Or is that something that should be addressed within the hopefully= dispatched overload working group? Since, to some extent, the 503 + Retry-after mechanism represents an on/off overload control approach (w/ some known problems [1]), IMHO it deserves special attention within the so-expected overload control WG. [1] http://tools.ietf.org/html/rfc5390#section-5 Cheers, --=20 Victor Pascual =C3=81vila From pkyzivat@cisco.com Mon Apr 12 17:24:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C983A698A for ; Mon, 12 Apr 2010 17:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG5Gk5pNgXUU for ; Mon, 12 Apr 2010 17:24:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 93B063A6970 for ; Mon, 12 Apr 2010 17:24:43 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIRWw0tAZnwN/2dsb2JhbACbQ3Gic5kyhQwE X-IronPort-AV: E=Sophos;i="4.52,193,1270425600"; d="scan'208";a="101023452" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2010 00:24:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3D0ObQl010334; Tue, 13 Apr 2010 00:24:37 GMT Message-ID: <4BC3B9C9.7090108@cisco.com> Date: Mon, 12 Apr 2010 20:24:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 00:24:45 -0000 Brett Tate wrote: >>> I don't think that lets you off the hook. >>> We've learned from experience that we were too vague in >>> the past. So I would expect you to be less vague here - >>> being more explicit about what conditions justify violating >>> the SHOULD. >> And really using "MUST..., unless..." instead. > > Is making 503 with Retry-After usable (i.e. so it does more good than harm) something that should be done within this draft and in this working group? Or is that something that should be addressed within the hopefully dispatched overload working group? Well, now you ask the hard questions. With my chair hat on, IMO any changes to the behavior of 503 will at least need to be blessed by sipcore. (But I'm new as a sipcore chair, so I'm willing to learn from the other chair or the AD that is isn't so.) After that, I think it depends on what is to happen with this draft. If it is intended to be informational, then it can't make any normative changes. It can make any recommendations it wants as long as they don't require violating normative behavior. If its aspirations are higher, and maybe even if they aren't, then I think it makes sense to coordinate it with the work of the overload wg. (AFAIK we don't yet *have* an overload WG, but there is a mailing list, and I gather its expected that we will have the WG before long.) With my individual hat on I will recommend that it go there for some discussion of if/how it relates. Thanks, Paul From christer.holmberg@ericsson.com Mon Apr 12 22:49:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEAE3A697B for ; Mon, 12 Apr 2010 22:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keiRk31DfYPY for ; Mon, 12 Apr 2010 22:49:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9D8993A6853 for ; Mon, 12 Apr 2010 22:49:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-03-4bc405fef6dc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 38.70.23532.EF504CB4; Tue, 13 Apr 2010 07:49:51 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 13 Apr 2010 07:49:50 +0200 From: Christer Holmberg To: Paul Kyzivat , "Paul E. Jones" Date: Tue, 13 Apr 2010 07:49:48 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcraSGcGwLBSNWzXSfeoFn2z/3iUbwAhJcEg Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> In-Reply-To: <4BC3273D.7090902@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: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 05:49:59 -0000 Hi, I agree with Paul. I think that we should try to have a generic procedure, where we in the cas= e of SHOULD describe when something does not apply. Otherwise it's useless = when it comes to writing test specifications etc. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 12. huhtikuuta 2010 16:59 > To: Paul E. Jones > Cc: sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D=20 > Action:draft-jones-sip-options-ping-00.txt >=20 > [as individual] >=20 > Paul E. Jones wrote: > > Brett, > >=20 > > So, I think the only change we need in the draft is to=20 > change the word=20 > > "MUST" to "SHOULD" in the paragraph just before Section 8? >=20 > Let me just interject here that in the past we have=20 > frequently gotten into trouble by using SHOULD without=20 > qualification of what constitutes a valid reason for going=20 > against the SHOULD. Without actual text that clarifies that,=20 > SHOULD is often treated as if it said "you can claim=20 > conformance without implementing this." >=20 > Thanks, > Paul >=20 > > Paul > >=20 > >> -----Original Message----- > >> From: Brett Tate [mailto:brett@broadsoft.com] > >> Sent: Sunday, April 11, 2010 9:03 AM > >> To: Paul E. Jones; sipcore@ietf.org > >> Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > >> 00.txt > >> > >>> What in this draft violates the rule? > >> The draft is currently upgrading rfc3261's honoring Retry-After=20 > >> requirements from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to=20 > >> MUST (MUST NOT) levels. Thus it is preventing the UAC from making=20 > >> appropriate/configurable decisions concerning if/how it is=20 > willing to=20 > >> honor/apply the reception of 503 with Retry-After. > >> > >> For instance, the draft doesn't allow UAC to reduce the=20 > honoring of=20 > >> 503 with Retry-After value of 1 year to only apply for 30 seconds. > >> > >> For instance, the draft doesn't allow UAC to avoid=20 > applying the 503=20 > >> with Retry-After value to sending requests associated with=20 > emergency=20 > >> calls. > >> > >> For instance, the draft doesn't allow UAC to avoid=20 > applying the 503=20 > >> with Retry-After to sending requests within dialog. > >> > >> For instance, the draft doesn't allow UAC to avoid honoring a 503=20 > >> with Retry-After when response source ip-address is not=20 > equivalent to=20 > >> where the request was sent. Concerning their not=20 > matching, the draft=20 > >> currently does not mention it from a security risk or otherwise. > >> > >> For instance, the draft doesn't allow UAC to only apply=20 > the 503 with=20 > >> Retry-After to specific interfaces. More specifically if=20 > a UAC knows=20 > >> it should not trust/honor the 503 Retry-After value (because of a=20 > >> proxy rfc3261/draft non compliance or an insecure interface), the=20 > >> draft doesn't allow the device to instead not honor the=20 > 503 with Retry-After. > >> > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From kpfleming@digium.com Wed Apr 14 15:30:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EBC28C190 for ; Wed, 14 Apr 2010 15:30:58 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVnxUOkJsXiV for ; Wed, 14 Apr 2010 15:30:57 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id EC3FB28C1B4 for ; Wed, 14 Apr 2010 15:28:39 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1O2B4S-0008Su-PO; Wed, 14 Apr 2010 17:28:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C1556D8004; Wed, 14 Apr 2010 17:28:32 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJKYh3Vw0dfD; Wed, 14 Apr 2010 17:28:32 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 723A3D8002; Wed, 14 Apr 2010 17:28:32 -0500 (CDT) Message-ID: <4BC64190.9050002@digium.com> Date: Wed, 14 Apr 2010 17:28:32 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Paul E. Jones" References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> <747A6506A991724FB09B129B79D5FEB61480BBFAD1@EXMBXCLUS01.citservers.local> <002c01cad90b$0a9c17f0$1fd447d0$@com> In-Reply-To: <002c01cad90b$0a9c17f0$1fd447d0$@com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:30:58 -0000 Paul E. Jones wrote: > This is a problem general for SIP, since there is no way for a SIP entity to > know that a DNS query that returns 4 replies relates to the same or > different servers. I can't fix that problem in this draft :-) No, but in the 'normal' case, an INVITE is not directed to a RURI that contains an IP address and port number, it's directed to a RURI with a logical name for the 'service', and in that case, it's very logical for Retry-After returned in the 503 to apply to the entire 'service'. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From paulej@packetizer.com Wed Apr 14 22:31:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AAC3A659C for ; Wed, 14 Apr 2010 22:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQYrUqHN4K1U for ; Wed, 14 Apr 2010 22:31:18 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 42FED3A6B89 for ; Wed, 14 Apr 2010 22:26:46 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3F5PlIc004714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2010 01:25:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271309153; bh=XR78twFh3IOd9hivK1vqaBMpATHo4/oj11k0nxqWNew=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=GRs9EjmO/9pbSKplRmDcUzzMV1mvC3P5R6jZtyZVBSUtwpGaoSPHx/S5BC9ZB1RTY caXHHbaEZonFnWnhZHjA2XCr8pO/gOYE8gzuQUrujpppahKjHazHjjeDQ/6UAaDXtZ 4vinoav+qQpt6yDbQCMZfj0irHMXq98Xrf5wt2bE= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3F5PkuF011897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Apr 2010 01:25:46 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> In-Reply-To: <4BC338F9.80604@cisco.com> Date: Thu, 15 Apr 2010 01:25:40 -0400 Message-ID: <018a01cadc5c$167a5ba0$436f12e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcraUvEPA8se5GNcTt+kDyVGE4LSvwCCM81Q Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 05:31:20 -0000 > I think that's OK here, since what Brett was suggesting was that it > is > > already a SHOULD in effect in 3261. In any case, the worst thing > that > > happens here is that a device ignores the Retry-After header and > claims > > compliance. Apparently, some feel there are plenty of good reasons > to do > > so. > > I don't think that lets you off the hook. > We've learned from experience that we were too vague in the past. > So I would expect you to be less vague here - being more explicit about > what conditions justify violating the SHOULD. Shall I put it back to MUST? Keep in mind, we're not trying to re-define RFC 3261. Paul From christer.holmberg@ericsson.com Wed Apr 14 22:38:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBBF3A68F6 for ; Wed, 14 Apr 2010 22:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.344 X-Spam-Level: X-Spam-Status: No, score=-5.344 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iOqd9lIoQrJ for ; Wed, 14 Apr 2010 22:38:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 47EC03A67B2 for ; Wed, 14 Apr 2010 22:38:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1a-4bc6a65c4f54 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id AC.96.23532.C56A6CB4; Thu, 15 Apr 2010 07:38:36 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 15 Apr 2010 07:38:35 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Thu, 15 Apr 2010 07:38:34 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21D08B06ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 05:38:47 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21D08B06ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the keep-alive draft. Based on the "lessons learned" during the work on the info-events draft, I'= ve done some editorial changes. The TECHNICAL change, however, is that there is no longer a "=3Dyes" value = added to a "keep" parameter inserted by another entity, because it did not = work in all cases. The new solution is much more simple. An entity simply adds a "keep" parame= ter if it supports keep-alive, and once the route set/path is established e= ntities will then see whether the adjacent node supports keep-alives or not= . An open issue is whether, in the proxy-to-proxy heartbeat/ping case, whethe= r it should be possible to negotiate a keep-alive lifetime that extends the= dialog for which the keep-alives were negotiated. I guess the outcome of t= hat depends on what/if we are going to do with the options-ping draft. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep-02.txt Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC745E21D08B06ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a new version of the keep-alive draft.=
 
Based on the "lessons learned" during the w= ork on the info-events draft, I've done some editorial changes.
 
The TECHNICAL change, however, is that there is no lo= nger a "=3Dyes" value added to a "keep" parameter inser= ted by another entity, because it did not work in all cases.
 
The new solution is much more simple. An entity simpl= y adds a "keep" parameter if it supports keep-alive, and once the= route set/path is established entities will then see whether the adjacent = node supports keep-alives or not.
 
An open issue is whether, in the proxy-to-proxy heart= beat/ping case, whether it should be possible to negotiate a keep-alive lif= etime that extends the dialog for which the keep-alives were negotiated. I = guess the outcome of that depends on what/if we are going to do with the options-ping draft.
 
The draft can also be found at:
 
http://users.piuha.= net/cholmber/drafts/draft-ietf-sipcore-keep-02.txt
 
Regards,
 
Christer
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21D08B06ESESSCMS0354e_-- From root@core3.amsl.com Wed Apr 14 22:45:14 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BF5E63A6902; Wed, 14 Apr 2010 22:45:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100415054504.BF5E63A6902@core3.amsl.com> Date: Wed, 14 Apr 2010 22:45:04 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 05:45:14 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-02.txt Pages : 15 Date : 2010-04-14 This specification defines a new Session Initiation Protocol (SIP) header field parameter, "keep", that SIP entities can use to negotiate explicit support of the NAT keep-alive mechanisms defined in the SIP Outbound specification. The parameter is defined for cases where the SIP Outbound mechanism is not supported, or in cases where it cannot be applied. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14223306.I-D@ietf.org> --NextPart-- From paulej@packetizer.com Wed Apr 14 23:25:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926673A67B2 for ; Wed, 14 Apr 2010 23:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p-oy7gMxpet for ; Wed, 14 Apr 2010 23:25:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 19DA73A6765 for ; Wed, 14 Apr 2010 23:25:46 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3F6POkG007556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2010 02:25:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271312730; bh=/WXCiNR6zh4r3HayeKaZsTDWS9zVZfW72NqPe/3gUgc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=C45Adj44+KAqbk+8oif4AW+ZJjDD1A2erHiSlBh5/BGop5ahHOxPK7Ntn5mfGE8HH 9y0vp82cEBqGadhcpVY2LNIFqCZ+ENfl/er581hd2p6iKFfMzR5LZvDcO0HxYDQga7 TIByyguIiksOcW/FlT/hnhJnKiIS3Sqtq1braPWA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3F6POme012050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Apr 2010 02:25:24 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Brett Tate'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> In-Reply-To: <4BC3B9C9.7090108@cisco.com> Date: Thu, 15 Apr 2010 02:25:17 -0400 Message-ID: <01a401cadc64$6ab7a120$4026e360$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acran7exGP6h12eRRQ2NeN6yiqL2UwBw3CRg Content-Language: en-us Cc: sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:25:47 -0000 Paul, Brett, I looked at the OPTIONS ping draft and 3261 again. Perhaps I'm missing it and need to be reminded (and I note it's 2AM here), but what in the OPTIONS draft changes anything stated in 3261. The statement of concern is this, right? To avoid unduly taxing a receiving SIP entity, transmitters of OPTIONS messages MUST honor the Retry-After header field if received. When a 503 is used is in line with 3261: we're not suggesting new opportunities to send one. We're just saying that code should be used vs. other codes that don't have the same meaning. And, Retry-After should be honored. We say MUST, which I understand is a stronger word than SHOULD (and why I'm willing to soften it). Changing it to SHOULD would be in stronger agreement with 21.5.4 of 3261. A device would not send 503 with Retry-After lightly, nor are we proposing a change as to when a 503 is sent. So, is using "SHOULD" acceptable? Or is this really a problem? I understand the problems one can get into with the current wording in 3261, but what I'm failing to see, I guess, is how the OPTIONS ping draft makes this worse. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 12, 2010 8:25 PM > To: Brett Tate > Cc: Hadriel Kaplan; Paul E. Jones; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > > Brett Tate wrote: > >>> I don't think that lets you off the hook. > >>> We've learned from experience that we were too vague in > >>> the past. So I would expect you to be less vague here - > >>> being more explicit about what conditions justify violating > >>> the SHOULD. > >> And really using "MUST..., unless..." instead. > > > > Is making 503 with Retry-After usable (i.e. so it does more good than > harm) something that should be done within this draft and in this > working group? Or is that something that should be addressed within > the hopefully dispatched overload working group? > > > Well, now you ask the hard questions. > > With my chair hat on, IMO any changes to the behavior of 503 will at > least need to be blessed by sipcore. (But I'm new as a sipcore chair, > so > I'm willing to learn from the other chair or the AD that is isn't so.) > > After that, I think it depends on what is to happen with this draft. > > If it is intended to be informational, then it can't make any normative > changes. It can make any recommendations it wants as long as they don't > require violating normative behavior. > > If its aspirations are higher, and maybe even if they aren't, then I > think it makes sense to coordinate it with the work of the overload wg. > (AFAIK we don't yet *have* an overload WG, but there is a mailing list, > and I gather its expected that we will have the WG before long.) > > With my individual hat on I will recommend that it go there for some > discussion of if/how it relates. > > Thanks, > Paul > From paulej@packetizer.com Wed Apr 14 23:33:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564DE3A69D1 for ; Wed, 14 Apr 2010 23:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0OPWD-8L5u2 for ; Wed, 14 Apr 2010 23:33:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 52A363A695D for ; Wed, 14 Apr 2010 23:33:24 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3F6X8cw007815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2010 02:33:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271313195; bh=I2lp70lflty2l4bHSCnpYkikzgBi00n53jO6fxTmgIQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hUgapQtv/a+7yDAIeGQ8wCRaMgI+SRGfGOe2uEavnRIsGt6flfCY/zgU3gIJdYX1d eJ/DFX6dofLKN8VV4crH23x0XWlU1NNntYQmSjU363Pi33vlTOo7c0TJuxkFFrw9U9 O4IEBGKUUEzTfgYZiSibGN8+jHo4mhP3Le3GkVDk= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3F6X7FY012064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Apr 2010 02:33:07 -0400 From: "Paul E. Jones" To: "'Kevin P. Fleming'" References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> <747A6506A991724FB09B129B79D5FEB61480BBFAD1@EXMBXCLUS01.citservers.local> <002c01cad90b$0a9c17f0$1fd447d0$@com> <4BC64190.9050002@digium.com> In-Reply-To: <4BC64190.9050002@digium.com> Date: Thu, 15 Apr 2010 02:33:00 -0400 Message-ID: <01ac01cadc65$7f1b1790$7d5146b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrcIdUOGsWmu6HGTdeMs7XS0U5dygAQzlGQ Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:33:25 -0000 > > This is a problem general for SIP, since there is no way for a SIP > entity to > > know that a DNS query that returns 4 replies relates to the same or > > different servers. I can't fix that problem in this draft :-) > > No, but in the 'normal' case, an INVITE is not directed to a RURI that > contains an IP address and port number, it's directed to a RURI with a > logical name for the 'service', and in that case, it's very logical for > Retry-After returned in the 503 to apply to the entire 'service'. Messages are still transmitted to a certain server. RFC 3261 provides guidance as to when an entity should stop transmitting messages to a given server. The OPTIONS ping draft does not change that logic. Paul From john.elwell@siemens-enterprise.com Thu Apr 15 01:19:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E399E3A687B for ; Thu, 15 Apr 2010 01:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB3AP1CLG0o4 for ; Thu, 15 Apr 2010 01:19:20 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3EC523A6863 for ; Thu, 15 Apr 2010 01:19:18 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1559013; Thu, 15 Apr 2010 10:19:08 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C1E531EB82AB; Thu, 15 Apr 2010 10:19:08 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 15 Apr 2010 10:19:08 +0200 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 10:19:08 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+w 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: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 08:19:35 -0000 Christer, Why is this draft-ietf? I don't recall adopting anything of this nature as = a WG item. I have a major concern that the draft assumes a very specific to= pology. I remember discussing similar concerns on earlier iterations, but t= his new draft makes things worse, if anything. Details below: 1. For UAs that don't perform registration (e.g., gateways, media servers, = B2BUAs typically don't do registration), the provisions of section 4 seem a= bit restrictive. For example, between a proxy and a gateway, the gateway m= ust do the keep-alives, not the proxy. I don't necessarily have a problem w= ith this, but I wondered why there is this constraint. What I do have a pro= blem with is the UA-to-UA case (in particular, B2BUA-to-B2BUA), where, if t= his mechanism is to be used, clearly one of the UAs has to receive keep-ali= ves. 2. Also section 4.1 starts off by saying that this is all about keep-alive = between a UA and its edge proxy, which tends to rule out the cases above, a= nd also cases where a registering UA registers directly with its registrar,= not via an edge proxy. Also it seems to rule out cases where the proxy doe= s not record-route, so that for dialog keep-alive the UA would need to send= keep-alives to some other entity. 3. In 4.2.2: "When the UAC receives the response(s) to the initial request for the dialog, if the top-most Record-Route header field (edge proxy) of response(s) contains a "keep" parameter, the UAC MUST start to send keep-alives towards the edge proxy for the remaining duration of the dialog." This doesn't make sense. The response containing the "keep" parameter will = be received on the path of the request, but depending which entities have = record-routed, the dialog path may be different. A transport connection to = the first entity on the dialog path is not established until the next outbo= und or inbound request on that dialog, so "MUST start to send keep-alives t= owards the edge proxy" is unachievable in such cases. 4. In 4.3.1: "When a UAS receives an initial request for a dialog, if the top-most Record-Route header filed contains a "keep" parameter, and if the UAS is willing to send keep-alives associated with the dialog, it MUST insert a "keep" parameter in its Contact header field in the response(s) to the request. After that the UAS MUST start to send keep-alives towards the edge proxy, and it MUST send keep-alives for the remaining duration of the registration." I have a similar problem with this. 5. In 5.3.1: "When a proxy receives a dialog initiation request from its previous- hop proxy, and the top-most Record-Route header field of the request contains a "keep" parameter, if the proxy is willing to send and receive keep-alives from the previous-hop proxy for the associated dialog, the proxy MUST insert a "keep" parameter in its Record-Route header field of the associated response(s) sent towards the previous- hop proxy. After that the proxy MUST send keep-alives, and accept keep-alives sent from the previous-hop proxy, for the duration of the dialog." I have a similar problem with this. If the top-most Record-Route header fie= ld does not represent the previous hop proxy, there is no transport connect= ion established to allow you to start sending keep-alives at this time. 6. "When a proxy forwards a dialog initiation request towards its next- hop proxy, and it wants to negotiate the usage of keep-alives with that next-hop proxy, it MUST include a "keep" parameter in its Record-Record header field of the request." How does the proxy know that the next hop is a proxy, as opposed to a UA? A= ssuming it does know that the next hop is a proxy, how does it know that th= e next hop proxy will record-route? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 15 April 2010 06:39 > To: sipcore@ietf.org > Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 >=20 > =20 > Hi, > =20 > I've submitted a new version of the keep-alive draft. > =20 > Based on the "lessons learned" during the work on the=20 > info-events draft, I've done some editorial changes. > =20 > The TECHNICAL change, however, is that there is no longer a=20 > "=3Dyes" value added to a "keep" parameter inserted by another=20 > entity, because it did not work in all cases. > =20 > The new solution is much more simple. An entity simply adds a=20 > "keep" parameter if it supports keep-alive, and once the=20 > route set/path is established entities will then see whether=20 > the adjacent node supports keep-alives or not. > =20 > An open issue is whether, in the proxy-to-proxy=20 > heartbeat/ping case, whether it should be possible to=20 > negotiate a keep-alive lifetime that extends the dialog for=20 > which the keep-alives were negotiated. I guess the outcome of=20 > that depends on what/if we are going to do with the=20 > options-ping draft. > =20 > The draft can also be found at: > =20 > http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep > -02.txt=20 > p-02.txt>=20 > =20 > Regards, > =20 > Christer > = From christer.holmberg@ericsson.com Thu Apr 15 02:43:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5531C3A69EE for ; Thu, 15 Apr 2010 02:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.341 X-Spam-Level: X-Spam-Status: No, score=-5.341 tagged_above=-999 required=5 tests=[AWL=1.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+FLxj2QUN0X for ; Thu, 15 Apr 2010 02:43:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C7BB53A68E3 for ; Thu, 15 Apr 2010 02:43:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-02-4bc6dfc21047 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F2.29.23532.3CFD6CB4; Thu, 15 Apr 2010 11:43:31 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 15 Apr 2010 11:43:30 +0200 From: Christer Holmberg To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 11:43:30 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 09:43:40 -0000 Hi John, >Why is this draft-ietf? I don't recall adopting anything of this nature as= a WG item.=20 The draft has been adopted a long time ago. It has just been on hold for a = while, partly because of the INFO work.=20 Before answering to your specific comments, I want to clarify one thing: When I talk about "next hop" and "previous hop", I refer to the adjacent no= de in the established registration/dialog path - not a hop which will not b= e part of that path. That needs to be clarfied. And, this is the reason, based on a comment from yourself, that we decided = to NOT define the "keep" parameter for the Via header field, since not all = entities that insert Via will be part of the path. -------- >I have a major concern that the draft assumes a very specific topology. I = remember discussing similar concerns on earlier iterations, but this new dr= aft=20 >makes things worse, if anything. Details below: >=20 >1. For UAs that don't perform registration (e.g., gateways,=20 >media servers, B2BUAs typically don't do registration), the=20 >provisions of section 4 seem a bit restrictive. For example,=20 >between a proxy and a gateway, the gateway must do the=20 >keep-alives, not the proxy. I don't necessarily have a=20 >problem with this, but I wondered why there is this=20 >constraint. The idea is that keep-alives would not be sent towards UAs. It is the UAs t= hat need to send keep-alives in order to keep the NAT binding open. -------- >What I do have a problem with is the UA-to-UA case (in particular, B2BUA-t= o-B2BUA), where, if this mechanism is to be used, clearly one of the UAs ha= s to=20 >receive keep-alives. The initial scope of the draft was to use the Outbound topology, and assume= there is an edge proxy. After that people asked to also cover the proxy-to= -proxy case. However, if we want to cover the direct UA-to-UA case I guess we could say = that the UAs check for a Record-Route with "keep", and if there is none the= n check for a Contact with "keep". -------- >2. Also section 4.1 starts off by saying that this is all=20 >about keep-alive between a UA and its edge proxy, which tends=20 >to rule out the cases above, and also cases where a=20 >registering UA registers directly with its registrar, not via=20 >an edge proxy. Also it seems to rule out cases where the=20 >proxy does not record-route, so that for dialog keep-alive=20 >the UA would need to send keep-alives to some other entity. See my comment about the scope of the draft above. However, as for the UA-to-UA case, I don't have a problem if we want to als= o cover the direct UA-to-Registrar case. I guess the question then is how t= he registrar will indicate its support of keep-alives, since it normally do= esn't insert a Path header field. -------- >3. In 4.2.2: >"When the UAC receives the response(s) to the initial request for the >dialog, if the top-most Record-Route header field (edge proxy) of >response(s) contains a "keep" parameter, the UAC MUST start to send >keep-alives towards the edge proxy for the remaining=20 >duration of the dialog." >This doesn't make sense. The response containing the "keep"=20 >parameter will be received on the path of the request, but=20 >depending which entities have record-routed, the dialog path=20 >may be different. A transport connection to the first entity=20 >on the dialog path is not established until the next outbound=20 >or inbound request on that dialog, so "MUST start to send=20 >keep-alives towards the edge proxy" is unachievable in such cases. The UAC will send the keep-alives towards the address indicated in the Reco= rd-Route - NOT to where it sent the INVITE request. -------- >4. In 4.3.1: >"When a UAS receives an initial request for a dialog, if the top-most >Record-Route header filed contains a "keep" parameter, and=20 >if the UAS is willing to send keep-alives associated with the dialog, it M= UST >insert a "keep" parameter in its Contact header field in the >response(s) to the request. After that the UAS MUST start to send >keep-alives towards the edge proxy, and it MUST send keep-alives for >the remaining duration of the registration." >I have a similar problem with this. Again, the UAS will send the keep-alives towards the address indicated in t= he Record-Route. -------- >5. In 5.3.1: >"When a proxy receives a dialog initiation request from its previous- >hop proxy, and the top-most Record-Route header field of the request >contains a "keep" parameter, if the proxy is willing to send and >receive keep-alives from the previous-hop proxy for the associated >dialog, the proxy MUST insert a "keep" parameter in its=20 >Record-Route header field of the associated response(s) sent towards=20 >the previous-hop proxy. After that the proxy MUST send keep-alives, and a= ccept >keep-alives sent from the previous-hop proxy, for the duration of the >dialog." >I have a similar problem with this. If the top-most=20 >Record-Route header field does not represent the previous hop=20 >proxy, there is no transport connection established to allow=20 >you to start sending keep-alives at this time. As I said in the beginning of the reply, "next hop" and "previous hop" are = probably confusing terminology - at least without proper explanation. -------- >6. "When a proxy forwards a dialog initiation request towards=20 >its next- hop proxy, and it wants to negotiate the usage of keep-alives wi= th >that next-hop proxy, it MUST include a "keep" parameter in its >Record-Record header field of the request." >How does the proxy know that the next hop is a proxy, as=20 >opposed to a UA?=20 I guess that would be a edge-to-UA case. But, I guess that could be clarifi= ed. -------- >Assuming it does know that the next hop is a proxy, how does it know that = the next hop proxy will record-route? See previous comments on "next hop" and "previous hop" terminology. Regards, Christer From john.elwell@siemens-enterprise.com Thu Apr 15 03:27:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB1E3A69EE for ; Thu, 15 Apr 2010 03:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiTgxYAEVLI5 for ; Thu, 15 Apr 2010 03:27:12 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8C8F13A6AE6 for ; Thu, 15 Apr 2010 03:26:39 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1560059; Thu, 15 Apr 2010 12:26:17 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 9EB3B1EB82AE; Thu, 15 Apr 2010 12:26:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 15 Apr 2010 12:26:17 +0200 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 12:26:16 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764A== 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: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:27:13 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 15 April 2010 10:44 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Draft new version: draft-ietf-sipcore-keep-02 >=20 >=20 > Hi John, >=20 > >Why is this draft-ietf? I don't recall adopting anything of=20 > this nature as a WG item.=20 >=20 > The draft has been adopted a long time ago. It has just been=20 > on hold for a while, partly because of the INFO work.=20 [JRE] I know, but this draft looks very different from the one adopted as W= G item, but never mind, the important thing is to address the comments. >=20 > Before answering to your specific comments, I want to clarify=20 > one thing: >=20 > When I talk about "next hop" and "previous hop", I refer to=20 > the adjacent node in the established registration/dialog path=20 > - not a hop which will not be part of that path. That needs=20 > to be clarfied. >=20 > And, this is the reason, based on a comment from yourself,=20 > that we decided to NOT define the "keep" parameter for the=20 > Via header field, since not all entities that insert Via will=20 > be part of the path. [JRE] Yes, I understand the problems with the old Via-based proposal, but o= n reading the present draft it didn't seem to help much. >=20 > -------- >=20 > >I have a major concern that the draft assumes a very=20 > specific topology. I remember discussing similar concerns on=20 > earlier iterations, but this new draft=20 > >makes things worse, if anything. Details below: > >=20 > >1. For UAs that don't perform registration (e.g., gateways,=20 > >media servers, B2BUAs typically don't do registration), the=20 > >provisions of section 4 seem a bit restrictive. For example,=20 > >between a proxy and a gateway, the gateway must do the=20 > >keep-alives, not the proxy. I don't necessarily have a=20 > >problem with this, but I wondered why there is this=20 > >constraint. >=20 > The idea is that keep-alives would not be sent towards UAs.=20 > It is the UAs that need to send keep-alives in order to keep=20 > the NAT binding open. >=20 > -------- >=20 > >What I do have a problem with is the UA-to-UA case (in=20 > particular, B2BUA-to-B2BUA), where, if this mechanism is to=20 > be used, clearly one of the UAs has to=20 > >receive keep-alives. >=20 > The initial scope of the draft was to use the Outbound=20 > topology, and assume there is an edge proxy. After that=20 > people asked to also cover the proxy-to-proxy case. >=20 > However, if we want to cover the direct UA-to-UA case I guess=20 > we could say that the UAs check for a Record-Route with=20 > "keep", and if there is none then check for a Contact with "keep". [JRE] Many people use B2BUAs rather than proxies, and I would expect the dr= aft to be equally applicable between B2BUAs. Also I would have expected the= draft to be applicable between a proxy/B2BUA and a non-registering UA, or = between a proxy/B2BUA and a directly registering UA (without an edge proxy)= . In other words, filling all the gaps that aren't covered by sip-outbound. >=20 > -------- >=20 > >2. Also section 4.1 starts off by saying that this is all=20 > >about keep-alive between a UA and its edge proxy, which tends=20 > >to rule out the cases above, and also cases where a=20 > >registering UA registers directly with its registrar, not via=20 > >an edge proxy. Also it seems to rule out cases where the=20 > >proxy does not record-route, so that for dialog keep-alive=20 > >the UA would need to send keep-alives to some other entity. >=20 > See my comment about the scope of the draft above. >=20 > However, as for the UA-to-UA case, I don't have a problem if=20 > we want to also cover the direct UA-to-Registrar case. I=20 > guess the question then is how the registrar will indicate=20 > its support of keep-alives, since it normally doesn't insert=20 > a Path header field. [JRE] Well, the previous proposal used the Via header field, so in moving a= way from Via we seem to have lost a capability. Perhaps a UA wanting to use= this mechanism must insert a Path header field - I haven't thought through= the consequences, however. >=20 > -------- >=20 > >3. In 4.2.2: > >"When the UAC receives the response(s) to the initial request for the > >dialog, if the top-most Record-Route header field (edge proxy) of > >response(s) contains a "keep" parameter, the UAC MUST start to send > >keep-alives towards the edge proxy for the remaining=20 > >duration of the dialog." > >This doesn't make sense. The response containing the "keep"=20 > >parameter will be received on the path of the request, but=20 > >depending which entities have record-routed, the dialog path=20 > >may be different. A transport connection to the first entity=20 > >on the dialog path is not established until the next outbound=20 > >or inbound request on that dialog, so "MUST start to send=20 > >keep-alives towards the edge proxy" is unachievable in such cases. >=20 > The UAC will send the keep-alives towards the address=20 > indicated in the Record-Route - NOT to where it sent the=20 > INVITE request. [JRE] How can it sent keep-alives when it hasn't established a transport co= nnection yet? It must wait for the transport connection to be established, = which means waiting for an inbound or outbound mid-dialog request. If it's = an inbound request, however, which entity should be responsible for keep-al= ives? >=20 > -------- >=20 > >4. In 4.3.1: > >"When a UAS receives an initial request for a dialog, if the top-most > >Record-Route header filed contains a "keep" parameter, and=20 > >if the UAS is willing to send keep-alives associated with=20 > the dialog, it MUST > >insert a "keep" parameter in its Contact header field in the > >response(s) to the request. After that the UAS MUST start to send > >keep-alives towards the edge proxy, and it MUST send keep-alives for > >the remaining duration of the registration." > >I have a similar problem with this. >=20 > Again, the UAS will send the keep-alives towards the address=20 > indicated in the Record-Route. [JRE] Same problem. >=20 > -------- >=20 > >5. In 5.3.1: > >"When a proxy receives a dialog initiation request from its previous- > >hop proxy, and the top-most Record-Route header field of the request > >contains a "keep" parameter, if the proxy is willing to send and > >receive keep-alives from the previous-hop proxy for the associated > >dialog, the proxy MUST insert a "keep" parameter in its=20 > >Record-Route header field of the associated response(s) sent towards=20 > >the previous-hop proxy. After that the proxy MUST send=20 > keep-alives, and accept > >keep-alives sent from the previous-hop proxy, for the duration of the > >dialog." > >I have a similar problem with this. If the top-most=20 > >Record-Route header field does not represent the previous hop=20 > >proxy, there is no transport connection established to allow=20 > >you to start sending keep-alives at this time. >=20 > As I said in the beginning of the reply, "next hop" and=20 > "previous hop" are probably confusing terminology - at least=20 > without proper explanation. [JRE] OK, but this still doesn't address my concern about the absence of a = transport connection. >=20 > -------- >=20 > >6. "When a proxy forwards a dialog initiation request towards=20 > >its next- hop proxy, and it wants to negotiate the usage of=20 > keep-alives with > >that next-hop proxy, it MUST include a "keep" parameter in its > >Record-Record header field of the request." > >How does the proxy know that the next hop is a proxy, as=20 > >opposed to a UA?=20 >=20 > I guess that would be a edge-to-UA case. But, I guess that=20 > could be clarified. [JRE] As a proxy, how do I know I am the "edge", i.e., how do I know the ne= xt entity is a UA? Even in the IMS P-CSCF case, I don't know - there could = be a PBX behind it. >=20 > -------- >=20 > >Assuming it does know that the next hop is a proxy, how does=20 > it know that the next hop proxy will record-route? >=20 > See previous comments on "next hop" and "previous hop" terminology. [JRE] The words "When a proxy forwards a dialog initiation request towards = its next-hop proxy" do not make sense - a proxy simply forwards a request t= o the next hop entity. Until it receives a response, it has no idea whether= the entity it forwarded the request to is a UA, a non-record-routing proxy= or a record-routing proxy, i.e., it has no idea whether it has sent it to = something that complies with your definition of "next-hop proxy". John From christer.holmberg@ericsson.com Thu Apr 15 03:57:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC12028C0F0 for ; Thu, 15 Apr 2010 03:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB5VLyOs3BSr for ; Thu, 15 Apr 2010 03:57:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C9BFB3A6939 for ; Thu, 15 Apr 2010 03:57:23 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ff-4bc6f10b4055 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 08.AB.23740.B01F6CB4; Thu, 15 Apr 2010 12:57:15 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 15 Apr 2010 12:57:14 +0200 From: Christer Holmberg To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 12:57:13 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:57:32 -0000 Hi John,=20 >>Why is this draft-ietf? I don't recall adopting anything of this nature a= s a WG item.=20 >>=20 >>The draft has been adopted a long time ago. It has just been on hold=20 >>for a while, partly because of the INFO work. >[JRE] I know, but this draft looks very different from the one adopted as = WG item, Please compare the first and last version of the Info-events draft :) Seriously, I agree there were editorial changes, but the only technical cha= nge was to not use the "=3Dyes" parameter. And, some of the editorial chang= es are also based on that change. =20 >>Before answering to your specific comments, I want to clarify one thing: >>=20 >>When I talk about "next hop" and "previous hop", I refer to=20 >>the adjacent node in the established registration/dialog path=20 >>- not a hop which will not be part of that path. That needs=20 >>to be clarfied. >>=20 >>And, this is the reason, based on a comment from yourself,=20 >>that we decided to NOT define the "keep" parameter for the=20 >>Via header field, since not all entities that insert Via will=20 >>be part of the path. >[JRE] Yes, I understand the problems with the old Via-based=20 >proposal, but on reading the present draft it didn't seem to=20 >help much. Keep in mind that in Stockholm we decided to use Contact/Path/Record-Route = instead of Via, so that is an existing agreement. The change in this version is to not use the "=3Dyes" value. But, as I said earlier, the "next/previous hop" terminology is confusing, b= ut I *AM* referring to adjacent nodes in the established path :) -------- >>>I have a major concern that the draft assumes a very=20 >>>specific topology. I remember discussing similar concerns on=20 >>>earlier iterations, but this new draft=20 >>>makes things worse, if anything. Details below: >>>=20 >>>1. For UAs that don't perform registration (e.g., gateways,=20 >>>media servers, B2BUAs typically don't do registration), the=20 >>>provisions of section 4 seem a bit restrictive. For example,=20 >>>between a proxy and a gateway, the gateway must do the=20 >>>keep-alives, not the proxy. I don't necessarily have a=20 >>>problem with this, but I wondered why there is this=20 >>>constraint. >>=20 >>The idea is that keep-alives would not be sent towards UAs.=20 >>It is the UAs that need to send keep-alives in order to keep=20 >>the NAT binding open. >>=20 >>-------- >>=20 >>>What I do have a problem with is the UA-to-UA case (in=20 >>>particular, B2BUA-to-B2BUA), where, if this mechanism is to=20 >>>be used, clearly one of the UAs has to=20 >>>receive keep-alives. >>=20 >>The initial scope of the draft was to use the Outbound=20 >>topology, and assume there is an edge proxy. After that=20 >>people asked to also cover the proxy-to-proxy case. >>=20 >>However, if we want to cover the direct UA-to-UA case I guess=20 >>we could say that the UAs check for a Record-Route with=20 >>"keep", and if there is none then check for a Contact with "keep". >[JRE] Many people use B2BUAs rather than proxies, and I would=20 >expect the draft to be equally applicable between B2BUAs.=20 >Also I would have expected the draft to be applicable between=20 >a proxy/B2BUA and a non-registering UA, or between a=20 >proxy/B2BUA and a directly registering UA (without an edge=20 >proxy). In other words, filling all the gaps that aren't=20 >covered by sip-outbound. Since a B2BUA acts as a UA, I don't we need to separate them. If we solve U= A-to-UA we also solve UA-to-B2BUA. ---------- >>>2. Also section 4.1 starts off by saying that this is all=20 >>>about keep-alive between a UA and its edge proxy, which tends=20 >>>to rule out the cases above, and also cases where a=20 >>>registering UA registers directly with its registrar, not via=20 >>>an edge proxy. Also it seems to rule out cases where the=20 >>>proxy does not record-route, so that for dialog keep-alive=20 >>>the UA would need to send keep-alives to some other entity. >>=20 >>See my comment about the scope of the draft above. >>=20 >>However, as for the UA-to-UA case, I don't have a problem if=20 >>we want to also cover the direct UA-to-Registrar case. I=20 >>guess the question then is how the registrar will indicate=20 >>its support of keep-alives, since it normally doesn't insert=20 >>a Path header field. >[JRE] Well, the previous proposal used the Via header field,=20 >so in moving away from Via we seem to have lost a capability.=20 >Perhaps a UA wanting to use this mechanism must insert a Path=20 >header field - I haven't thought through the consequences, however. The UA inserts Contact so that is not a problem. The question is how the re= gistrar would indicate support. --------- >>>3. In 4.2.2: >>>"When the UAC receives the response(s) to the initial=20 >>>request for the dialog, if the top-most Record-Route header field (edge = proxy) of >>>response(s) contains a "keep" parameter, the UAC MUST start to send >>>keep-alives towards the edge proxy for the remaining=20 >>>duration of the dialog." >>>This doesn't make sense. The response containing the "keep"=20 >>>parameter will be received on the path of the request, but=20 >>>depending which entities have record-routed, the dialog path=20 >>>may be different. A transport connection to the first entity=20 >>>on the dialog path is not established until the next outbound=20 >>>or inbound request on that dialog, so "MUST start to send=20 >>>keep-alives towards the edge proxy" is unachievable in such cases. >>=20 >>The UAC will send the keep-alives towards the address=20 >>indicated in the Record-Route - NOT to where it sent the=20 >>INVITE request. >[JRE] How can it sent keep-alives when it hasn't established=20 >a transport connection yet? It must wait for the transport=20 >connection to be established, which means waiting for an=20 >inbound or outbound mid-dialog request. If it's an inbound=20 >request, however, which entity should be responsible for keep-alives? What prevents the UAC from establishing the transport connection without wa= iting for any mid-dialog request to be sent? And, unless the UAC establishes the connnection, it won't even be able to r= eceive inbound requests in case there is a NAT. --------- >>>4. In 4.3.1: >>>"When a UAS receives an initial request for a dialog, if=20 >>>the top-most Record-Route header filed contains a "keep" parameter, and= =20 >>>if the UAS is willing to send keep-alives associated with=20 >>>the dialog, it MUST insert a "keep" parameter in its Contact header fiel= d in the >>>response(s) to the request. After that the UAS MUST start to send >>>keep-alives towards the edge proxy, and it MUST send keep-alives for >>>the remaining duration of the registration." >>>I have a similar problem with this. >>=20 >>Again, the UAS will send the keep-alives towards the address=20 >>indicated in the Record-Route. >[JRE] Same problem. Same answer :) --------- >>>5. In 5.3.1: >>>"When a proxy receives a dialog initiation request from=20 >>>its previous-hop proxy, and the top-most Record-Route header field of=20 >>>the request contains a "keep" parameter, if the proxy is willing to send= and >>>receive keep-alives from the previous-hop proxy for the associated >>>dialog, the proxy MUST insert a "keep" parameter in its=20 >>>Record-Route header field of the associated response(s) sent towards=20 >>>the previous-hop proxy. After that the proxy MUST send keep-alives, and= accept >>>keep-alives sent from the previous-hop proxy, for the duration of the >>>dialog." >>>I have a similar problem with this. If the top-most=20 >>>Record-Route header field does not represent the previous hop=20 >>>proxy, there is no transport connection established to allow=20 >>>you to start sending keep-alives at this time. >>=20 >>As I said in the beginning of the reply, "next hop" and=20 >>"previous hop" are probably confusing terminology - at least=20 >>without proper explanation. >[JRE] OK, but this still doesn't address my concern about the=20 >absence of a transport connection. See above. -------- >>>6. "When a proxy forwards a dialog initiation request towards=20 >>>its next- hop proxy, and it wants to negotiate the usage of=20 >>>keep-alives with >>>that next-hop proxy, it MUST include a "keep" parameter in its >>>Record-Record header field of the request." >>>How does the proxy know that the next hop is a proxy, as=20 >>>opposed to a UA?=20 >>=20 >>I guess that would be a edge-to-UA case. But, I guess that=20 >>could be clarified. >[JRE] As a proxy, how do I know I am the "edge", i.e., how do=20 >I know the next entity is a UA? Even in the IMS P-CSCF case,=20 >I don't know - there could be a PBX behind it. When the proxy get the response, if there are no Record-Routes between the = proxy and the UA, the proxy is adjacent to the UA. --------- >>>Assuming it does know that the next hop is a proxy, how does=20 >>>it know that the next hop proxy will record-route? >>=20 >>See previous comments on "next hop" and "previous hop" terminology. >[JRE] The words "When a proxy forwards a dialog initiation=20 >request towards its next-hop proxy" do not make sense - a=20 >proxy simply forwards a request to the next hop entity. Until=20 >it receives a response, it has no idea whether the entity it=20 >forwarded the request to is a UA, a non-record-routing proxy=20 >or a record-routing proxy, i.e., it has no idea whether it=20 >has sent it to something that complies with your definition=20 >of "next-hop proxy". I agree. So, the text could probably be more generic, and the actions then = depend on what comes in the answer (Record-Route or Contact). Regards, Christer From pkyzivat@cisco.com Thu Apr 15 05:55:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813D13A6A29 for ; Thu, 15 Apr 2010 05:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmaee+9VSxBq for ; Thu, 15 Apr 2010 05:55:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DF3CE28C208 for ; Thu, 15 Apr 2010 05:51:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFaoxktAZnwM/2dsb2JhbACbbnGjdJokhQ4E X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="101892856" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2010 12:51:32 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FCpV33009319; Thu, 15 Apr 2010 12:51:31 GMT Message-ID: <4BC70BD6.4060601@cisco.com> Date: Thu, 15 Apr 2010 08:51:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <018a01cadc5c$167a5ba0$436f12e0$@com> In-Reply-To: <018a01cadc5c$167a5ba0$436f12e0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 12:55:12 -0000 I'm ok with the SHOULD since that is what is in 3261. What I would prefer to see is some enumeration of the cases when its appropriate to violate the SHOULD. Thanks, Paul Paul E. Jones wrote: >> I think that's OK here, since what Brett was suggesting was that it >> is >>> already a SHOULD in effect in 3261. In any case, the worst thing >> that >>> happens here is that a device ignores the Retry-After header and >> claims >>> compliance. Apparently, some feel there are plenty of good reasons >> to do >>> so. >> I don't think that lets you off the hook. >> We've learned from experience that we were too vague in the past. >> So I would expect you to be less vague here - being more explicit about >> what conditions justify violating the SHOULD. > > Shall I put it back to MUST? Keep in mind, we're not trying to re-define > RFC 3261. > > Paul > > > From john.elwell@siemens-enterprise.com Thu Apr 15 06:31:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F90A28C221 for ; Thu, 15 Apr 2010 06:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8iRbtXwKheU for ; Thu, 15 Apr 2010 06:31:37 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 89D8B3A67A2 for ; Thu, 15 Apr 2010 06:27:50 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1564431; Thu, 15 Apr 2010 15:27:43 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6CB721EB82AB; Thu, 15 Apr 2010 15:27:43 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 15 Apr 2010 15:27:43 +0200 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 15:27:41 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQAAVazAA= 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: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 13:31:39 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 15 April 2010 11:57 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Draft new version: draft-ietf-sipcore-keep-02 >=20 >=20 > Hi John,=20 >=20 > >>Why is this draft-ietf? I don't recall adopting anything of=20 > this nature as a WG item.=20 > >>=20 > >>The draft has been adopted a long time ago. It has just=20 > been on hold=20 > >>for a while, partly because of the INFO work. > >[JRE] I know, but this draft looks very different from the=20 > one adopted as WG item, >=20 > Please compare the first and last version of the Info-events draft :) >=20 > Seriously, I agree there were editorial changes, but the only=20 > technical change was to not use the "=3Dyes" parameter. And,=20 > some of the editorial changes are also based on that change. [JRE] This is not true. -00 and -01 both used Via, now we use Path, Record-= Route and Contact. That is a completely different solution. I agree that -0= 2 might be moving in the right direction. > =20 > >>Before answering to your specific comments, I want to=20 > clarify one thing: > >>=20 > >>When I talk about "next hop" and "previous hop", I refer to=20 > >>the adjacent node in the established registration/dialog path=20 > >>- not a hop which will not be part of that path. That needs=20 > >>to be clarfied. > >>=20 > >>And, this is the reason, based on a comment from yourself,=20 > >>that we decided to NOT define the "keep" parameter for the=20 > >>Via header field, since not all entities that insert Via will=20 > >>be part of the path. > >[JRE] Yes, I understand the problems with the old Via-based=20 > >proposal, but on reading the present draft it didn't seem to=20 > >help much. >=20 > Keep in mind that in Stockholm we decided to use=20 > Contact/Path/Record-Route instead of Via, so that is an=20 > existing agreement. [JRE] Well, I could not find any mailing list endorsement of this following= Stockholm, and that is nearly one year ago, so my memory failed me. The mi= nutes just state: "Option 2 from slides: "Nodes which are adjacent in a rou= te set/registration path"", and don't say anything about the header fields.= Unfortunately the link to the slides is broken. Anyway, we should focus on= fixing the present draft. >=20 > The change in this version is to not use the "=3Dyes" value. >=20 > But, as I said earlier, the "next/previous hop" terminology=20 > is confusing, but I *AM* referring to adjacent nodes in the=20 > established path :) >=20 > -------- >=20 > >>>I have a major concern that the draft assumes a very=20 > >>>specific topology. I remember discussing similar concerns on=20 > >>>earlier iterations, but this new draft=20 > >>>makes things worse, if anything. Details below: > >>>=20 > >>>1. For UAs that don't perform registration (e.g., gateways,=20 > >>>media servers, B2BUAs typically don't do registration), the=20 > >>>provisions of section 4 seem a bit restrictive. For example,=20 > >>>between a proxy and a gateway, the gateway must do the=20 > >>>keep-alives, not the proxy. I don't necessarily have a=20 > >>>problem with this, but I wondered why there is this=20 > >>>constraint. > >>=20 > >>The idea is that keep-alives would not be sent towards UAs.=20 > >>It is the UAs that need to send keep-alives in order to keep=20 > >>the NAT binding open. > >>=20 > >>-------- > >>=20 > >>>What I do have a problem with is the UA-to-UA case (in=20 > >>>particular, B2BUA-to-B2BUA), where, if this mechanism is to=20 > >>>be used, clearly one of the UAs has to=20 > >>>receive keep-alives. > >>=20 > >>The initial scope of the draft was to use the Outbound=20 > >>topology, and assume there is an edge proxy. After that=20 > >>people asked to also cover the proxy-to-proxy case. > >>=20 > >>However, if we want to cover the direct UA-to-UA case I guess=20 > >>we could say that the UAs check for a Record-Route with=20 > >>"keep", and if there is none then check for a Contact with "keep". > >[JRE] Many people use B2BUAs rather than proxies, and I would=20 > >expect the draft to be equally applicable between B2BUAs.=20 > >Also I would have expected the draft to be applicable between=20 > >a proxy/B2BUA and a non-registering UA, or between a=20 > >proxy/B2BUA and a directly registering UA (without an edge=20 > >proxy). In other words, filling all the gaps that aren't=20 > >covered by sip-outbound. >=20 > Since a B2BUA acts as a UA, I don't we need to separate them.=20 > If we solve UA-to-UA we also solve UA-to-B2BUA. [JRE] Fine, but the present draft doesn't seem to work for UA-to-UA. >=20 > >>>2. Also section 4.1 starts off by saying that this is all=20 > >>>about keep-alive between a UA and its edge proxy, which tends=20 > >>>to rule out the cases above, and also cases where a=20 > >>>registering UA registers directly with its registrar, not via=20 > >>>an edge proxy. Also it seems to rule out cases where the=20 > >>>proxy does not record-route, so that for dialog keep-alive=20 > >>>the UA would need to send keep-alives to some other entity. > >>=20 > >>See my comment about the scope of the draft above. > >>=20 > >>However, as for the UA-to-UA case, I don't have a problem if=20 > >>we want to also cover the direct UA-to-Registrar case. I=20 > >>guess the question then is how the registrar will indicate=20 > >>its support of keep-alives, since it normally doesn't insert=20 > >>a Path header field. > >[JRE] Well, the previous proposal used the Via header field,=20 > >so in moving away from Via we seem to have lost a capability.=20 > >Perhaps a UA wanting to use this mechanism must insert a Path=20 > >header field - I haven't thought through the consequences, however. >=20 > The UA inserts Contact so that is not a problem. The question=20 > is how the registrar would indicate support. [JRE] If the registrar receives Path in the request, it could send Path in = the response. >=20 >=20 > --------- >=20 >=20 > >>>3. In 4.2.2: > >>>"When the UAC receives the response(s) to the initial=20 > >>>request for the dialog, if the top-most Record-Route=20 > header field (edge proxy) of > >>>response(s) contains a "keep" parameter, the UAC MUST start to send > >>>keep-alives towards the edge proxy for the remaining=20 > >>>duration of the dialog." > >>>This doesn't make sense. The response containing the "keep"=20 > >>>parameter will be received on the path of the request, but=20 > >>>depending which entities have record-routed, the dialog path=20 > >>>may be different. A transport connection to the first entity=20 > >>>on the dialog path is not established until the next outbound=20 > >>>or inbound request on that dialog, so "MUST start to send=20 > >>>keep-alives towards the edge proxy" is unachievable in such cases. > >>=20 > >>The UAC will send the keep-alives towards the address=20 > >>indicated in the Record-Route - NOT to where it sent the=20 > >>INVITE request. > >[JRE] How can it sent keep-alives when it hasn't established=20 > >a transport connection yet? It must wait for the transport=20 > >connection to be established, which means waiting for an=20 > >inbound or outbound mid-dialog request. If it's an inbound=20 > >request, however, which entity should be responsible for keep-alives? >=20 > What prevents the UAC from establishing the transport=20 > connection without waiting for any mid-dialog request to be sent? [JRE] Well, nothing I guess, except that isn't SIP. What would the next hop= do if it receives a TCP connection without any SIP message for a while, or= receives an empty UDP packet? >=20 > And, unless the UAC establishes the connnection, it won't=20 > even be able to receive inbound requests in case there is a NAT. [JRE] True, and in such cases I would expect the first proxy to record-rout= e, so no issue. The point is, there are situations that the present draft d= oesn't deal with. I am happy to be convinced that you don't need keep-alive= in cases that aren't covered by the draft, but we haven't had that discuss= ion. >=20 >=20 > --------- >=20 >=20 > >>>4. In 4.3.1: > >>>"When a UAS receives an initial request for a dialog, if=20 > >>>the top-most Record-Route header filed contains a "keep"=20 > parameter, and=20 > >>>if the UAS is willing to send keep-alives associated with=20 > >>>the dialog, it MUST insert a "keep" parameter in its=20 > Contact header field in the > >>>response(s) to the request. After that the UAS MUST start to send > >>>keep-alives towards the edge proxy, and it MUST send=20 > keep-alives for > >>>the remaining duration of the registration." > >>>I have a similar problem with this. > >>=20 > >>Again, the UAS will send the keep-alives towards the address=20 > >>indicated in the Record-Route. > >[JRE] Same problem. >=20 > Same answer :) >=20 >=20 > --------- >=20 >=20 > >>>5. In 5.3.1: > >>>"When a proxy receives a dialog initiation request from=20 > >>>its previous-hop proxy, and the top-most Record-Route=20 > header field of=20 > >>>the request contains a "keep" parameter, if the proxy is=20 > willing to send and > >>>receive keep-alives from the previous-hop proxy for the associated > >>>dialog, the proxy MUST insert a "keep" parameter in its=20 > >>>Record-Route header field of the associated response(s)=20 > sent towards=20 > >>>the previous-hop proxy. After that the proxy MUST send=20 > keep-alives, and accept > >>>keep-alives sent from the previous-hop proxy, for the=20 > duration of the > >>>dialog." > >>>I have a similar problem with this. If the top-most=20 > >>>Record-Route header field does not represent the previous hop=20 > >>>proxy, there is no transport connection established to allow=20 > >>>you to start sending keep-alives at this time. > >>=20 > >>As I said in the beginning of the reply, "next hop" and=20 > >>"previous hop" are probably confusing terminology - at least=20 > >>without proper explanation. > >[JRE] OK, but this still doesn't address my concern about the=20 > >absence of a transport connection. >=20 > See above. >=20 >=20 > -------- >=20 >=20 > >>>6. "When a proxy forwards a dialog initiation request towards=20 > >>>its next- hop proxy, and it wants to negotiate the usage of=20 > >>>keep-alives with > >>>that next-hop proxy, it MUST include a "keep" parameter in its > >>>Record-Record header field of the request." > >>>How does the proxy know that the next hop is a proxy, as=20 > >>>opposed to a UA?=20 > >>=20 > >>I guess that would be a edge-to-UA case. But, I guess that=20 > >>could be clarified. > >[JRE] As a proxy, how do I know I am the "edge", i.e., how do=20 > >I know the next entity is a UA? Even in the IMS P-CSCF case,=20 > >I don't know - there could be a PBX behind it. >=20 > When the proxy get the response, if there are no=20 > Record-Routes between the proxy and the UA, the proxy is=20 > adjacent to the UA. [JRE] This still doesn't make sense. The text talks about "When a proxy for= wards a dialog initiation request" - at the time of forwarding you just don= 't know what the next entity is - not until the response arrives. John >=20 >=20 > --------- >=20 > >>>Assuming it does know that the next hop is a proxy, how does=20 > >>>it know that the next hop proxy will record-route? > >>=20 > >>See previous comments on "next hop" and "previous hop" terminology. > >[JRE] The words "When a proxy forwards a dialog initiation=20 > >request towards its next-hop proxy" do not make sense - a=20 > >proxy simply forwards a request to the next hop entity. Until=20 > >it receives a response, it has no idea whether the entity it=20 > >forwarded the request to is a UA, a non-record-routing proxy=20 > >or a record-routing proxy, i.e., it has no idea whether it=20 > >has sent it to something that complies with your definition=20 > >of "next-hop proxy". >=20 > I agree. So, the text could probably be more generic, and the=20 > actions then depend on what comes in the answer (Record-Route=20 > or Contact). >=20 >=20 > Regards, >=20 > Christer > = From pkyzivat@cisco.com Thu Apr 15 06:42:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31D23A6782 for ; Thu, 15 Apr 2010 06:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZtWT6Pk8P60 for ; Thu, 15 Apr 2010 06:42:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 43A7A3A6A0C for ; Thu, 15 Apr 2010 06:42:05 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANOzxktAZnwM/2dsb2JhbACbbnGkOJojhQ4E X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="101906659" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2010 13:41:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3FDfw6C025557; Thu, 15 Apr 2010 13:41:58 GMT Message-ID: <4BC7179F.9020604@cisco.com> Date: Thu, 15 Apr 2010 09:41:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> In-Reply-To: <01a401cadc64$6ab7a120$4026e360$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 13:42:06 -0000 Paul E. Jones wrote: > Paul, Brett, > > I looked at the OPTIONS ping draft and 3261 again. Perhaps I'm missing it > and need to be reminded (and I note it's 2AM here), but what in the OPTIONS > draft changes anything stated in 3261. The statement of concern is this, > right? > > To avoid unduly taxing a receiving SIP entity, transmitters of > OPTIONS messages MUST honor the Retry-After header field if > received. > > When a 503 is used is in line with 3261: we're not suggesting new > opportunities to send one. We're just saying that code should be used vs. > other codes that don't have the same meaning. > And, Retry-After should be honored. We say MUST, which I understand is a > stronger word than SHOULD (and why I'm willing to soften it). Changing it > to SHOULD would be in stronger agreement with 21.5.4 of 3261. > > A device would not send 503 with Retry-After lightly, nor are we proposing a > change as to when a 503 is sent. So, is using "SHOULD" acceptable? Or is > this really a problem? I understand the problems one can get into with the > current wording in 3261, but what I'm failing to see, I guess, is how the > OPTIONS ping draft makes this worse. Let me see if I fully understand your intent here. If you said nothing about this, and the result of an OPTIONS ping was a 503 with a Retry-After, then the recipient would be bound by 3261, which says: A client ... receiving a 503 ... SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. Is the intent of the MUST in your draft to strengthen that SHOULD NOT in 3261 to MUST NOT for those devices that claim conformance to your draft? If that is the case, then I think it is ok as long as this draft itself becomes normative, or a BCP. (I have to check the rules for BCPs - I'm not certain if they can have normative statements of their own.) I'm pretty sure this would be inappropriate in an informative draft, though some non-normative language with the same intent should be ok. Thanks, Paul > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, April 12, 2010 8:25 PM >> To: Brett Tate >> Cc: Hadriel Kaplan; Paul E. Jones; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >> >> >> >> Brett Tate wrote: >>>>> I don't think that lets you off the hook. >>>>> We've learned from experience that we were too vague in >>>>> the past. So I would expect you to be less vague here - >>>>> being more explicit about what conditions justify violating >>>>> the SHOULD. >>>> And really using "MUST..., unless..." instead. >>> Is making 503 with Retry-After usable (i.e. so it does more good than >> harm) something that should be done within this draft and in this >> working group? Or is that something that should be addressed within >> the hopefully dispatched overload working group? >> >> >> Well, now you ask the hard questions. >> >> With my chair hat on, IMO any changes to the behavior of 503 will at >> least need to be blessed by sipcore. (But I'm new as a sipcore chair, >> so >> I'm willing to learn from the other chair or the AD that is isn't so.) >> >> After that, I think it depends on what is to happen with this draft. >> >> If it is intended to be informational, then it can't make any normative >> changes. It can make any recommendations it wants as long as they don't >> require violating normative behavior. >> >> If its aspirations are higher, and maybe even if they aren't, then I >> think it makes sense to coordinate it with the work of the overload wg. >> (AFAIK we don't yet *have* an overload WG, but there is a mailing list, >> and I gather its expected that we will have the WG before long.) >> >> With my individual hat on I will recommend that it go there for some >> discussion of if/how it relates. >> >> Thanks, >> Paul >> > > > From pkyzivat@cisco.com Thu Apr 15 06:47:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F353A6829 for ; Thu, 15 Apr 2010 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycogqmCW5WcN for ; Thu, 15 Apr 2010 06:47:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DEFE43A67A2 for ; Thu, 15 Apr 2010 06:47:26 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP+0xktAZnwN/2dsb2JhbACbbnGkO5ojhQ4E X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="101908569" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2010 13:47:20 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3FDlJvq025685; Thu, 15 Apr 2010 13:47:19 GMT Message-ID: <4BC718E0.2020706@cisco.com> Date: Thu, 15 Apr 2010 09:47:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <747A6506A991724FB09B129B79D5FEB61480BBFA9E@EXMBXCLUS01.citservers.local> <002601cad3a0$06b20ac0$14162040$@com> <747A6506A991724FB09B129B79D5FEB61480BBFAD1@EXMBXCLUS01.citservers.local> <002c01cad90b$0a9c17f0$1fd447d0$@com> <4BC64190.9050002@digium.com> <01ac01cadc65$7f1b1790$7d5146b0$@com> In-Reply-To: <01ac01cadc65$7f1b1790$7d5146b0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, "'Kevin P. Fleming'" Subject: Re: [sipcore] draft-jones-sip-options-ping-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 13:47:28 -0000 Paul E. Jones wrote: >>> This is a problem general for SIP, since there is no way for a SIP >> entity to >>> know that a DNS query that returns 4 replies relates to the same or >>> different servers. I can't fix that problem in this draft :-) >> No, but in the 'normal' case, an INVITE is not directed to a RURI that >> contains an IP address and port number, it's directed to a RURI with a >> logical name for the 'service', and in that case, it's very logical for >> Retry-After returned in the 503 to apply to the entire 'service'. > > Messages are still transmitted to a certain server. RFC 3261 provides > guidance as to when an entity should stop transmitting messages to a given > server. The OPTIONS ping draft does not change that logic. The 3261 language could be clearer on this subject. In reality, messages are transmitted toward an address (typically an IP address), and arrive (if at all) at some server listening on that address. As you pointed out already, when the sender has a list of alternate addresses that it could have sent the request to, it has no way of knowing which ones are served by the same server. So, in general I think the best the client can do is refrain from sending to the same *address*. But maybe somebody else has better insight on this. Thanks, Paul From christer.holmberg@ericsson.com Thu Apr 15 09:03:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E023A693F for ; Thu, 15 Apr 2010 09:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3oWCRWXpw9N for ; Thu, 15 Apr 2010 09:03:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 479963A6851 for ; Thu, 15 Apr 2010 09:03:11 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-04-4bc738b72fe6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 96.CF.23740.7B837CB4; Thu, 15 Apr 2010 18:03:03 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 15 Apr 2010 18:03:02 +0200 From: Christer Holmberg To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 18:03:01 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQAAVazAAABYgt+g== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 16:03:13 -0000 Hi, >>>Why is this draft-ietf? I don't recall adopting anything of this nature = as a WG item. >>> >>>The draft has been adopted a long time ago. It has just been on hold >>>for a while, partly because of the INFO work. >>[JRE] I know, but this draft looks very different from the one adopted as= WG item, > > Please compare the first and last version of the Info-events draft :) > > Seriously, I agree there were editorial changes, but the only > technical change was to not use the "=3Dyes" parameter. And, > some of the editorial changes are also based on that change. >[JRE] This is not true. -00 and -01 both used Via, now we use Path, Record= -Route and Contact.=20 True. What I meant was that we in Stockholm agreed to use P/RR/C instead of= Via, with the "=3Dyes" parameter value, but it was never documented in a d= raft. In addition, at one point I indicated that there are problems with "= =3Dyes", and that something else is needed. That else is now presented in -= 02. ---------- >That is a completely different solution. I agree that -02 might be moving = in the right direction. Good. >>>>Before answering to your specific comments, I want to clarify one thing= : >>>> >>>>When I talk about "next hop" and "previous hop", I refer to >>>>the adjacent node in the established registration/dialog path >>>>- not a hop which will not be part of that path. That needs >>>>to be clarfied. >>>> >>>>And, this is the reason, based on a comment from yourself, >>>>that we decided to NOT define the "keep" parameter for the >>>>Via header field, since not all entities that insert Via will >>>>be part of the path. >>>[JRE] Yes, I understand the problems with the old Via-based >>>proposal, but on reading the present draft it didn't seem to >>>help much. >> >>Keep in mind that in Stockholm we decided to use Contact/Path/Record-Rout= e instead of Via, so that is an existing agreement. >[JRE] Well, I could not find any mailing list endorsement of this followin= g Stockholm, and that is nearly one year ago, so my memory failed me.=20 >The minutes just state: "Option 2 from slides: "Nodes which are adjacent i= n a route set/registration path"", and don't say anything about the header= =20 >fields. Unfortunately the link to the slides is broken. I can look for them, if you want. ---------- >Anyway, we should focus on fixing the present draft. Yes. ---------- >>>>>What I do have a problem with is the UA-to-UA case (in >>>>>particular, B2BUA-to-B2BUA), where, if this mechanism is to >>>>>be used, clearly one of the UAs has to >>>>>receive keep-alives. >>>> >>>>The initial scope of the draft was to use the Outbound >>>>topology, and assume there is an edge proxy. After that >>>>people asked to also cover the proxy-to-proxy case. >>>> >>>>However, if we want to cover the direct UA-to-UA case I guess >>>>we could say that the UAs check for a Record-Route with >>>>"keep", and if there is none then check for a Contact with "keep". >>>[JRE] Many people use B2BUAs rather than proxies, and I would >>>expect the draft to be equally applicable between B2BUAs. >>>Also I would have expected the draft to be applicable between >>>a proxy/B2BUA and a non-registering UA, or between a >>>proxy/B2BUA and a directly registering UA (without an edge >>>proxy). In other words, filling all the gaps that aren't >>>covered by sip-outbound. >> >>Since a B2BUA acts as a UA, I don't we need to separate them. >>If we solve UA-to-UA we also solve UA-to-B2BUA. >[JRE] Fine, but the present draft doesn't seem to work for UA-to-UA. I agree, and the reason for that is I assumed it was not within the scope o= f the solution. But, as I said earlier, there should be no problem to make it work for UA-t= o-UA. Currently an UA only checks if the adjacent node supports keep-alive = by looking at Record-Route, but we can add text saying that, if there is no= Record-Route, the UA checks whether the Contact contains "keep". However, the use-cases described in the beginning of the draft are the ones= I used to justfiy the work, and UA-to-UA is not covered in any of those. S= o, I just want to be sure people are ok with adding it. ---------- >>>>>2. Also section 4.1 starts off by saying that this is all >>>>>about keep-alive between a UA and its edge proxy, which tends >>>>>to rule out the cases above, and also cases where a >>>>>registering UA registers directly with its registrar, not via >>>>>an edge proxy. Also it seems to rule out cases where the >>>>>proxy does not record-route, so that for dialog keep-alive >>>>>the UA would need to send keep-alives to some other entity. >>>> >>>>See my comment about the scope of the draft above. >>>> >>>>However, as for the UA-to-UA case, I don't have a problem if >>>>we want to also cover the direct UA-to-Registrar case. I >>>>guess the question then is how the registrar will indicate >>>>its support of keep-alives, since it normally doesn't insert >>>>a Path header field. >>>[JRE] Well, the previous proposal used the Via header field, >>>so in moving away from Via we seem to have lost a capability. >>>Perhaps a UA wanting to use this mechanism must insert a Path >>>header field - I haven't thought through the consequences, however. >> >>The UA inserts Contact so that is not a problem. The question >>is how the registrar would indicate support. >[JRE] If the registrar receives Path in the request, it could send Path in= the response. Yes. It would insert a Path pointing to itself, and add a "keep" parameter. ---------- >>>>3. In 4.2.2: >>>>"When the UAC receives the response(s) to the initial >>>>request for the dialog, if the top-most Record-Route >>>>header field (edge proxy) of >>>>response(s) contains a "keep" parameter, the UAC MUST start to send >>>>keep-alives towards the edge proxy for the remaining >>>>duration of the dialog." >>>>This doesn't make sense. The response containing the "keep" >>>>parameter will be received on the path of the request, but >>>>depending which entities have record-routed, the dialog path >>>>may be different. A transport connection to the first entity >>>>on the dialog path is not established until the next outbound >>>>or inbound request on that dialog, so "MUST start to send >>>>keep-alives towards the edge proxy" is unachievable in such cases. >>> >>>The UAC will send the keep-alives towards the address >>>indicated in the Record-Route - NOT to where it sent the >>>INVITE request. >>[JRE] How can it sent keep-alives when it hasn't established >>a transport connection yet? It must wait for the transport >>connection to be established, which means waiting for an >>inbound or outbound mid-dialog request. If it's an inbound >>request, however, which entity should be responsible for keep-alives? > >What prevents the UAC from establishing the transport >connection without waiting for any mid-dialog request to be sent? >[JRE] Well, nothing I guess, except that isn't SIP. What would the next ho= p do if it receives a TCP connection without any SIP message for a while, o= r receives an empty UDP packet? The UA establishes the connection when the first keep-alive is sent, and si= nce the next hop has indicated support of keep-alive it needs to be ready t= o handle it. I guess we could add a Note indicating that. ---------- >>And, unless the UAC establishes the connnection, it won't >>even be able to receive inbound requests in case there is a NAT. >[JRE] True, and in such cases I would expect the first proxy to record-rou= te, so no issue. The point is, there are situations that the present draft = doesn't deal with.=20 >I am happy to be convinced that you don't need keep-alive in cases that ar= en't covered by the draft, but we haven't had that discussion. I am NOT trying to convince you about that :) =20 I wrote the draft based on the use-cases we had agreed upon (at least accor= ding to my understanding), but I would be happy to cover additional use-cas= es, if people are ok with it. ---------- >>>>6. "When a proxy forwards a dialog initiation request towards >>>>its next- hop proxy, and it wants to negotiate the usage of >>>>keep-alives with >>>>that next-hop proxy, it MUST include a "keep" parameter in its >>>>Record-Record header field of the request." >>>>How does the proxy know that the next hop is a proxy, as >>>>opposed to a UA? >>> >>>I guess that would be a edge-to-UA case. But, I guess that >>>could be clarified. >>[JRE] As a proxy, how do I know I am the "edge", i.e., how do >>I know the next entity is a UA? Even in the IMS P-CSCF case, >>I don't know - there could be a PBX behind it. > >When the proxy get the response, if there are no >Record-Routes between the proxy and the UA, the proxy is >adjacent to the UA. >[JRE] This still doesn't make sense. The text talks about "When a proxy fo= rwards a dialog initiation request" - at the time of forwarding you just do= n't know what the next entity is - not until the response arrives. That is what I tried to say :)=20 The text about the request being forward would NOT make assumption about wh= at type of node the next hope is - it would be detected when the response a= rrives. Regards, Christer= From christer.holmberg@ericsson.com Thu Apr 15 09:04:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA3628C154 for ; Thu, 15 Apr 2010 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUXfVicvhjUr for ; Thu, 15 Apr 2010 09:04:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 93C983A692E for ; Thu, 15 Apr 2010 09:04:41 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-b3-4bc73911a0a3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B2.EF.23740.11937CB4; Thu, 15 Apr 2010 18:04:33 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 15 Apr 2010 18:04:33 +0200 From: Christer Holmberg To: Paul Kyzivat , "Paul E. Jones" Date: Thu, 15 Apr 2010 18:03:49 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrcmwn1ahq6Ji/uTSecLF1g3QFi5gAGjKeS Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <018a01cadc5c$167a5ba0$436f12e0$@com>,<4BC70BD6.4060601@cisco.com> In-Reply-To: <4BC70BD6.4060601@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: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 16:04:43 -0000 Hi, >I'm ok with the SHOULD since that is what is in 3261. What I would >prefer to see is some enumeration of the cases when its appropriate to >violate the SHOULD. If it is a reference to 3261 it would be good to say: "As specified in RFC 3261, blah blah blah..." Regards, Christer Paul E. Jones wrote: >> I think that's OK here, since what Brett was suggesting was that it >> is >>> already a SHOULD in effect in 3261. In any case, the worst thing >> that >>> happens here is that a device ignores the Retry-After header and >> claims >>> compliance. Apparently, some feel there are plenty of good reasons >> to do >>> so. >> I don't think that lets you off the hook. >> We've learned from experience that we were too vague in the past. >> So I would expect you to be less vague here - being more explicit about >> what conditions justify violating the SHOULD. > > Shall I put it back to MUST? Keep in mind, we're not trying to re-define > RFC 3261. > > Paul > > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From john.elwell@siemens-enterprise.com Thu Apr 15 09:53:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C81F28C1EC for ; Thu, 15 Apr 2010 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FfLxZmvcSCv for ; Thu, 15 Apr 2010 09:53:45 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 72E6B28C1E5 for ; Thu, 15 Apr 2010 09:53:45 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1568622; Thu, 15 Apr 2010 18:53:38 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 30BDC23F0278; Thu, 15 Apr 2010 18:53:38 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 15 Apr 2010 18:53:38 +0200 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 18:53:36 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQAAVazAAABYgt+gACafvQ 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: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 16:53:46 -0000 Christer, The use cases in 1.1 to 1.4 seem to cover most of what I mentioned in my co= mments. For example, they make no assumption about the presence of an edge = proxy between a UA and its registrar/proxy, and they make no assumption abo= ut which entities, if any, between two UAs, perform record-route. Therefore= I would expect such situations to be covered by the solution. What is missing from the use cases is the B2BUA case, I guess. I think if w= e include the proxy-to-proxy case (1.4), we should also include the B2BUA-B= 2BUA case, since B2BUAs are commonly used instead of proxies. (Rest of thread stripped). John From christer.holmberg@ericsson.com Thu Apr 15 10:07:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68B03A6B09 for ; Thu, 15 Apr 2010 10:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkZek1OoR7sg for ; Thu, 15 Apr 2010 10:07:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9B5423A697D for ; Thu, 15 Apr 2010 10:07:47 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-c1-4bc747db95ef Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 05.D3.23740.BD747CB4; Thu, 15 Apr 2010 19:07:39 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 15 Apr 2010 19:07:38 +0200 From: Christer Holmberg To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 19:04:42 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQAAVazAAABYgt+gACafvQAACTFr4= Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 17:07:48 -0000 Hi, >The use cases in 1.1 to 1.4 seem to cover most of what I mentioned in my c= omments. For example, they=20 >make no assumption about the presence of an edge proxy between a UA and it= s registrar/proxy, and they=20 >make no assumption about which entities, if any, between two UAs, perform = record-route. Well, there is text talking about the fact why Outbound can't be used in th= ose cases, so the assumption is that the Outbound topology is used. But, we don't need to argue about it. I am ok to make it more general :) >What is missing from the use cases is the B2BUA case, I guess. I think if = we include the proxy-to-proxy case=20 >(1.4), we should also include the B2BUA-B2BUA case, since B2BUAs are commo= nly used instead of=20 >proxies. Won't UA-UA case also cover B2BUA-B2BUA? Regards, Christer= From john.elwell@siemens-enterprise.com Thu Apr 15 12:37:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47ED3A694A for ; Thu, 15 Apr 2010 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RKb5uomV4zd for ; Thu, 15 Apr 2010 12:37:21 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BE2833A690B for ; Thu, 15 Apr 2010 12:37:19 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1569803; Thu, 15 Apr 2010 21:37:12 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 3E70523F0278; Thu, 15 Apr 2010 21:37:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 15 Apr 2010 21:37:12 +0200 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 21:37:10 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQAAVazAAABYgt+gACafvQAACTFr4ABTzx0A== 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: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 19:37:21 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 15 April 2010 18:05 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Draft new version: draft-ietf-sipcore-keep-02 >=20 > Hi, >=20 > >The use cases in 1.1 to 1.4 seem to cover most of what I=20 > mentioned in my comments. For example, they=20 > >make no assumption about the presence of an edge proxy=20 > between a UA and its registrar/proxy, and they=20 > >make no assumption about which entities, if any, between two=20 > UAs, perform record-route. >=20 > Well, there is text talking about the fact why Outbound can't=20 > be used in those cases, so the assumption is that the=20 > Outbound topology is used. [JRE] Outbound does not mandate an edge proxy. >=20 > But, we don't need to argue about it. I am ok to make it more=20 > general :) >=20 > >What is missing from the use cases is the B2BUA case, I=20 > guess. I think if we include the proxy-to-proxy case=20 > >(1.4), we should also include the B2BUA-B2BUA case, since=20 > B2BUAs are commonly used instead of=20 > >proxies. >=20 > Won't UA-UA case also cover B2BUA-B2BUA? [JRE] But where is the UA-UA case in 1.1 to 1.4? If it's there, it's not ob= vious. John From christer.holmberg@ericsson.com Thu Apr 15 13:34:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8D923A6999 for ; Thu, 15 Apr 2010 13:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyNO3-70cFso for ; Thu, 15 Apr 2010 13:34:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E1F553A6A34 for ; Thu, 15 Apr 2010 13:33:54 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-a1-4bc7782a6c20 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 92.1D.23740.A2877CB4; Thu, 15 Apr 2010 22:33:47 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 15 Apr 2010 22:33:46 +0200 From: Christer Holmberg To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 22:30:07 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AABAvqQAAVazAAABYgt+gACafvQAACTFr4ABTzx0AAB75Ga Message-ID: References: , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 20:34:48 -0000 Hi, >>>The use cases in 1.1 to 1.4 seem to cover most of what I >>>mentioned in my comments. For example, they >>>make no assumption about the presence of an edge proxy >>>between a UA and its registrar/proxy, and they >>>make no assumption about which entities, if any, between two >>>UAs, perform record-route. >> >>Well, there is text talking about the fact why Outbound can't >>be used in those cases, so the assumption is that the >>Outbound topology is used. >[JRE] Outbound does not mandate an edge proxy. > >But, we don't need to argue about it. I am ok to make it more >general :) > >>What is missing from the use cases is the B2BUA case, I >>guess. I think if we include the proxy-to-proxy case >>(1.4), we should also include the B2BUA-B2BUA case, since >>B2BUAs are commonly used instead of >>proxies. > >Won't UA-UA case also cover B2BUA-B2BUA? >[JRE] But where is the UA-UA case in 1.1 to 1.4? If it's there, it's not o= bvious. It's not there. My point was that if we add the UA-UA case, we'll also cove= r the B2BUA-B2BUA case. Regards, Christer= From dean.willis@softarmor.com Thu Apr 15 16:42:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3F43A6AAA for ; Thu, 15 Apr 2010 16:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJUHNlLbmU88 for ; Thu, 15 Apr 2010 16:42:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DF42E3A6AB2 for ; Thu, 15 Apr 2010 16:42:39 -0700 (PDT) Received: from [10.2.4.79] (mobile-032-160-052-101.mycingular.net [32.160.52.101] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3FNgFfp012964 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 18:42:20 -0500 Date: Thu, 15 Apr 2010 19:42:06 -0400 From: "Dean Willis" To: "Paul Kyzivat" MIME-Version: 1.0 X-Mailer: LCG ProfiMail Message-ID: <9961835115.955827726@softarmor.com> In-Reply-To: <4BC7179F.9020604@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Cc: paulej@packetizer.com, sipcore@ietf.org, Hadriel Kaplan Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 23:42:42 -0000 ------- Original message ------- > From: Paul Kyzivat > > Is the intent of the MUST in your draft to strengthen that SHOULD NOT in > 3261 to MUST NOT for those devices that claim conformance to your draft? > > If that is the case, then I think it is ok as long as this draft itself > becomes normative, or a BCP. (I have to check the rules for BCPs - I'm not > certain if they can have normative statements of their own.) I'm pretty > sure this would be inappropriate in an informative draft, though some > non-normative language with the same intent should be ok. BCP can use 2119 language, but is for documenting practices for which we have in-the-field experience, so it doesn't really apply here. An informative or experimental draft can use such language, but has to lay out the conditions of "what happens if" and explain "why" in a very high level of detail. Remember: 2119 is about requirements, and naked requirements are weaker than naked emperors. They need to be well-dressed in explanation to be respected. That said, if there is adequate justification to change the language of RFC 3261, then we should probably just change it, and that means a standards-track draft. -- Dean From paulej@packetizer.com Thu Apr 15 17:34:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6D53A690C for ; Thu, 15 Apr 2010 17:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ydD8OZIxJmO for ; Thu, 15 Apr 2010 17:34:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id C80873A6AB3 for ; Thu, 15 Apr 2010 17:34:46 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3G0YUpx014441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2010 20:34:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271378076; bh=6lozdXHdSvvaH306CCsI+ibSVkmlzjmDXIQ+4F1m3Bg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=O6r4qJq2G4B/xM3LwR5/Bu1TRvVK3x+BX8fLuC0y5/5nnoZPug1mqdLpLO5onkAD/ zexCLGEYauyRaqCtRN4rm/GdqmuTEAtXa9yaFcNfZFpNJ5oAS+7RiSb0iHZC3/PpXG vwFJkBEcthcgAtBhtgaj4GugEV8rbRxmKron+GaA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3G0YUkD015579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Apr 2010 20:34:30 -0400 From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <018a01cadc5c$167a5ba0$436f12e0$@com>, <4BC70BD6.4060601@cisco.com> In-Reply-To: Date: Thu, 15 Apr 2010 20:34:22 -0400 Message-ID: <00cd01cadcfc$8f1f8f80$ad5eae80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acrcmwn1ahq6Ji/uTSecLF1g3QFi5gAGjKeSABHKrjA= Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 00:34:48 -0000 Capturing everyone's comments, I changed the paragraph as follows: If a requesting entity fails to receive a response to an OPTIONS message, it MAY retransmit that message following the procedures defined in RFC 3261. If a requesting entity receives a 486 or 503 response code, it MAY send a subsequent OPTIONS messages in order to detect a change in operational status, but it SHOULD, as per RFC 3261, honor the Retry-After header field received in the previous response. Pail > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, April 15, 2010 12:04 PM > To: Paul Kyzivat; Paul E. Jones > Cc: sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > Hi, > > >I'm ok with the SHOULD since that is what is in 3261. What I would > >prefer to see is some enumeration of the cases when its appropriate to > >violate the SHOULD. > > If it is a reference to 3261 it would be good to say: > > "As specified in RFC 3261, blah blah blah..." > > Regards, > > Christer > > > > > Paul E. Jones wrote: > >> I think that's OK here, since what Brett was suggesting was that it > >> is > >>> already a SHOULD in effect in 3261. In any case, the worst thing > >> that > >>> happens here is that a device ignores the Retry-After header and > >> claims > >>> compliance. Apparently, some feel there are plenty of good reasons > >> to do > >>> so. > >> I don't think that lets you off the hook. > >> We've learned from experience that we were too vague in the past. > >> So I would expect you to be less vague here - being more explicit > about > >> what conditions justify violating the SHOULD. > > > > Shall I put it back to MUST? Keep in mind, we're not trying to re- > define > > RFC 3261. > > > > Paul > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Thu Apr 15 20:40:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257453A6B0D for ; Thu, 15 Apr 2010 20:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ2+ymZ-mRMU for ; Thu, 15 Apr 2010 20:40:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 53A4A3A6AEA for ; Thu, 15 Apr 2010 20:40:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 15 Apr 2010 23:39:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 15 Apr 2010 23:39:47 -0400 From: Hadriel Kaplan To: "Elwell, John" , Christer Holmberg , "sipcore@ietf.org" Date: Thu, 15 Apr 2010 23:39:19 -0400 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvA Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 03:40:13 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Elwell, John > Sent: Thursday, April 15, 2010 6:26 AM > > [JRE] Yes, I understand the problems with the old Via-based proposal, but > on reading the present draft it didn't seem to help much. Can someone explain the problems with the Via approach again? I'm sorry, I= must just be thick. It seemed like such a clean/simple approach. -hadriel From christer.holmberg@ericsson.com Thu Apr 15 22:37:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55CCC3A6A02 for ; Thu, 15 Apr 2010 22:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmY-QhsKPFED for ; Thu, 15 Apr 2010 22:37:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3A77E3A69D9 for ; Thu, 15 Apr 2010 22:37:50 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-e5-4bc7f7a6340c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A1.D6.23740.6A7F7CB4; Fri, 16 Apr 2010 07:37:42 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 16 Apr 2010 07:37:42 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 07:37:41 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 05:37:52 -0000 Hi,=20 >>[JRE] Yes, I understand the problems with the old Via-based=20 >>proposal,=20 >>but on reading the present draft it didn't seem to help much. >=20 >Can someone explain the problems with the Via approach again?=20 >I'm sorry, I must just be thick. It seemed like such a=20 >clean/simple approach. The main problem is that all entities, including those that will not be pat= h of the registration/dialog path, insert Via, so when an entity receives a= request it does not know which Via header represents the entity that will = be its "neighbour" in the path, and can't therefor check whether that neigh= bour supports keep-alives or not. Example: P1 P2 P3 = P4 --- INVITE -------------> Via: P1;keep Record-Route: P1 --- INVITE -------------> Via: P1;keep Via: P2 Record-Route: P1 --- INVITE ------------->= =20 Via: P1;keep Via: P2 Via: P3 Record-Route: P1 Now, when P4 receives the INVITE, how does it know that P1 will be its dial= og path neighbour (since P2 and P3 do not record-route)? We cannot assume t= hat P4 would be able to figure that out by starting to compare the Vias wit= h the Record-Routes etc... Regards, Christer From HKaplan@acmepacket.com Thu Apr 15 23:24:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C513A63D3 for ; Thu, 15 Apr 2010 23:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJYYGCjmc7vt for ; Thu, 15 Apr 2010 23:24:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 271AA3A6B6F for ; Thu, 15 Apr 2010 23:23:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Apr 2010 02:23:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Apr 2010 02:23:27 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 02:23:25 -0400 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-02 Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAPBE0A== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCEF04@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 06:24:14 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, April 16, 2010 1:38 AM >=20 > The main problem is that all entities, including those that will not be > path of the registration/dialog path, insert Via, so when an entity > receives a request it does not know which Via header represents the entit= y > that will be its "neighbour" in the path, and can't therefor check whethe= r > that neighbour supports keep-alives or not. So?? What does it matter? P4 received a request with a top-most Via that = does not have the keep param, and it thereby knows the previous hop of that= Via's address:port (P3) does not do keep-alive. Likewise, P1 will get bac= k a response with the top-most Via (its own) without the keep param's value= being "yes", and knows that next-hop address:port (P2) cannot do keepalive= . =20 That's all that's important at that point. =20 At some later time P1 will send an ACK, and P4 will get it and see the top-= most Via (now P1) has the keep param, and know that previous hop addr:port = of P1 can do keep-alive. P1 won't get a response for the ACK of course (un= less there's a PRACK) so it won't learn about P4's ability, but P4 can send= a stun/crlf keep-alive if it wants to. And if P1 really cares it can send= an Update or re-Invite and find out for itself. That may sound annoying to have to send a re-invite/update, but it's not th= e common use-case for this thing anyway, right? The common use-case would be for a UA registering to its proxy/registrar, w= here the Via's will be fine. And the other use-case might be between proxi= es/b2bua's, where the Via's will be fine too. I mean basically this whole thing is an optimization at the end of the day = to avoid doing OPTIONS or REGISTER refreshes, for specific common use-cases= , so why make it complicated for the common use-cases just to be less annoy= ing for the not-common use-cases? -hadriel From john.elwell@siemens-enterprise.com Thu Apr 15 23:28:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C053A6A02 for ; Thu, 15 Apr 2010 23:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFmiHOOS5Skm for ; Thu, 15 Apr 2010 23:28:22 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 954FF3A6B24 for ; Thu, 15 Apr 2010 23:28:22 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1571589; Fri, 16 Apr 2010 08:28:15 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 211EA23F028E; Fri, 16 Apr 2010 08:28:15 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 16 Apr 2010 08:28:15 +0200 From: "Elwell, John" To: Christer Holmberg , Hadriel Kaplan , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 08:28:13 +0200 Thread-Topic: Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0A== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 06:28:23 -0000 One of the consequences of the changes in the current version of keep is as= follows. Taking the example in the diagram Christer drew below, we have P1= and P4 on the dialog path, but not P3 and P4. The dialog-forming INVITE tr= ansaction follows the path through P1, P2, P3 and P4, so none of the transp= ort connections used for that transaction need to be kept. The only transpo= rt connection that needs to be kept is the one from P1 to P4. However, this= does not exist yet. So what the draft seems to imply is that, when a trans= port connection directly between P1 and P4 is established, it needs to be k= ept alive. In an earlier mail, Christer suggested we establish it straight away, just = to send the keep-alive, and then, when the first mid-dialog transaction tak= es place, the connection will be there ready and waiting. This seems wastef= ul to me. In particular, for some calls the only mid-dialog transaction mig= ht be the BYE, so establishing a transport connection early and keeping it = alive, just to send the BYE, seems particularly pointless. Of course, other= INVITE-initiated dialogs might have more traffic, e.g., UPDATE, INFO, re-I= NVITE, REFER, PRACK. The alternative would be to wait for the first mid-dialog request, and then= establish the connection in the normal manner and keep it alive (assuming = the transaction is not a BYE). But then, we could equally well use Via in the first mid-dialog transaction= to signal keep-alive, and in fact that would probably be simpler. We seem to have confusion between the dialog-forming transaction and the tr= ansaction that establishes connections for the dialog path (the first mid-d= ialog transaction). Finally, we need to say something about dialog termination - there is no po= int in keeping the path open permanently, except in the context of connecti= on reuse. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 April 2010 06:38 > To: Hadriel Kaplan; Elwell, John; sipcore@ietf.org > Subject: RE: Draft new version: draft-ietf-sipcore-keep-02 >=20 >=20 > Hi,=20 >=20 > >>[JRE] Yes, I understand the problems with the old Via-based=20 > >>proposal,=20 > >>but on reading the present draft it didn't seem to help much. > >=20 > >Can someone explain the problems with the Via approach again?=20 > >I'm sorry, I must just be thick. It seemed like such a=20 > >clean/simple approach. >=20 > The main problem is that all entities, including those that=20 > will not be path of the registration/dialog path, insert Via,=20 > so when an entity receives a request it does not know which=20 > Via header represents the entity that will be its "neighbour"=20 > in the path, and can't therefor check whether that neighbour=20 > supports keep-alives or not. >=20 > Example: >=20 > P1 P2 P3 =20 > P4 >=20 > --- INVITE -------------> > Via: P1;keep > Record-Route: P1 > --- INVITE -------------> > Via: P1;keep > Via: P2 > Record-Route: P1 > --- INVITE --------> = =20 > Via: P1;keep > Via: P2 > Via: P3 > Record-Route: P1 >=20 >=20 >=20 > Now, when P4 receives the INVITE, how does it know that P1=20 > will be its dialog path neighbour (since P2 and P3 do not=20 > record-route)? We cannot assume that P4 would be able to=20 > figure that out by starting to compare the Vias with the=20 > Record-Routes etc... >=20 >=20 > Regards, >=20 > Christer > = From john.elwell@siemens-enterprise.com Thu Apr 15 23:31:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8043A68C4 for ; Thu, 15 Apr 2010 23:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PysY--gY9IO4 for ; Thu, 15 Apr 2010 23:31:48 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F2D1E3A67E5 for ; Thu, 15 Apr 2010 23:31:45 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1573381; Fri, 16 Apr 2010 08:31:38 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 274F923F028E; Fri, 16 Apr 2010 08:31:38 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 16 Apr 2010 08:31:38 +0200 From: "Elwell, John" To: Christer Holmberg , Hadriel Kaplan , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 08:31:36 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 06:31:49 -0000 Sorry, I forgot to mention ACK in the list of mid-dialog requests below. Th= at has specific considerations, as Hadriel has just pointed out on the old = thread. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 16 April 2010 07:28 > To: Christer Holmberg; Hadriel Kaplan; sipcore@ietf.org > Subject: [sipcore] Keeping alive connections on a dialog path=20 > (was RE: Draft new version: draft-ietf-sipcore-keep-02) >=20 > One of the consequences of the changes in the current version=20 > of keep is as follows. Taking the example in the diagram=20 > Christer drew below, we have P1 and P4 on the dialog path,=20 > but not P3 and P4. The dialog-forming INVITE transaction=20 > follows the path through P1, P2, P3 and P4, so none of the=20 > transport connections used for that transaction need to be=20 > kept. The only transport connection that needs to be kept is=20 > the one from P1 to P4. However, this does not exist yet. So=20 > what the draft seems to imply is that, when a transport=20 > connection directly between P1 and P4 is established, it=20 > needs to be kept alive. >=20 > In an earlier mail, Christer suggested we establish it=20 > straight away, just to send the keep-alive, and then, when=20 > the first mid-dialog transaction takes place, the connection=20 > will be there ready and waiting. This seems wasteful to me.=20 > In particular, for some calls the only mid-dialog transaction=20 > might be the BYE, so establishing a transport connection=20 > early and keeping it alive, just to send the BYE, seems=20 > particularly pointless. Of course, other INVITE-initiated=20 > dialogs might have more traffic, e.g., UPDATE, INFO,=20 > re-INVITE, REFER, PRACK. >=20 > The alternative would be to wait for the first mid-dialog=20 > request, and then establish the connection in the normal=20 > manner and keep it alive (assuming the transaction is not a BYE). >=20 > But then, we could equally well use Via in the first=20 > mid-dialog transaction to signal keep-alive, and in fact that=20 > would probably be simpler. >=20 > We seem to have confusion between the dialog-forming=20 > transaction and the transaction that establishes connections=20 > for the dialog path (the first mid-dialog transaction). >=20 > Finally, we need to say something about dialog termination -=20 > there is no point in keeping the path open permanently,=20 > except in the context of connection reuse. >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > > Sent: 16 April 2010 06:38 > > To: Hadriel Kaplan; Elwell, John; sipcore@ietf.org > > Subject: RE: Draft new version: draft-ietf-sipcore-keep-02 > >=20 > >=20 > > Hi,=20 > >=20 > > >>[JRE] Yes, I understand the problems with the old Via-based=20 > > >>proposal,=20 > > >>but on reading the present draft it didn't seem to help much. > > >=20 > > >Can someone explain the problems with the Via approach again?=20 > > >I'm sorry, I must just be thick. It seemed like such a=20 > > >clean/simple approach. > >=20 > > The main problem is that all entities, including those that=20 > > will not be path of the registration/dialog path, insert Via,=20 > > so when an entity receives a request it does not know which=20 > > Via header represents the entity that will be its "neighbour"=20 > > in the path, and can't therefor check whether that neighbour=20 > > supports keep-alives or not. > >=20 > > Example: > >=20 > > P1 P2 P3 =20 > > P4 > >=20 > > --- INVITE -------------> > > Via: P1;keep > > Record-Route: P1 > > --- INVITE -------------> > > Via: P1;keep > > Via: P2 > > Record-Route: P1 > > ---=20 > INVITE --------> =20 > > Via: P1;keep > > Via: P2 > > Via: P3 > > =20 > Record-Route: P1 > >=20 > >=20 > >=20 > > Now, when P4 receives the INVITE, how does it know that P1=20 > > will be its dialog path neighbour (since P2 and P3 do not=20 > > record-route)? We cannot assume that P4 would be able to=20 > > figure that out by starting to compare the Vias with the=20 > > Record-Routes etc... > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Fri Apr 16 00:03:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809F53A6AF2 for ; Fri, 16 Apr 2010 00:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.148 X-Spam-Level: X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=1.451, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh0WFPc7nTEa for ; Fri, 16 Apr 2010 00:03:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 79FE93A6765 for ; Fri, 16 Apr 2010 00:03:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-f4-4bc80b9c853e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5D.47.23532.C9B08CB4; Fri, 16 Apr 2010 09:02:52 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 16 Apr 2010 09:02:52 +0200 From: Christer Holmberg To: "Elwell, John" , Hadriel Kaplan , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 09:02:50 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 07:03:06 -0000 Hi, Just for my understanding, how would Via be simpler, since it requires the = insertion of "=3Dyes" by the adjacent entity in order to work? Regards, Christer =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: 16. huhtikuuta 2010 9:32 > To: Christer Holmberg; Hadriel Kaplan; sipcore@ietf.org > Subject: RE: [sipcore] Keeping alive connections on a dialog=20 > path (was RE: Draft new version: draft-ietf-sipcore-keep-02) >=20 > Sorry, I forgot to mention ACK in the list of mid-dialog=20 > requests below. That has specific considerations, as Hadriel=20 > has just pointed out on the old thread. >=20 > John=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 16 April 2010 07:28 > > To: Christer Holmberg; Hadriel Kaplan; sipcore@ietf.org > > Subject: [sipcore] Keeping alive connections on a dialog=20 > path (was RE:=20 > > Draft new version: draft-ietf-sipcore-keep-02) > >=20 > > One of the consequences of the changes in the current=20 > version of keep=20 > > is as follows. Taking the example in the diagram Christer=20 > drew below,=20 > > we have P1 and P4 on the dialog path, but not P3 and P4. The=20 > > dialog-forming INVITE transaction follows the path through=20 > P1, P2, P3=20 > > and P4, so none of the transport connections used for that=20 > transaction=20 > > need to be kept. The only transport connection that needs=20 > to be kept=20 > > is the one from P1 to P4. However, this does not exist yet. So what=20 > > the draft seems to imply is that, when a transport=20 > connection directly=20 > > between P1 and P4 is established, it needs to be kept alive. > >=20 > > In an earlier mail, Christer suggested we establish it=20 > straight away,=20 > > just to send the keep-alive, and then, when the first mid-dialog=20 > > transaction takes place, the connection will be there ready and=20 > > waiting. This seems wasteful to me. > > In particular, for some calls the only mid-dialog=20 > transaction might be=20 > > the BYE, so establishing a transport connection early and=20 > keeping it=20 > > alive, just to send the BYE, seems particularly pointless.=20 > Of course,=20 > > other INVITE-initiated dialogs might have more traffic,=20 > e.g., UPDATE,=20 > > INFO, re-INVITE, REFER, PRACK. > >=20 > > The alternative would be to wait for the first mid-dialog=20 > request, and=20 > > then establish the connection in the normal manner and keep=20 > it alive=20 > > (assuming the transaction is not a BYE). > >=20 > > But then, we could equally well use Via in the first mid-dialog=20 > > transaction to signal keep-alive, and in fact that would=20 > probably be=20 > > simpler. > >=20 > > We seem to have confusion between the dialog-forming=20 > transaction and=20 > > the transaction that establishes connections for the dialog=20 > path (the=20 > > first mid-dialog transaction). > >=20 > > Finally, we need to say something about dialog termination=20 > - there is=20 > > no point in keeping the path open permanently, except in=20 > the context=20 > > of connection reuse. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: 16 April 2010 06:38 > > > To: Hadriel Kaplan; Elwell, John; sipcore@ietf.org > > > Subject: RE: Draft new version: draft-ietf-sipcore-keep-02 > > >=20 > > >=20 > > > Hi, > > >=20 > > > >>[JRE] Yes, I understand the problems with the old Via-based=20 > > > >>proposal, but on reading the present draft it didn't=20 > seem to help=20 > > > >>much. > > > >=20 > > > >Can someone explain the problems with the Via approach again?=20 > > > >I'm sorry, I must just be thick. It seemed like such a=20 > > > >clean/simple approach. > > >=20 > > > The main problem is that all entities, including those=20 > that will not=20 > > > be path of the registration/dialog path, insert Via, so when an=20 > > > entity receives a request it does not know which Via header=20 > > > represents the entity that will be its "neighbour" > > > in the path, and can't therefor check whether that neighbour=20 > > > supports keep-alives or not. > > >=20 > > > Example: > > >=20 > > > P1 P2 P3 =20 > > > P4 > > >=20 > > > --- INVITE -------------> > > > Via: P1;keep > > > Record-Route: P1 > > > --- INVITE -------------> > > > Via: P1;keep > > > Via: P2 > > > Record-Route: P1 > > > --- > > INVITE --------> =20 > > > Via: P1;keep > > > Via: P2 > > > Via: P3 > > > =20 > > Record-Route: P1 > > >=20 > > >=20 > > >=20 > > > Now, when P4 receives the INVITE, how does it know that=20 > P1 will be=20 > > > its dialog path neighbour (since P2 and P3 do not=20 > record-route)? We=20 > > > cannot assume that P4 would be able to figure that out by=20 > starting=20 > > > to compare the Vias with the Record-Routes etc... > > >=20 > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From HKaplan@acmepacket.com Fri Apr 16 00:15:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C975E3A685E for ; Fri, 16 Apr 2010 00:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rX4H0w8oTR0 for ; Fri, 16 Apr 2010 00:15:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CAFD33A6765 for ; Fri, 16 Apr 2010 00:15:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Apr 2010 03:15:48 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Apr 2010 03:15:48 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 03:15:46 -0400 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 07:15:59 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, April 16, 2010 3:03 AM > To: Elwell, John; Hadriel Kaplan; sipcore@ietf.org >=20 > Hi, >=20 > Just for my understanding, how would Via be simpler, since it requires th= e > insertion of "=3Dyes" by the adjacent entity in order to work? Compared to using several different header types, each used in different ca= ses, and having a bunch of if/else checks and such? How *isn't* it simpler= ?=20 Setting a received top-most Via param isn't hard is it? Like the Via "rece= ived" param. =20 In fact, instead of doing the new Flow-Timer header, just make the "keep" p= aram's value the timer. So instead of setting it to "yes", it sets it to t= he number of seconds. -hadriel From john.elwell@siemens-enterprise.com Fri Apr 16 00:35:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E4F3A6BFB for ; Fri, 16 Apr 2010 00:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joeMtEQu3eNg for ; Fri, 16 Apr 2010 00:35:57 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C58543A6BAA for ; Fri, 16 Apr 2010 00:29:00 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1573351; Fri, 16 Apr 2010 09:28:52 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2F1E923F0278; Fri, 16 Apr 2010 09:28:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 16 Apr 2010 09:28:52 +0200 From: "Elwell, John" To: Hadriel Kaplan , Christer Holmberg , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 09:28:50 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqpQw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 07:35:58 -0000 In addition to Hadriel's point, mid-dialog requests do not necessarily cont= ain Record-Route and Contact, but always contain Via. So if we rely on Reco= rd-Route and Contact, the decision on keeping connections alive for followi= ng the first mid-dialog request would have to be based on retained state fr= om the initial request. Does a record-routing proxy necessarily store Recor= d-route and Contact header fields from the dialog-forming transaction? John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 16 April 2010 08:16 > To: Christer Holmberg; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] Keeping alive connections on a dialog=20 > path (was RE: Draft new version: draft-ietf-sipcore-keep-02) >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, April 16, 2010 3:03 AM > > To: Elwell, John; Hadriel Kaplan; sipcore@ietf.org > >=20 > > Hi, > >=20 > > Just for my understanding, how would Via be simpler, since=20 > it requires the > > insertion of "=3Dyes" by the adjacent entity in order to work? >=20 > Compared to using several different header types, each used=20 > in different cases, and having a bunch of if/else checks and=20 > such? How *isn't* it simpler?=20 >=20 > Setting a received top-most Via param isn't hard is it? Like=20 > the Via "received" param. =20 >=20 > In fact, instead of doing the new Flow-Timer header, just=20 > make the "keep" param's value the timer. So instead of=20 > setting it to "yes", it sets it to the number of seconds. >=20 > -hadriel > = From christer.holmberg@ericsson.com Fri Apr 16 00:37:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4923A6BE3 for ; Fri, 16 Apr 2010 00:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcwHMNKMAc99 for ; Fri, 16 Apr 2010 00:37:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 59A003A6BE1 for ; Fri, 16 Apr 2010 00:33:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-c0-4bc812aa4565 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 46.CA.23532.AA218CB4; Fri, 16 Apr 2010 09:32:58 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 16 Apr 2010 09:32:57 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 09:32:57 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQ Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 07:37:45 -0000 Hi, So, let's look at an example, to make sure I understand you. An route set has been established, and ACK is sent: UAC ----------- P1 ----------- UAS ---ACK ---------> ---Via: UAC;keep ---ACK ---------> ---Via:P1;keep ---Via:UAC;keep=3Dyes Since there is no reply to ACK, how does the UAS tell P1 that it supports k= eep-alives? To make it work, wouldn't we need to require UPDATE or PRACK, so that UAS c= an send back a response with "Via:P1;keep=3Dyes"? Regards, Christer > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 16. huhtikuuta 2010 10:16 > To: Christer Holmberg; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] Keeping alive connections on a dialog=20 > path (was RE: Draft new version: draft-ietf-sipcore-keep-02) >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, April 16, 2010 3:03 AM > > To: Elwell, John; Hadriel Kaplan; sipcore@ietf.org > >=20 > > Hi, > >=20 > > Just for my understanding, how would Via be simpler, since=20 > it requires=20 > > the insertion of "=3Dyes" by the adjacent entity in order to work? >=20 > Compared to using several different header types, each used=20 > in different cases, and having a bunch of if/else checks and=20 > such? How *isn't* it simpler?=20 >=20 > Setting a received top-most Via param isn't hard is it? Like=20 > the Via "received" param. =20 >=20 > In fact, instead of doing the new Flow-Timer header, just=20 > make the "keep" param's value the timer. So instead of=20 > setting it to "yes", it sets it to the number of seconds. >=20 > -hadriel > = From christer.holmberg@ericsson.com Fri Apr 16 00:39:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5C93A69BD for ; Fri, 16 Apr 2010 00:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur7lAsQK2-dx for ; Fri, 16 Apr 2010 00:39:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A4DDF3A6BF9 for ; Fri, 16 Apr 2010 00:35:55 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-68-4bc81353740b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6A.F3.23740.35318CB4; Fri, 16 Apr 2010 09:35:47 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 16 Apr 2010 09:35:47 +0200 From: Christer Holmberg To: "Elwell, John" , Hadriel Kaplan , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 09:35:46 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqpQwAABVsJA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 07:39:43 -0000 Hi,=20 >In addition to Hadriel's point, mid-dialog requests do not=20 >necessarily contain Record-Route and Contact, but always=20 >contain Via. So if we rely on Record-Route and Contact, the=20 >decision on keeping connections alive for following the first=20 >mid-dialog request would have to be based on retained state=20 >from the initial request. Does a record-routing proxy=20 >necessarily store Record-route and Contact header fields from=20 >the dialog-forming transaction? I agree that it might not be possible to rely on R-R and Contact in a mid-d= ialog request. But, the current draft does not require a mid-dialog request= . Regards, Christer > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 16 April 2010 08:16 > > To: Christer Holmberg; Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] Keeping alive connections on a=20 > dialog path (was=20 > > RE: Draft new version: draft-ietf-sipcore-keep-02) > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Friday, April 16, 2010 3:03 AM > > > To: Elwell, John; Hadriel Kaplan; sipcore@ietf.org > > >=20 > > > Hi, > > >=20 > > > Just for my understanding, how would Via be simpler, since > > it requires the > > > insertion of "=3Dyes" by the adjacent entity in order to work? > >=20 > > Compared to using several different header types, each used in=20 > > different cases, and having a bunch of if/else checks and=20 > such? How=20 > > *isn't* it simpler? > >=20 > > Setting a received top-most Via param isn't hard is it? =20 > Like the Via=20 > > "received" param. > >=20 > > In fact, instead of doing the new Flow-Timer header, just make the=20 > > "keep" param's value the timer. So instead of setting it=20 > to "yes", it=20 > > sets it to the number of seconds. > >=20 > > -hadriel > > = From john.elwell@siemens-enterprise.com Fri Apr 16 01:04:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C082A3A695A for ; Fri, 16 Apr 2010 01:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0EPlWb7E7Rm for ; Fri, 16 Apr 2010 01:04:42 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1AFBB28C10F for ; Fri, 16 Apr 2010 01:03:25 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1574489; Fri, 16 Apr 2010 10:03:18 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 45C1F1EB82AB; Fri, 16 Apr 2010 10:03:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 16 Apr 2010 10:03:18 +0200 From: "Elwell, John" To: Christer Holmberg , Hadriel Kaplan , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 10:03:16 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqpQwAABVsJAAAK5O0A== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 08:04:43 -0000 Christer, But the current draft requires retention of state from the dialog initiatio= n request to be used when the first mid-dialog request occurs or, as I thin= k you are suggesting, we establish the connection for the mid-dialog path i= mmediately, in anticipation of the first mid-dialog request. Example 1: INVITE. The first mid-dialog request is normally ACK, so following the dialog-formi= ng response to INVITE (e.g., 180), a record-routing proxy establishes a con= nection to the next record-routing proxy and keeps it alive. When the ACK a= rrives, the first record-routing proxy knows it can send it over that trans= port connection. I think this is what you are suggesting. But what if the first mid-dialog request is UPDATE, sent in the backwards d= irection (legal without having used PRACK, as long as UPDATE doesn't contai= n an SDP offer)? Example 2: SUBSCRIBE or REFER. The first mid-dialog request is NOTIFY. If the first record-routing proxy e= stablishes a connection to the second record-routing proxy at the time of t= he SUBSCRIBE response, how does the second record-routing proxy know that t= his can be used for the NOTIFY request? Also what if the NOTIFY request reaches the first record-routing proxy befo= re the SUBSCRIBE response? John =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 16 April 2010 08:36 > To: Elwell, John; Hadriel Kaplan; sipcore@ietf.org > Subject: RE: [sipcore] Keeping alive connections on a dialog path >=20 >=20 > Hi,=20 >=20 > >In addition to Hadriel's point, mid-dialog requests do not=20 > >necessarily contain Record-Route and Contact, but always=20 > >contain Via. So if we rely on Record-Route and Contact, the=20 > >decision on keeping connections alive for following the first=20 > >mid-dialog request would have to be based on retained state=20 > >from the initial request. Does a record-routing proxy=20 > >necessarily store Record-route and Contact header fields from=20 > >the dialog-forming transaction? >=20 > I agree that it might not be possible to rely on R-R and=20 > Contact in a mid-dialog request. But, the current draft does=20 > not require a mid-dialog request. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: 16 April 2010 08:16 > > > To: Christer Holmberg; Elwell, John; sipcore@ietf.org > > > Subject: RE: [sipcore] Keeping alive connections on a=20 > > dialog path (was=20 > > > RE: Draft new version: draft-ietf-sipcore-keep-02) > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Friday, April 16, 2010 3:03 AM > > > > To: Elwell, John; Hadriel Kaplan; sipcore@ietf.org > > > >=20 > > > > Hi, > > > >=20 > > > > Just for my understanding, how would Via be simpler, since > > > it requires the > > > > insertion of "=3Dyes" by the adjacent entity in order to work? > > >=20 > > > Compared to using several different header types, each used in=20 > > > different cases, and having a bunch of if/else checks and=20 > > such? How=20 > > > *isn't* it simpler? > > >=20 > > > Setting a received top-most Via param isn't hard is it? =20 > > Like the Via=20 > > > "received" param. > > >=20 > > > In fact, instead of doing the new Flow-Timer header, just=20 > make the=20 > > > "keep" param's value the timer. So instead of setting it=20 > > to "yes", it=20 > > > sets it to the number of seconds. > > >=20 > > > -hadriel > > > = From keith.drage@alcatel-lucent.com Fri Apr 16 04:42:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7803A6B5D for ; Fri, 16 Apr 2010 04:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCMNNjaOAiTt for ; Fri, 16 Apr 2010 04:42:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 440DE28C19C for ; Fri, 16 Apr 2010 04:37:38 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3GBbP13030312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Apr 2010 13:37:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 16 Apr 2010 13:37:25 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Christer Holmberg'" , "'Paul Kyzivat'" Date: Fri, 16 Apr 2010 13:37:24 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrcmwn1ahq6Ji/uTSecLF1g3QFi5gAGjKeSABHKrjAAFyO+0A== Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <018a01cadc5c$167a5ba0$436f12e0$@com>, <4BC70BD6.4060601@cisco.com> <00cd01cadcfc$8f1f8f80$ad5eae80$@com> In-Reply-To: <00cd01cadcfc$8f1f8f80$ad5eae80$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 11:42:50 -0000 Being pedantic, I would note that the second "MAY" (as in "it MAY send a su= bsequent OPTIONS messages") can apparently be replaced with "can" as all th= is sentence is doing is the possibility of repeating the option expressed b= y the "MAY" in the first sentence. It is not expressing a new requirement. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > Sent: Friday, April 16, 2010 1:34 AM > To: 'Christer Holmberg'; 'Paul Kyzivat' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D=20 > Action:draft-jones-sip-options-ping-00.txt >=20 > Capturing everyone's comments, I changed the paragraph as follows: >=20 > If a requesting entity fails to receive a response to an > OPTIONS message, it MAY retransmit that message following > the procedures defined in RFC 3261. If a requesting entity > receives a 486 or 503 response code, it MAY send a subsequent > OPTIONS messages in order to detect a change in operational > status, but it SHOULD, as per RFC 3261, honor the Retry-After > header field received in the previous response. >=20 > Pail > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, April 15, 2010 12:04 PM > > To: Paul Kyzivat; Paul E. Jones > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > > 00.txt > >=20 > > Hi, > >=20 > > >I'm ok with the SHOULD since that is what is in 3261. What I would=20 > > >prefer to see is some enumeration of the cases when its=20 > appropriate=20 > > >to violate the SHOULD. > >=20 > > If it is a reference to 3261 it would be good to say: > >=20 > > "As specified in RFC 3261, blah blah blah..." > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > Paul E. Jones wrote: > > >> I think that's OK here, since what Brett was suggesting=20 > was that it=20 > > >> is > > >>> already a SHOULD in effect in 3261. In any case, the=20 > worst thing > > >> that > > >>> happens here is that a device ignores the Retry-After header and > > >> claims > > >>> compliance. Apparently, some feel there are plenty of good=20 > > >>> reasons > > >> to do > > >>> so. > > >> I don't think that lets you off the hook. > > >> We've learned from experience that we were too vague in the past. > > >> So I would expect you to be less vague here - being more explicit > > about > > >> what conditions justify violating the SHOULD. > > > > > > Shall I put it back to MUST? Keep in mind, we're not=20 > trying to re- > > define > > > RFC 3261. > > > > > > Paul > > > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Fri Apr 16 06:36:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B0A3A696B for ; Fri, 16 Apr 2010 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.434 X-Spam-Level: X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3vmEC5gbKxT for ; Fri, 16 Apr 2010 06:36:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7D62F28C1B5 for ; Fri, 16 Apr 2010 06:28:47 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADYDyEtAZnwM/2dsb2JhbACDE5hecaQPiGGROYEsgnRuBA X-IronPort-AV: E=Sophos;i="4.52,219,1270425600"; d="scan'208";a="102375263" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2010 13:28:40 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3GDSe2q027643; Fri, 16 Apr 2010 13:28:40 GMT Message-ID: <4BC86607.1000100@cisco.com> Date: Fri, 16 Apr 2010 09:28:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <9961835115.955827726@softarmor.com> In-Reply-To: <9961835115.955827726@softarmor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: paulej@packetizer.com, sipcore@ietf.org, Hadriel Kaplan Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 13:36:13 -0000 Dean Willis wrote: > > > ------- Original message ------- >> From: Paul Kyzivat >> >> Is the intent of the MUST in your draft to strengthen that SHOULD NOT >> in 3261 to MUST NOT for those devices that claim conformance to your >> draft? >> >> If that is the case, then I think it is ok as long as this draft >> itself becomes normative, or a BCP. (I have to check the rules for >> BCPs - I'm not certain if they can have normative statements of their >> own.) I'm pretty sure this would be inappropriate in an informative >> draft, though some non-normative language with the same intent should >> be ok. > > BCP can use 2119 language, but is for documenting practices for which we > have in-the-field experience, so it doesn't really apply here. If I understand Paul Jones's intent, I think that does apply. I think he is suggesting this behavior just for those following the practices he is proposing. > An informative or experimental draft can use such language, but has to > lay out the conditions of "what happens if" and explain "why" in a very > high level of detail. Remember: 2119 is about requirements, and naked > requirements are weaker than naked emperors. They need to be > well-dressed in explanation to be respected. > > That said, if there is adequate justification to change the language of > RFC 3261, then we should probably just change it, and that means a > standards-track draft. I don't think we would change the SHOULD NOT to MUST NOT in 3261. But it would be helpful to change it to SHOULD NOT, with exception for the following cases: ... But that is a different thing than what Paul J is trying to achieve. Thanks, Paul From pkyzivat@cisco.com Fri Apr 16 06:38:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6C33A6C2A for ; Fri, 16 Apr 2010 06:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO1-6zMaXqPW for ; Fri, 16 Apr 2010 06:38:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F061E28C18B for ; Fri, 16 Apr 2010 06:31:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADYDyEtAZnwN/2dsb2JhbACbcXGkD5oahQ4E X-IronPort-AV: E=Sophos;i="4.52,219,1270425600"; d="scan'208";a="102375894" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2010 13:30:59 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3GDUxjV019816; Fri, 16 Apr 2010 13:30:59 GMT Message-ID: <4BC86693.4030908@cisco.com> Date: Fri, 16 Apr 2010 09:30:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <018a01cadc5c$167a5ba0$436f12e0$@com>, <4BC70BD6.4060601@cisco.com> <00cd01cadcfc$8f1f8f80$ad5eae80$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 13:38:06 -0000 All of this (Paul's revision and Keith's tweak) all work for me. Thanks, Paul DRAGE, Keith (Keith) wrote: > Being pedantic, I would note that the second "MAY" (as in "it MAY send a subsequent OPTIONS messages") can apparently be replaced with "can" as all this sentence is doing is the possibility of repeating the option expressed by the "MAY" in the first sentence. It is not expressing a new requirement. > > regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones >> Sent: Friday, April 16, 2010 1:34 AM >> To: 'Christer Holmberg'; 'Paul Kyzivat' >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-jones-sip-options-ping-00.txt >> >> Capturing everyone's comments, I changed the paragraph as follows: >> >> If a requesting entity fails to receive a response to an >> OPTIONS message, it MAY retransmit that message following >> the procedures defined in RFC 3261. If a requesting entity >> receives a 486 or 503 response code, it MAY send a subsequent >> OPTIONS messages in order to detect a change in operational >> status, but it SHOULD, as per RFC 3261, honor the Retry-After >> header field received in the previous response. >> >> Pail >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Thursday, April 15, 2010 12:04 PM >>> To: Paul Kyzivat; Paul E. Jones >>> Cc: sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >>> 00.txt >>> >>> Hi, >>> >>>> I'm ok with the SHOULD since that is what is in 3261. What I would >>>> prefer to see is some enumeration of the cases when its >> appropriate >>>> to violate the SHOULD. >>> If it is a reference to 3261 it would be good to say: >>> >>> "As specified in RFC 3261, blah blah blah..." >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> Paul E. Jones wrote: >>>>> I think that's OK here, since what Brett was suggesting >> was that it >>>>> is >>>>>> already a SHOULD in effect in 3261. In any case, the >> worst thing >>>>> that >>>>>> happens here is that a device ignores the Retry-After header and >>>>> claims >>>>>> compliance. Apparently, some feel there are plenty of good >>>>>> reasons >>>>> to do >>>>>> so. >>>>> I don't think that lets you off the hook. >>>>> We've learned from experience that we were too vague in the past. >>>>> So I would expect you to be less vague here - being more explicit >>> about >>>>> what conditions justify violating the SHOULD. >>>> Shall I put it back to MUST? Keep in mind, we're not >> trying to re- >>> define >>>> RFC 3261. >>>> >>>> Paul >>>> >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From HKaplan@acmepacket.com Fri Apr 16 08:29:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3924528C194 for ; Fri, 16 Apr 2010 08:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeUc5XOsFV34 for ; Fri, 16 Apr 2010 08:29:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2922628C22D for ; Fri, 16 Apr 2010 08:26:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Apr 2010 11:25:55 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Apr 2010 11:25:55 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Paul E. Jones" Date: Fri, 16 Apr 2010 11:25:54 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrcoXGgauSJYZHdSzmJcRpscG12XwA0mcIg Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> In-Reply-To: <4BC7179F.9020604@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: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 15:29:39 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 15, 2010 9:42 AM > To: Paul E. Jones >=20 > Let me see if I fully understand your intent here. > If you said nothing about this, and the result of an OPTIONS ping was a > 503 with a Retry-After, then the recipient would be bound by 3261, which > says: >=20 > A client ... receiving a 503 ... SHOULD NOT > forward any other requests to that server for the duration specified > in the Retry-After header field, if present. >=20 > Is the intent of the MUST in your draft to strengthen that SHOULD NOT in > 3261 to MUST NOT for those devices that claim conformance to your draft? >=20 > If that is the case, then I think it is ok as long as this draft itself > becomes normative, or a BCP. (I have to check the rules for BCPs - I'm > not certain if they can have normative statements of their own.) I'm > pretty sure this would be inappropriate in an informative draft, though > some non-normative language with the same intent should be ok. Afaik you can keep the language even in an Informational. At least 2119 an= d 2026 don't say otherwise, and there are existing published Informational'= s which use the word MUST.=20 The real question is if you SHOULD or SHOULD NOT have this Retry-After stat= ement to begin with. ;) If your goal is interoperability from the customer's perspective, then I th= ink explicitly specifying what the Retry-After really does/means *is* impor= tant. Unfortunately, if you specify that it means no subsequent requests (= other than OPTIONS) are sent, some of us will have to submit another Inform= ational which contradicts this one because for a lot of customers it's the = wrong behavior.=20 -hadriel From HKaplan@acmepacket.com Fri Apr 16 08:42:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6E63A6956 for ; Fri, 16 Apr 2010 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-LNjQNWX0Q3 for ; Fri, 16 Apr 2010 08:42:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 144C03A693E for ; Fri, 16 Apr 2010 08:42:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Apr 2010 11:42:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Apr 2010 11:42:28 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 11:42:21 -0400 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+A= Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 15:42:37 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, April 16, 2010 3:33 AM > To: Hadriel Kaplan; Elwell, John; sipcore@ietf.org > > So, let's look at an example, to make sure I understand you. > An route set has been established, and ACK is sent: >=20 >=20 >=20 > UAC ----------- P1 ----------- UAS >=20 > ---ACK ---------> > ---Via: UAC;keep > ---ACK ---------> > ---Via:P1;keep > ---Via:UAC;keep=3Dyes >=20 > Since there is no reply to ACK, how does the UAS tell P1 that it supports > keep-alives? As I said in my email: it doesn't. But that's ok. SIP isn't broken. > To make it work, wouldn't we need to require UPDATE or PRACK, so that UAS > can send back a response with "Via:P1;keep=3Dyes"? No, we don't need to require anything. The UAS learned P1 supports keep. = If it wants to, it can now send keepalives to P1. P1 has learned that the = UAC supports keep. If it wants to, it can send keepalives to it. If the UAC really wants to send keepalive for some reason, it can send a UP= DATE, re-INVITE, or OPTIONS at its leisure, to find out about P1. If P1 re= ally wants to send keepalive for some reason, it can act as a UA of its own= and send an out-of-dialog OPTIONS. That's it. It's not *broken* - SIP still works, the dialog still exists, e= tc. It's just not "optimal" for this specific call-flow scenario, but who = cares?!? Why double the complexity for the common use-cases, just to make = it less complex for the rare use-cases?? -hadriel From paulej@packetizer.com Fri Apr 16 15:08:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F6D3A6AA3 for ; Fri, 16 Apr 2010 15:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jlqO1uqppKU for ; Fri, 16 Apr 2010 15:08:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id AA58D3A686D for ; Fri, 16 Apr 2010 15:08:41 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3GM8IWb026544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Apr 2010 18:08:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271455704; bh=tZFjZhZX891DpAZKboIY9GsEpp2Rn/JaKRNwV6SNAR4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P655OG9VUz6acOVRpwV7gNz6MraO7LMz7I7vKqhU5TXJpeu1S2pCfEQCYpGoCGbDN dyqJsVZEmfIPkOI1MRB3igwWK6XAKRCu3q93QAXzilBjuaPIgbYvtbJwcVNjzbOWNT TN1vVrinlDG+lwABuWT2EFHEWn8tmy2C4rIPFqgg= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3GM8GsN021298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Apr 2010 18:08:17 -0400 From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , "'Christer Holmberg'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <018a01cadc5c$167a5ba0$436f12e0$@com>, <4BC70BD6.4060601@cisco.com> <00cd01cadcfc$8f1f8f80$ad5eae80$@com> In-Reply-To: Date: Fri, 16 Apr 2010 18:08:07 -0400 Message-ID: <000301caddb1$4ba847f0$e2f8d7d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrcmwn1ahq6Ji/uTSecLF1g3QFi5gAGjKeSABHKrjAAFyO+0AAWFC2g Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 22:08:43 -0000 Ok.. done. Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Friday, April 16, 2010 7:37 AM > To: Paul E. Jones; 'Christer Holmberg'; 'Paul Kyzivat' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > Being pedantic, I would note that the second "MAY" (as in "it MAY send > a subsequent OPTIONS messages") can apparently be replaced with "can" > as all this sentence is doing is the possibility of repeating the > option expressed by the "MAY" in the first sentence. It is not > expressing a new requirement. > > regards > > Keith > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > > Sent: Friday, April 16, 2010 1:34 AM > > To: 'Christer Holmberg'; 'Paul Kyzivat' > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] FW: I-D > > Action:draft-jones-sip-options-ping-00.txt > > > > Capturing everyone's comments, I changed the paragraph as follows: > > > > If a requesting entity fails to receive a response to an > > OPTIONS message, it MAY retransmit that message following > > the procedures defined in RFC 3261. If a requesting entity > > receives a 486 or 503 response code, it MAY send a subsequent > > OPTIONS messages in order to detect a change in operational > > status, but it SHOULD, as per RFC 3261, honor the Retry-After > > header field received in the previous response. > > > > Pail > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, April 15, 2010 12:04 PM > > > To: Paul Kyzivat; Paul E. Jones > > > Cc: sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > > > 00.txt > > > > > > Hi, > > > > > > >I'm ok with the SHOULD since that is what is in 3261. What I would > > > >prefer to see is some enumeration of the cases when its > > appropriate > > > >to violate the SHOULD. > > > > > > If it is a reference to 3261 it would be good to say: > > > > > > "As specified in RFC 3261, blah blah blah..." > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > Paul E. Jones wrote: > > > >> I think that's OK here, since what Brett was suggesting > > was that it > > > >> is > > > >>> already a SHOULD in effect in 3261. In any case, the > > worst thing > > > >> that > > > >>> happens here is that a device ignores the Retry-After header > and > > > >> claims > > > >>> compliance. Apparently, some feel there are plenty of good > > > >>> reasons > > > >> to do > > > >>> so. > > > >> I don't think that lets you off the hook. > > > >> We've learned from experience that we were too vague in the > past. > > > >> So I would expect you to be less vague here - being more > explicit > > > about > > > >> what conditions justify violating the SHOULD. > > > > > > > > Shall I put it back to MUST? Keep in mind, we're not > > trying to re- > > > define > > > > RFC 3261. > > > > > > > > Paul > > > > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Apr 16 15:30:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5213A6877 for ; Fri, 16 Apr 2010 15:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWNfkLOnQCvH for ; Fri, 16 Apr 2010 15:30:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 869A73A6A66 for ; Fri, 16 Apr 2010 15:30:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-72-4bc8e4f91a3b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 88.D9.23532.9F4E8CB4; Sat, 17 Apr 2010 00:30:18 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sat, 17 Apr 2010 00:30:17 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , "sipcore@ietf.org" Date: Sat, 17 Apr 2010 00:30:17 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9Pw== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 22:30:28 -0000 Hi Hadriel, > So, let's look at an example, to make sure I understand you. > An route set has been established, and ACK is sent: > > > > UAC ----------- P1 ----------- UAS > > ---ACK ---------> > ---Via: UAC;keep > ---ACK ---------> > ---Via:P1;keep > ---Via:UAC;keep=3Dyes > > Since there is no reply to ACK, how does the UAS tell P1 that it supports > keep-alives? As I said in my email: it doesn't. But that's ok. SIP isn't broken. > To make it work, wouldn't we need to require UPDATE or PRACK, so that UAS > can send back a response with "Via:P1;keep=3Dyes"? No, we don't need to require anything. The UAS learned P1 supports keep. = If it wants to, it can now send keepalives to P1. P1 has learned that the = UAC supports keep. If it wants to, it can send keepalives to it. >If the UAC really wants to send keepalive for some reason, it can send a U= PDATE, re-INVITE, or OPTIONS at its leisure, to find out about P1. If P1 r= eally wants to send keepalive for some reason, it can act as a UA of its ow= n and send an out-of-dialog OPTIONS. One of the most important use-cases, also documented in the draft, is when = the non-registered UAC wants to send keep-alives for a dialog, e.g. for an = emergency call. It then needs to know that P1 supports keep-alives. >That's it. It's not *broken* - SIP still works, the dialog still exists, = etc. It's just not "optimal" for this specific call-flow scenario, but who= cares?!? Why double the complexity for the common use-cases, just to make= it less complex for the rare use-cases?? I can agree that it is rare that the UAS would want to negotiate keep-alive= s for a dialog - because unless the UAS already sends keep-alives (e.g. ass= ociated with its registration) the INVITE won't even reach it (assuming the= UAS is behind a NAT). So, IF the UAS really wants to negotiate keep-alives= for the dialog, IT can send an UPDATE and negotiate the keep-alives with P= 1. Because, eventhough the UAS may know that P1 supports keep-alives, P1 mi= ght want to be informed that the UAS also support them. BUT, in the example above, replace the UAS with P2. How does P1 know that P= 2 supports keep-alives? YOU are one of those who wanted to support proxy-to= -proxy, so I assume you regard that as an important use-case :) Regards, Christer= From HKaplan@acmepacket.com Fri Apr 16 15:48:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067C73A67D4 for ; Fri, 16 Apr 2010 15:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id died5PicILUI for ; Fri, 16 Apr 2010 15:48:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 116D53A67F0 for ; Fri, 16 Apr 2010 15:48:21 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Apr 2010 18:48:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Apr 2010 18:48:12 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , "sipcore@ietf.org" Date: Fri, 16 Apr 2010 18:48:02 -0400 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9PwAApcjA Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 22:48:23 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, April 16, 2010 6:30 PM >=20 > One of the most important use-cases, also documented in the draft, is whe= n > the non-registered UAC wants to send keep-alives for a dialog, e.g. for a= n > emergency call. It then needs to know that P1 supports keep-alives. And the UAC is free to send an UPDATE or re-INVITE at anytime of its choosi= ng (well, constrained by when it can send such legally). And really, if it's a UA making an Emergency call, it's not gonna be using = a non-session-stateful proxy as its next-hop, and besides it can and should= use SIP session-timers anyway. Because as long as the next-hop proxy continues to be the one you sent the = INVITE to, there's no "issue" with using the Via. The only case it's not o= ptimal in is when the next-hop is a stateless or transaction-stateful proxy= . If you've got one of those, NAT traversal is going to be tough anyway. > BUT, in the example above, replace the UAS with P2. How does P1 know that > P2 supports keep-alives? YOU are one of those who wanted to support proxy= - > to-proxy, so I assume you regard that as an important use-case :) My personal use case isn't for some random next-hop proxy being used only f= or the ACK and later messages of one dialog - it would be for either the sa= me proxy that the INVITE went to, or for a longer-lived relationship, or ev= en provisioned. But anyway, the P1 proxy can send an OPTIONS-ping to find out. -hadriel From christer.holmberg@ericsson.com Fri Apr 16 16:23:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9523A69B5 for ; Fri, 16 Apr 2010 16:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.177 X-Spam-Level: X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=1.422, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxyxxukdq01M for ; Fri, 16 Apr 2010 16:23:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E889A3A6877 for ; Fri, 16 Apr 2010 16:23:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-97-4bc8f1786e83 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 11.7B.23532.871F8CB4; Sat, 17 Apr 2010 01:23:36 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 17 Apr 2010 01:23:36 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 17 Apr 2010 01:23:35 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , "sipcore@ietf.org" Date: Sat, 17 Apr 2010 01:23:34 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9PwAApcjAAAC89/k= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 23:23:47 -0000 Hi, >>One of the most important use-cases, also documented in the draft, is whe= n >>the non-registered UAC wants to send keep-alives for a dialog, e.g. for a= n >>emergency call. It then needs to know that P1 supports keep-alives. > >And the UAC is free to send an UPDATE or re-INVITE at anytime of its choos= ing (well, constrained by when it can send such legally). I think people would have problems to require the usage of UPDATE and re-IN= VITE for emergency calls.=20 Also, you cannot assume SIP session-timers will be required for emergency c= alls. However, that is a separate issue. >And really, if it's a UA making an Emergency call, it's not gonna be using= a non-session-stateful proxy as its next-hop, and besides it can and shoul= d use SIP session-timers anyway. The current assumption is that the next hop is an edge proxy, which IS stat= eful. So, in that case it will be possible to do the keep-alive negotiation= as part of the initial INVITE. (John indicated that the next hop could also be the registrar, so that woul= d also have to be stateful) >Because as long as the next-hop proxy continues to be the one you sent the= INVITE to, there's no "issue" with using the Via. The only case it's not = optimal in is when the=20 >next-hop is a stateless or transaction-stateful proxy. If you've got one = of those, NAT traversal is going to be tough anyway. I agree.=20 So, I am happy to keep the assumption that the next hop is stateful. >>BUT, in the example above, replace the UAS with P2. How does P1 know that >>P2 supports keep-alives? YOU are one of those who wanted to support proxy= - >>to-proxy, so I assume you regard that as an important use-case :) > >My personal use case isn't for some random next-hop proxy being used only = for the ACK and later messages of one dialog - it would be for either the s= ame proxy that the INVITE went to, or for a longer-lived relationship, or e= ven provisioned. For proxy-to-proxy I don't think we can make the assumption that the all th= e proxies that the INVITE traverse will record-route. And, if that is provi= sioned, you can as well provision the usage of keep-alives - there is no ne= ed for a protocol level negotiation... >But anyway, the P1 proxy can send an OPTIONS-ping to find out. But, in that case, why not *only* use OPTIONS-ping, then, and leave proxy-t= o-proxy out of the scope of the keep-draft? I don't think a solution which = requires a proxy to send OPTIONS is simple... Regards, Christer= From HKaplan@acmepacket.com Sat Apr 17 06:08:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7BE3A69DD for ; Sat, 17 Apr 2010 06:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETpCoqMZFCq9 for ; Sat, 17 Apr 2010 06:08:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E04873A6914 for ; Sat, 17 Apr 2010 06:08:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 17 Apr 2010 09:08:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Apr 2010 09:08:16 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , "sipcore@ietf.org" Date: Sat, 17 Apr 2010 09:08:15 -0400 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9PwAApcjAAAC89/kAHRstIA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF107@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 13:08:27 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, April 16, 2010 7:24 PM >=20 > >My personal use case isn't for some random next-hop proxy being used onl= y > >for the ACK and later messages of one dialog - it would be for either th= e > >same proxy that the INVITE went to, or for a longer-lived relationship, > >or even provisioned. >=20 > For proxy-to-proxy I don't think we can make the assumption that the all > the proxies that the INVITE traverse will record-route.=20 Just to be clear, we're not making "assumptions" which affect anything crit= ically. All we're doing is making assumptions for what the common use-case= s of this mechanism are, so we can have a simple mechanism for those cases,= while for other cases the devices might need to do more, or else they may = not be able to leverage the benefits of this mechanism. But that's ok. Th= is mechanism is not fixing something that doesn't work already today. All = it's doing is providing an optimization. It's a valuable/worth-while optim= ization, but an optimization nonetheless, and thus we don't need to address= every possible scenario under the sun. Do you agree with that characterization? > >But anyway, the P1 proxy can send an OPTIONS-ping to find out. >=20 > But, in that case, why not *only* use OPTIONS-ping, then, and leave proxy= - > to-proxy out of the scope of the keep-draft? I don't think a solution > which requires a proxy to send OPTIONS is simple... The solution does NOT "require" sending an OPTIONS, in the sense that there= should be no "MUST" statement to that affect. It's just something the pro= xy can do if it wants to learn about the keepalive ability of another proxy= . The reason why a proxy might not want to only use an OPTIONS-ping is per= formance, that's all. If you prefer, I'm fine with making the proxy-to-proxy case just a side not= e of this draft, by saying something like "A Proxy MAY use the keepalive in= dication of its previous-hop or next-hop to detect that hop supports [outbo= und] keepalives, and MAY send keepalives to that hop." Or something like t= hat. And just keep the focus of the draft the UA case. -hadriel From HKaplan@acmepacket.com Sat Apr 17 06:23:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950803A6B19 for ; Sat, 17 Apr 2010 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tspYUQY938lI for ; Sat, 17 Apr 2010 06:23:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 106D83A6BA1 for ; Sat, 17 Apr 2010 06:22:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 17 Apr 2010 09:22:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Apr 2010 09:22:17 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , "sipcore@ietf.org" Date: Sat, 17 Apr 2010 09:22:16 -0400 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9PwAApcjAAAC89/kAHdl/4A== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF108@mail> References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 13:23:52 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, April 16, 2010 7:24 PM >=20 > >>One of the most important use-cases, also documented in the draft, is > when > >>the non-registered UAC wants to send keep-alives for a dialog, e.g. for > an > >>emergency call. It then needs to know that P1 supports keep-alives. > > > >And the UAC is free to send an UPDATE or re-INVITE at anytime of its > choosing (well, constrained by when it can send such legally). >=20 > I think people would have problems to require the usage of UPDATE and re- > INVITE for emergency calls. I think people would have problems with requiring all UAs and all Proxies t= o support draft-keep. I'd be fine if that could be done, I just don't see = how it reasonably can. It's a very useful optimization, nothing more. > Also, you cannot assume SIP session-timers will be required for emergency > calls. However, that is a separate issue. And you cannot assume draft-keep will be required or supported for emergenc= y calls either. There is no easy answer for emergency calls, if the starti= ng premise is any UA in existence making an emergency call through any Prox= y in existence, without Registering and without any requirements for what t= hey all must support. :) If there were some global standard and authority to enforce what every UA m= ust support to make an Emergency call, I would think the ability to send a = re-INVITE or UPDATE at periodic intervals during the call should be pretty = high on the list. It's the most likely thing to work. (note that sending r= e-INVITES or UPDATEs does not actually require support for session-timers i= n anything) -hadriel From paulej@packetizer.com Sat Apr 17 14:13:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B373A69ED for ; Sat, 17 Apr 2010 14:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvTOqnkhYEzw for ; Sat, 17 Apr 2010 14:13:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 180103A6A06 for ; Sat, 17 Apr 2010 14:12:57 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3HLCX5n024239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Apr 2010 17:12:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271538759; bh=Zc2fqBJGvxoC16v/vt86gw2AplM2umtC1OPAxUireEA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=h6AiyegnbT8Z2cNt8SaeNMpUICbwX9YV/9NnW8aRfSCuuINAQUfnItfuJFNnyoMx5 b8pMevrDYG+2bnojNTC8/JSI7U5+Cn7RGax9YQg1+OXOjx3DHgVxTFdvK0U1ZhFBMO eSvq4j/+yQifrjmpTYhCqim8g2FlS+hKafgfBesA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3HLCW7E023983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Apr 2010 17:12:32 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> Date: Sat, 17 Apr 2010 17:12:21 -0400 Message-ID: <006d01cade72$ab824600$0286d200$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrcoXGgauSJYZHdSzmJcRpscG12XwA0mcIgAD9wE1A= Content-language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 21:13:02 -0000 Hadriel, > The real question is if you SHOULD or SHOULD NOT have this Retry-After > statement to begin with. ;) I think we should at least have SHOULD here, since that's consistent with 3261. > If your goal is interoperability from the customer's perspective, then > I think explicitly specifying what the Retry-After really does/means > *is* important. Unfortunately, if you specify that it means no > subsequent requests (other than OPTIONS) are sent, some of us will have > to submit another Informational which contradicts this one because for > a lot of customers it's the wrong behavior. I don't want this document to change the rules as defined in 3261, unless we want to also change 3261 in the process. All we were hoping to do with the draft is to take a practice that is common, but not consistently implemented, legitimize it, and specify what devices should do. In the process, I don't want to create contradictory statements about that client/server interactions should be. I do want to encourage a client to observe a Retry-After header if it gets it, but I do not want to mandate that servers send that header nor do I want to change anything about the processing rules as specified in 3261. Given that these are widely implemented by a variety of devices, I'd personally like to see this put forward as a Standards Track RFC. We're not trying to define procedures to keep firewall pinholes open nor define a way to manage server overload with this: it has a very limit, but useful scope. Paul From HKaplan@acmepacket.com Sat Apr 17 18:50:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EF13A6A95 for ; Sat, 17 Apr 2010 18:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGSmtje7KARM for ; Sat, 17 Apr 2010 18:50:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5FA9E3A6452 for ; Sat, 17 Apr 2010 18:50:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 17 Apr 2010 21:50:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Apr 2010 21:50:17 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Sat, 17 Apr 2010 21:50:15 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrcoXGgauSJYZHdSzmJcRpscG12XwA0mcIgAD9wE1AACYOSoA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> In-Reply-To: <006d01cade72$ab824600$0286d200$@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: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 01:50:27 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, April 17, 2010 5:12 PM >=20 > I don't want this document to change the rules as defined in 3261, unless > we > want to also change 3261 in the process. It's not - 3261 says "SHOULD NOT", not "MUST NOT". Per RFC 2119, it means: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. =20 So your draft can simply be an Informational document, describing such circ= umstances. :) > All we were hoping to do with the draft is to take a practice that is > common, but not consistently implemented, legitimize it, and specify what > devices should do. Right, and I think it's bad form to recommend something that is knowingly a= bad idea in certain, common circumstances. If in most circumstances people have to configure systems to NOT follow thi= s draft's recommendations, then what good is the draft?? Isn't it in fact = harmful? =20 > Given that these are widely implemented by a variety of devices, I'd > personally like to see this put forward as a Standards Track RFC. We're > not > trying to define procedures to keep firewall pinholes open nor define a > way > to manage server overload with this: it has a very limit, but useful scop= e. My concern isn't about keeping firewall pinholes open. My concern is that = if a server becomes overloaded and sends a 503, that not only causes a comp= lete swing to 0% utilization, but more importantly the BYE's don't get sent= . Likewise, some people use it for admin-down state, to take a server out = of service gracefully - and thus still expect in-dialog requests. -hadriel From paulej@packetizer.com Sat Apr 17 19:13:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FC13A6A3F for ; Sat, 17 Apr 2010 19:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z07L3AlxosWY for ; Sat, 17 Apr 2010 19:13:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 628FA3A6992 for ; Sat, 17 Apr 2010 19:13:22 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3I2D5Iv010707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Apr 2010 22:13:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271556791; bh=BXMcZLAnIMnBSY8CLFV9FIUWr25Z+alWkuL/HHWuu3Q=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lUa1dPMxsEJbbFP4AwFQZJt28ChgMqkCWGJ1q4KikyZUmOD+Ju+coB5cltUpCbp0/ VBPPJfPoTANGvxHclaqX4jUnxkc4kITUMYjQuPceZisy0PGYq0sBDehl5N5Danm+Ew /sj9ImDpeWHMQaq5BoWLqLErJYa22YEvDmG3ItHc= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3I2D4eS024907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Apr 2010 22:13:04 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> Date: Sat, 17 Apr 2010 22:12:52 -0400 Message-ID: <009501cade9c$a6e4aff0$f4ae0fd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrcoXGgauSJYZHdSzmJcRpscG12XwA0mcIgAD9wE1AACYOSoAAA8DCw Content-language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 02:13:24 -0000 Hadriel, > > I don't want this document to change the rules as defined in 3261, > unless > > we > > want to also change 3261 in the process. > > It's not - 3261 says "SHOULD NOT", not "MUST NOT". Per RFC 2119, it > means: > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. The sentence in question in my draft is does not have NOT in it. It is this: "... it can send a subsequent OPTIONS messages in order to detect a change in operational status, but it SHOULD, as per RFC 3261, honor the Retry-After header field received in the previous response." (The above was revised as per list discussion.) > So your draft can simply be an Informational document, describing such > circumstances. :) We could do that, though I think it would be better to make it standards track in order to encourage consistent behavior and to legitimize a practice that is in wide use. > > All we were hoping to do with the draft is to take a practice that is > > common, but not consistently implemented, legitimize it, and specify > what > > devices should do. > > Right, and I think it's bad form to recommend something that is > knowingly a bad idea in certain, common circumstances. What recommendation is in the draft that's "bad"? Anything can be bad in some circumstances, but I don't think an OPTIONS "ping" is a bad idea. > If in most circumstances people have to configure systems to NOT follow > this draft's recommendations, then what good is the draft?? Isn't it > in fact harmful? Potentially, but that's why I want a set of procedures people can agree to. > > Given that these are widely implemented by a variety of devices, I'd > > personally like to see this put forward as a Standards Track RFC. > We're > > not > > trying to define procedures to keep firewall pinholes open nor define > a > > way > > to manage server overload with this: it has a very limit, but useful > scope. > > My concern isn't about keeping firewall pinholes open. My concern is > that if a server becomes overloaded and sends a 503, that not only > causes a complete swing to 0% utilization, but more importantly the > BYE's don't get sent. Likewise, some people use it for admin-down > state, to take a server out of service gracefully - and thus still > expect in-dialog requests. Understood, but we're not proposing that a server send that lightly. It should be done under the same circumstances as if it received an INVITE and decided to send a 503. Again, this draft is not trying to change the behavior of 3261. We're just trying to define a consistent usage of OPTIONS as an application-level ping mechanism. Paul From HKaplan@acmepacket.com Sat Apr 17 19:27:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD9E3A6A59 for ; Sat, 17 Apr 2010 19:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7ku39P6Dssb for ; Sat, 17 Apr 2010 19:27:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CFC543A6817 for ; Sat, 17 Apr 2010 19:27:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 17 Apr 2010 22:27:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 17 Apr 2010 22:27:37 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Sat, 17 Apr 2010 22:27:37 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrcoXGgauSJYZHdSzmJcRpscG12XwA0mcIgAD9wE1AACYOSoAAA8DCwAACzMiA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> In-Reply-To: <009501cade9c$a6e4aff0$f4ae0fd0$@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: "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 02:27:46 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, April 17, 2010 10:13 PM >=20 > The sentence in question in my draft is does not have NOT in it. It is > this: > "... it can send a subsequent OPTIONS messages in order to detect a chang= e > in operational status, but it SHOULD, as per RFC 3261, honor the Retry- > After > header field received in the previous response." > (The above was revised as per list discussion.) Sorry, I should have been clearer - I meant the statement in section 21.5.4= of 3261 about not sending subsequent requests: A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. I thought that's what you and other were concerned about "changing" or "ove= rriding". > > So your draft can simply be an Informational document, describing such > > circumstances. :) >=20 > We could do that, though I think it would be better to make it standards > track in order to encourage consistent behavior and to legitimize a > practice > that is in wide use. Sure - I just thought you wanted to keep it Informational. > What recommendation is in the draft that's "bad"? Anything can be bad in > some circumstances, but I don't think an OPTIONS "ping" is a bad idea. I meant keeping with the 3261 language I noted above, if it's not qualified= further. -hadriel From christer.holmberg@ericsson.com Sun Apr 18 09:51:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083C73A6909 for ; Sun, 18 Apr 2010 09:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.193 X-Spam-Level: X-Spam-Status: No, score=-5.193 tagged_above=-999 required=5 tests=[AWL=1.406, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrenEoQRocQ8 for ; Sun, 18 Apr 2010 09:51:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0A2863A6841 for ; Sun, 18 Apr 2010 09:51:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-68-4bcb387a12a4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4D.F4.23532.A783BCB4; Sun, 18 Apr 2010 18:51:06 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 18 Apr 2010 18:51:06 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sun, 18 Apr 2010 18:51:05 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , "sipcore@ietf.org" Date: Sun, 18 Apr 2010 18:51:04 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9PwAApcjAAAC89/kAHdl/4AA52/WS Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF108@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF108@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 16:51:17 -0000 Hi, >>I think people would have problems to require the usage of UPDATE and re-= INVITE for emergency calls. > >I think people would have problems with requiring all UAs and all Proxies = to support draft-keep. I'd be fine if that could be done, I just don't see= how it reasonably can. It's a very useful optimization, nothing more. > >>Also, you cannot assume SIP session-timers will be required for emergency= calls. However, that is a separate issue. > >And you cannot assume draft-keep will be required or supported for emergen= cy calls either. There is no easy answer for emergency calls, if the start= ing premise is any UA in existence making an emergency call through any Pro= xy in existence, without Registering and=20 >without any requirements for what they all must support. :) That's not what I was saying. I was saying that IF a UA supports and uses d= raft-keep, I don't think they should have to send UPDATE/re-INVITEs for the= negotiation of keep-alives. Then, if they send periodic UPDATEs/re-INVITEs= in order to keep the session alive is a separate issue. The puropse of kee= p-alives from UAs is to maintain NAT bindings. And, for whatever it's worth, at least IMS UEs are required to support draf= t-keep :) Regards, Christer= From christer.holmberg@ericsson.com Sun Apr 18 10:12:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801E23A69E5 for ; Sun, 18 Apr 2010 10:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq3IRIpVeKVj for ; Sun, 18 Apr 2010 10:12:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4D5EB3A6A45 for ; Sun, 18 Apr 2010 10:11:33 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-c4-4bcb3d3a9b9c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 98.D0.23740.A3D3BCB4; Sun, 18 Apr 2010 19:11:23 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 18 Apr 2010 19:11:23 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , "sipcore@ietf.org" Date: Sun, 18 Apr 2010 19:11:21 +0200 Thread-Topic: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) Thread-Index: AcrcXeOly77CLa31THyi9P9k4ceGJAAEiR+wAAMLdhAAAX764AAk/jvAAAP4dAAAAWcW0AAApiJwAAEaMbAAABoCYAAAqZfQABDdf+AADju9PwAApcjAAAC89/kAHRstIAA61z6t Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79FCEEE8@mail> <430FC6BDED356B4C8498F634416644A91A79FCEF0E@mail> , <430FC6BDED356B4C8498F634416644A91A79FCEFC4@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF0EA@mail> , <430FC6BDED356B4C8498F634416644A91A79FCF107@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF107@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Keeping alive connections on a dialog path (was RE: Draft new version: draft-ietf-sipcore-keep-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 17:12:04 -0000 Hi, >>>My personal use case isn't for some random next-hop proxy being used onl= y >>>for the ACK and later messages of one dialog - it would be for either th= e >>>same proxy that the INVITE went to, or for a longer-lived relationship, >>>or even provisioned. >> >>For proxy-to-proxy I don't think we can make the assumption that the all >>the proxies that the INVITE traverse will record-route. > >Just to be clear, we're not making "assumptions" which affect anything cri= tically. All we're doing is making assumptions for what the common use-cas= es of this mechanism are, so we can have a simple mechanism for those cases= , while for other cases the devices might need=20 >o do more, or else they may not be able to leverage the benefits of this m= echanism. But that's ok. This mechanism is not fixing something that does= n't work already today. All it's doing is providing an optimization. It's= a valuable/worth-while optimization, but an=20 >optimization nonetheless, and thus we don't need to address every possible= scenario under the sun. >Do you agree with that characterization? Are we assuming that there will be no proxy between the UA and edge proxy? = I believe Outbound makes that assumption. IF we make that assumption, the UA and edge proxy will be able to negotiate= the keep-alive as part of the initial INVITE. No need for UPDATEs/re-INVIT= E. IF we do NOT make that assumption, the UA will have to send UPDATE/re-INVIT= Es, because there MAY be another proxy between the UA and edge proxy. I think we both agree that the most common use-case will be when there is n= o other proxy between the UA and edge proxy. But, we don't optimize the sol= ution for that use-case if the UA needs to send UPDATE/re-INVITE in order t= o support the proxy-in-between use-case... >>>But anyway, the P1 proxy can send an OPTIONS-ping to find out. >> >>But, in that case, why not *only* use OPTIONS-ping, then, and leave proxy= - >>to-proxy out of the scope of the keep-draft? I don't think a solution >>which requires a proxy to send OPTIONS is simple... > >The solution does NOT "require" sending an OPTIONS, in the sense that ther= e should be no "MUST" statement to that affect. It's just something the pr= oxy can do if it wants to learn about the keepalive ability of another prox= y. The reason why a proxy might not want to=20 >only use an OPTIONS-ping is performance, that's all. > >If you prefer, I'm fine with making the proxy-to-proxy case just a side no= te of this draft, by saying something like "A Proxy MAY use the keepalive i= ndication of its previous-hop or next-hop to detect that hop supports [outb= ound] keepalives, and MAY send keepalives to=20 >that hop." Yes. But, then we need to describe that the proxies will not be able to neg= otiate the keep-alives during the initial INVITE, and that they need to wai= t for a UA to send UPDATE/re-INVITE before they can negotiate keep-alives. >Or something like that. And just keep the focus of the draft the UA case. Also keep in mind that keep-alives negotiated for a dialog will only be sen= t within that dialog. So, the question is whether people are interested in = such proxy-to-proxy functionality in the first place? From what I've heard = people are looking for a more "static" ping, not associated with a dialog -= something which option-ping provides. Regards, Christer= From paulej@packetizer.com Sun Apr 18 13:54:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6531F28C144 for ; Sun, 18 Apr 2010 13:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT7Mfjzs--Li for ; Sun, 18 Apr 2010 13:54:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 1ED933A6BC1 for ; Sun, 18 Apr 2010 13:54:46 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3IKsSI7006723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Apr 2010 16:54:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271624074; bh=n0g+YQQ2gmGKsm0D8Eq6fv5KIZvtXM2aqXhgP9SlvjA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=rFKqqgtzRP1TT5Ao70dNnTUzWesdx0inzjph7hdcIgPbzbdTfBpk8NkPIjSAPfz9l 1jf2ymstj6cO9Sfc4BTV2GCDQUa3ycV4NmTNJLrF6CgNBH23iNPyHpEDwoJfaQT2A8 X9QL9SBwSV8lrjL+wcjwtw4k22kYsByj2utXcD70= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3IKsR4e006157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Apr 2010 16:54:27 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> Date: Sun, 18 Apr 2010 16:54:14 -0400 Message-ID: <009801cadf39$4dda9120$e98fb360$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrcoXGgauSJYZHdSzmJcRpscG12XwA0mcIgAD9wE1AACYOSoAAA8DCwAACzMiAAJkxvsA== Content-language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 20:54:47 -0000 Hadriel, Ah, OK... I think we're on the same page, then. The changes from the -00 draft to the current draft have been extremely minimal thus far. You can see the current change here: http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft-jones-sip- options-ping-01.pdf I believe I've reflected everyone's comments and, I hope, the text does not suggest a different direction than what is specified in 3261. Now the next question, what shall we do with this? As I said, I think it ought to be a WG document. It is, after all, behavior that is widely implemented, but not implemented consistently. Further, 3261 does not specify the usage of OPTIONS for a "ping", so it needs documenting. Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Saturday, April 17, 2010 10:28 PM > To: Paul E. Jones; 'Paul Kyzivat' > Cc: 'Brett Tate'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Saturday, April 17, 2010 10:13 PM > > > > The sentence in question in my draft is does not have NOT in it. It > is > > this: > > "... it can send a subsequent OPTIONS messages in order to detect a > change > > in operational status, but it SHOULD, as per RFC 3261, honor the > Retry- > > After > > header field received in the previous response." > > (The above was revised as per list discussion.) > > Sorry, I should have been clearer - I meant the statement in section > 21.5.4 of 3261 about not sending subsequent requests: > A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > attempt to forward the request to an alternate server. It SHOULD > NOT > forward any other requests to that server for the duration specified > in the Retry-After header field, if present. > > I thought that's what you and other were concerned about "changing" or > "overriding". > > > > So your draft can simply be an Informational document, describing > such > > > circumstances. :) > > > > We could do that, though I think it would be better to make it > standards > > track in order to encourage consistent behavior and to legitimize a > > practice > > that is in wide use. > > Sure - I just thought you wanted to keep it Informational. > > > > What recommendation is in the draft that's "bad"? Anything can be > bad in > > some circumstances, but I don't think an OPTIONS "ping" is a bad > idea. > > I meant keeping with the 3261 language I noted above, if it's not > qualified further. > > -hadriel > From pkyzivat@cisco.com Sun Apr 18 16:19:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB47A3A6988 for ; Sun, 18 Apr 2010 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3icu-idrgyAP for ; Sun, 18 Apr 2010 16:19:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 48DF33A6A17 for ; Sun, 18 Apr 2010 16:18:19 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8wy0tAZnwM/2dsb2JhbACbeXGgYZh5glCCQAQ X-IronPort-AV: E=Sophos;i="4.52,232,1270425600"; d="scan'208";a="102889338" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2010 23:18:10 +0000 Received: from [10.86.254.94] ([10.86.254.94]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3INI9VZ024273; Sun, 18 Apr 2010 23:18:09 GMT Message-ID: <4BCB9331.50703@cisco.com> Date: Sun, 18 Apr 2010 19:18:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> In-Reply-To: <009801cadf39$4dda9120$e98fb360$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 23:19:04 -0000 [as co-chair] Paul E. Jones wrote: > Now the next question, what shall we do with this? As I said, I think it > ought to be a WG document. It is, after all, behavior that is widely > implemented, but not implemented consistently. Further, 3261 does not > specify the usage of OPTIONS for a "ping", so it needs documenting. Well, we already had another proposal for work on OPTIONS, but have not yet decided whether the WG will take this up or not. *This* work might be considered an aspect of that, or it might be considered and entirely separate thing. Either way we will need to see if there is enough interest from the WG to do this. So far there has been considerable activity from two people, with a couple of others chiming in from time to time. It would be easier to take this up if there were broader interest. Or potentially we could pursue advancing it as an individual draft. I'd like to hear from some other people on this. That would help us to understand the extent to which this is "best practice". Thanks, Paul From christer.holmberg@ericsson.com Sun Apr 18 21:14:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1655C28C100 for ; Sun, 18 Apr 2010 21:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=1.398, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIAGjL6pScky for ; Sun, 18 Apr 2010 21:14:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9FBFA28C0F3 for ; Sun, 18 Apr 2010 21:14:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-30-4bcbd8983f3b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 96.03.23532.898DBCB4; Mon, 19 Apr 2010 06:14:16 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 19 Apr 2010 06:14:16 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "Paul E. Jones" Date: Mon, 19 Apr 2010 06:14:15 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrfTY05Hj52+nKRTrK+zaAeQ1MJeAAKOP4g Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <430FC6BDED356B4C8498F634416644A91A79E9327E@mail> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> <4BCB9331.50703@cisco.com> In-Reply-To: <4BCB9331.50703@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: "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 04:14:28 -0000 Hi,=20 >>Now the next question, what shall we do with this? As I said, I think=20 >>it ought to be a WG document. It is, after all, behavior that is=20 >>widely implemented, but not implemented consistently. Further, 3261=20 >>does not specify the usage of OPTIONS for a "ping", so it needs documenti= ng. > >Well, we already had another proposal for work on OPTIONS, but have not ye= t decided whether the WG will take this up or not. > >*This* work might be considered an aspect of that, or it might be consider= ed and entirely separate thing. Either way we will need to see if there is = enough interest from the WG to do this. > >So far there has been considerable activity from two people, with a couple= of others chiming in from time to time. > >It would be easier to take this up if there were broader interest. >Or potentially we could pursue advancing it as an individual draft. > >I'd like to hear from some other people on this. That would help us to und= erstand the extent to which this is "best practice". Note that we already have a previous decission to work on a proxy-to-proxy = ping/heartbeat MECHANISM as such, using the keep-draft. So, I think the question is whether we want to use the keep-draft, options-= ping, or both to implement that mechanism. Regards, Christer From pkyzivat@cisco.com Mon Apr 19 05:52:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AC828C0E2 for ; Mon, 19 Apr 2010 05:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmwvMdLFbCbo for ; Mon, 19 Apr 2010 05:52:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1A3153A6ABA for ; Mon, 19 Apr 2010 05:52:13 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACXuy0tAZnwN/2dsb2JhbACbdnGgcZkdglCCQAQ X-IronPort-AV: E=Sophos;i="4.52,235,1270425600"; d="scan'208";a="103043938" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Apr 2010 12:52:04 +0000 Received: from [10.86.254.94] ([10.86.254.94]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3JCq3GH020294; Mon, 19 Apr 2010 12:52:03 GMT Message-ID: <4BCC51F3.20108@cisco.com> Date: Mon, 19 Apr 2010 08:52:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <01a201cad2a5$ae1096c0$0a31c440$@com> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> <4BCB9331.50703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 12:52:18 -0000 Christer Holmberg wrote: > Hi, > >>> Now the next question, what shall we do with this? As I said, I think >>> it ought to be a WG document. It is, after all, behavior that is >>> widely implemented, but not implemented consistently. Further, 3261 >>> does not specify the usage of OPTIONS for a "ping", so it needs documenting. >> Well, we already had another proposal for work on OPTIONS, but have not yet decided whether the WG will take this up or not. >> >> *This* work might be considered an aspect of that, or it might be considered and entirely separate thing. Either way we will need to see if there is enough interest from the WG to do this. >> >> So far there has been considerable activity from two people, with a couple of others chiming in from time to time. >> >> It would be easier to take this up if there were broader interest. >> Or potentially we could pursue advancing it as an individual draft. >> >> I'd like to hear from some other people on this. That would help us to understand the extent to which this is "best practice". > > Note that we already have a previous decission to work on a proxy-to-proxy ping/heartbeat MECHANISM as such, using the keep-draft. > > So, I think the question is whether we want to use the keep-draft, options-ping, or both to implement that mechanism. People can correct me if I'm wrong - my impression is that the *intent* of the keep stuff and the options ping stuff is different, at least in emphasis. I am thinking the focus of keep is on keeping nat pinholes open, while the focus of options ping is on determination of which neighbors are up/down. But each may be suitable for the other purpose itself. So there is overlap, at least in the eyes of some. And of course there is also some perceived overlap between detecting neighbors that are down and overload control. So to an extent its a matter of whether to characterize this ping work as part of one of those other charters, or as something independent of them. What is your take on that? Thanks, Paul From christer.holmberg@ericsson.com Mon Apr 19 06:02:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2FA3A69D8 for ; Mon, 19 Apr 2010 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6X4CWf81bOt for ; Mon, 19 Apr 2010 06:02:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0E6423A6A81 for ; Mon, 19 Apr 2010 06:02:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-a1-4bcc545a8f9f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 85.9B.23532.A545CCB4; Mon, 19 Apr 2010 15:02:18 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 19 Apr 2010 15:02:16 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 19 Apr 2010 15:02:15 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrfvyeee51qSJfoStCSIX57JjwbEgAAGSCA Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> <4BCB9331.50703@cisco.com> <4BCC51F3.20108@cisco.com> In-Reply-To: <4BCC51F3.20108@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: "Paul E. Jones" , "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 13:02:31 -0000 Hi,=20 >>>>Now the next question, what shall we do with this? As I said, I=20 >>>>think it ought to be a WG document. It is, after all,=20 >>>>behavior that is widely implemented, but not implemented consistently. = =20 >>>>Further, 3261 does not specify the usage of OPTIONS for a "ping",=20 >>>>so it needs documenting. >>>Well, we already had another proposal for work on OPTIONS,=20 >>>but have not yet decided whether the WG will take this up or not. >>> >>>*This* work might be considered an aspect of that, or it=20 >>>might be considered and entirely separate thing. Either way=20 >>>we will need to see if there is enough interest from the WG=20 >>>to do this. >>> >>>So far there has been considerable activity from two=20 >>>people, with a couple of others chiming in from time to time. >>> >>>It would be easier to take this up if there were broader interest. >>>Or potentially we could pursue advancing it as an individual draft. >>> >>>I'd like to hear from some other people on this. That=20 >>>would help us to understand the extent to which this is "best=20 >>>practice". >>=20 >>Note that we already have a previous decission to work on a=20 >>proxy-to-proxy ping/heartbeat MECHANISM as such, using the keep-draft. >>=20 >>So, I think the question is whether we want to use the=20 >>keep-draft, options-ping, or both to implement that mechanism. >=20 >People can correct me if I'm wrong - my impression is that=20 >the *intent* of the keep stuff and the options ping stuff is=20 >different, at least in emphasis. I am thinking the focus of=20 >keep is on keeping nat pinholes open, while the focus of=20 >options ping is on determination of which neighbors are up/down. It is correct that keeping nat pinholes open, between a UA and its edge pro= xy/registrar, is the main focus and scope of the document. However, at some point I was asked to also cover proxy-to-proxy heartbeat i= n the document, and nobody objected. =20 >But each may be suitable for the other purpose itself. So=20 >there is overlap, at least in the eyes of some. >=20 >And of course there is also some perceived overlap between=20 >detecting neighbors that are down and overload control. >=20 >So to an extent its a matter of whether to characterize this=20 >ping work as part of one of those other charters, or as=20 >something independent of them. What is your take on that? Personally I don't mind removing proxy-to-proxy hearbeat from the keep-draf= t - assuming we would adopt options-ping for that purpose. I do believe the= functionality is needed. And, as I said earlier, it seems like people want to have something persist= ant, not associated with a dialog, and if that is the case then options-pin= g would probably be better.=20 So, it really depends on what people want between proxies. Something which = is per dialog, or something which is more persistant - or both? Regards, Christer= From paulej@packetizer.com Mon Apr 19 09:58:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66C83A6C3C for ; Mon, 19 Apr 2010 09:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRLh9HozJihX for ; Mon, 19 Apr 2010 09:58:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id BB4BA28B23E for ; Mon, 19 Apr 2010 09:48:10 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3JGlplt023581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Apr 2010 12:47:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1271695677; bh=SIaEoNrpTNY1XBNXPmofNRWlFqgHHmr4huvkM3sHZl0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VxZUafIApnDC4waBQqjz0MxHVUB2txnpSA4ahOLiuS3lm+/pCvIdMrCXR9NFjW//o 9x1TFW2hHkdbT9Gk26bSmznpCxx9X72xdgteF/LZNU+T06CvmgPk+KzGMUWs09zLTn n1XgM5gEpbzva4oOiFwjoQfaVPFrcChvx3Em4BuU= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3JGlnhf009477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Apr 2010 12:47:49 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Christer Holmberg'" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <003201cad3a5$6f263540$4d729fc0$@com> <747A6506A991724FB09B129B79D5FEB61480BBFACB@EXMBXCLUS01.citservers.local> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> <4BCB9331.50703@cisco.com> <4BCC51F3.20108@c isco.com> In-Reply-To: <4BCC51F3.20108@cisco.com> Date: Mon, 19 Apr 2010 12:47:35 -0400 Message-ID: <018201cadfe0$0380ee10$0a82ca30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrfvyGpRGvM/q1eReaPPFNHCkre+gAHf9YQ Content-language: en-us Cc: sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 16:58:35 -0000 Paul, > People can correct me if I'm wrong - my impression is that the *intent* > of the keep stuff and the options ping stuff is different, at least in > emphasis. I am thinking the focus of keep is on keeping nat pinholes > open, while the focus of options ping is on determination of which > neighbors are up/down. That's also my understanding. > But each may be suitable for the other purpose itself. So there is > overlap, at least in the eyes of some. > > And of course there is also some perceived overlap between detecting > neighbors that are down and overload control. > > So to an extent its a matter of whether to characterize this ping work > as part of one of those other charters, or as something independent of > them. What is your take on that? I fully agree that the OPTIONS "ping" can be viewed as overlapping with the other two drafts. As you know, it was not the intent of the "ping" mechanism to serve as an overload mechanism, nor was it intended as a means of keeping pinholes open. I think both the keep and overload work is needed, as they work to solve specific problems. Likewise, I think we need the "ping" mechanism in places where the other two would not provide the desired device status information. We would not need keep or overload between some devices. Paul From pkyzivat@cisco.com Mon Apr 19 10:34:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426973A68ED for ; Mon, 19 Apr 2010 10:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCW7tlS9yRfF for ; Mon, 19 Apr 2010 10:34:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DD7BB3A69A9 for ; Mon, 19 Apr 2010 10:32:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcvzEtAZnwN/2dsb2JhbACbeHGkBJkxgm0IghkE X-IronPort-AV: E=Sophos;i="4.52,236,1270425600"; d="scan'208";a="102994963" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Apr 2010 17:32:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3JHWPqj027565; Mon, 19 Apr 2010 17:32:25 GMT Message-ID: <4BCC93A8.50401@cisco.com> Date: Mon, 19 Apr 2010 13:32:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01a201cad2a5$ae1096c0$0a31c440$@com> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> <4BCB9331.50703@cisco.com> <4BCC51F3.20108@c isco.com> <018201cadfe0$0380ee10$0a82ca30$@com> In-Reply-To: <018201cadfe0$0380ee10$0a82ca30$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 17:34:19 -0000 Paul E. Jones wrote: > Paul, > >> People can correct me if I'm wrong - my impression is that the *intent* >> of the keep stuff and the options ping stuff is different, at least in >> emphasis. I am thinking the focus of keep is on keeping nat pinholes >> open, while the focus of options ping is on determination of which >> neighbors are up/down. > > That's also my understanding. > >> But each may be suitable for the other purpose itself. So there is >> overlap, at least in the eyes of some. >> >> And of course there is also some perceived overlap between detecting >> neighbors that are down and overload control. >> >> So to an extent its a matter of whether to characterize this ping work >> as part of one of those other charters, or as something independent of >> them. What is your take on that? > > I fully agree that the OPTIONS "ping" can be viewed as overlapping with the > other two drafts. > > As you know, it was not the intent of the "ping" mechanism to serve as an > overload mechanism, nor was it intended as a means of keeping pinholes open. > > I think both the keep and overload work is needed, as they work to solve > specific problems. > > Likewise, I think we need the "ping" mechanism in places where the other two > would not provide the desired device status information. We would not need > keep or overload between some devices. I don't *in principle* have a problem with treating these as separate things. But then we must ensure that they don't have unintended (negative) interactions. That should be managed by careful scoping and by ensuring that they take account of one another. Christer indicated that there was a previous decision to include proxy-proxy keep-alives in the -keep draft. Christer - do you know where that decision might be documented? The existing goal list is very vague on this. If we were to piggyback options-ping onto that goal, it would make it even later than it already is. Otherwise it will need a new goal to become a WG draft. We will need some support from the ADs for that. But before asking them, I would like to see a broader level of interest on this mailing list. THanks Paul From christer.holmberg@ericsson.com Mon Apr 19 14:14:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E3D3A6A49 for ; Mon, 19 Apr 2010 14:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKH-BjAAa7k6 for ; Mon, 19 Apr 2010 14:14:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 27A263A695B for ; Mon, 19 Apr 2010 14:14:08 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-f9-4bccc797cae8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 22.52.23740.797CCCB4; Mon, 19 Apr 2010 23:13:59 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 19 Apr 2010 23:13:59 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 19 Apr 2010 23:13:58 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "Paul E. Jones" Date: Mon, 19 Apr 2010 23:13:58 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrf5ksFCcMa9uWWTVaz5EH1VoZKhwAHldAg Message-ID: References: <01a201cad2a5$ae1096c0$0a31c440$@com> <002901cad90a$6e6fee10$4b4fca30$@com> <747A6506A991724FB09B129B79D5FEB61480D10784@EXMBXCLUS01.citservers.local> <00d701cad9c0$394a0160$abde0420$@com> <4BC3273D.7090902@cisco.com> <003501cada4a$44b220c0$ce166240$@com> <4BC338F9.80604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D7D3@mail> <747A6506A991724FB09B129B79D5FEB61480D10C16@EXMBXCLUS01.citservers.local> <4BC3B9C9.7090108@cisco.com> <01a401cadc64$6ab7a120$4026e360$@com> <4BC7179F.9020604@cisco.com> <430FC6BDED356B4C8498F634416644A91A79FCEFAD@mail> <006d01cade72$ab824600$0286d200$@com> <430FC6BDED356B4C8498F634416644A91A79FCF110@mail> <009501cade9c$a6e4aff0$f4ae0fd0$@com> <430FC6BDED356B4C8498F634416644A91A79FCF111@mail> <009801cadf39$4dda9120$e98fb360$@com> <4BCB9331.50703@cisco.com> <4BCC51F3.20108@c isco.com> <018201cadfe0$0380ee10$0a82ca30$@com> <4BCC93A8.50401@cisco.com> In-Reply-To: <4BCC93A8.50401@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: "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:14:13 -0000 Hi,=20 >>> People can correct me if I'm wrong - my impression is that the=20 >>> *intent* of the keep stuff and the options ping stuff is different,=20 >>> at least in emphasis. I am thinking the focus of keep is on keeping=20 >>> nat pinholes open, while the focus of options ping is on=20 >>> determination of which neighbors are up/down. >>=20 >> That's also my understanding. >> =20 >>> But each may be suitable for the other purpose itself. So there is=20 >>> overlap, at least in the eyes of some. >>> >>> And of course there is also some perceived overlap between detecting=20 >>> neighbors that are down and overload control. >>> >>> So to an extent its a matter of whether to characterize this ping=20 >>> work as part of one of those other charters, or as something=20 >>> independent of them. What is your take on that? >>=20 >> I fully agree that the OPTIONS "ping" can be viewed as overlapping=20 >> with the other two drafts. >>=20 >> As you know, it was not the intent of the "ping" mechanism to serve as=20 >> an overload mechanism, nor was it intended as a means of keeping pinhole= s open. >>=20 >> I think both the keep and overload work is needed, as they work to=20 >> solve specific problems. >>=20 >> Likewise, I think we need the "ping" mechanism in places where the=20 >> other two would not provide the desired device status information. We=20 >> would not need keep or overload between some devices. > >I don't *in principle* have a problem with treating these as separate thin= gs. But then we must ensure that they don't have unintended >(negative) interactions. That should be managed by careful scoping and by = ensuring that they take account of one another. > >Christer indicated that there was a previous decision to include proxy-pro= xy keep-alives in the -keep draft. Christer - do you know where that decisi= on might be documented? The existing goal list is very=20 >vague on this. I haven't checked the meeting minutes, but the use-case was in the slides I= presented at the Dublin meeting. Regards, Christer From rjsparks@nostrum.com Tue Apr 20 12:53:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A76528C1D4 for ; Tue, 20 Apr 2010 12:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-yq2U8rKOpB for ; Tue, 20 Apr 2010 12:53:28 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 4FE7A3A6A15 for ; Tue, 20 Apr 2010 12:53:28 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-51-142.dllstx.fios.verizon.net [173.71.51.142]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3KJphMi095322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Apr 2010 14:53:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-13--719262017 Date: Tue, 20 Apr 2010 14:53:17 -0500 References: To: SIPCORE Message-Id: <14EF82F1-1369-45F8-A303-AB207341DD2C@nostrum.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 173.71.51.142 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: Registration closes in 10 days (Re: [RAI] SIPit26 registration is open) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 19:53:29 -0000 --Apple-Mail-13--719262017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii fyi Begin forwarded message: > From: Robert Sparks > Date: April 20, 2010 2:52:43 PM CDT > To: rai@ietf.org > Subject: Registration closes in 10 days (Re: [RAI] SIPit26 = registration is open) >=20 > Registration closes May 1. If you are planning to attend and have not = yet registered, please do so soon. >=20 > RjS >=20 > On Mar 16, 2010, at 11:15 AM, Robert Sparks wrote: >=20 >> SIPit 26 will be held in Kista - the telecom valley outside = Stockholm, Sweden on May 17-21, 2010. The event is hosted by Edvina and = TANDBERG and sponsored by Ingate, Intertex and .se. >>=20 >> See and for details = and to register. >>=20 >> RjS >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai >=20 --Apple-Mail-13--719262017 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Robert Sparks = <rjsparks@nostrum.com>
Date: April 20, 2010 = 2:52:43 PM CDT
Subject: Registration = closes in 10 days (Re: [RAI] SIPit26 registration is = open)

Registration closes May 1. If you are = planning to attend and have not yet registered, please do so = soon.

RjS

On Mar 16, 2010, at 11:15 AM, Robert Sparks = wrote:

SIPit 26 will be held in Kista - = the telecom valley outside Stockholm, Sweden on May 17-21, 2010. The = event is hosted by Edvina and TANDBERG and sponsored by Ingate, Intertex = and .se.

See <http://www.sipit.net> and <http://sipit.edvina.se> for = details and to register.

RjS
_______________________________________________
RAI mailing = list
RAI@ietf.org
https://www.ietf.org/ma= ilman/listinfo/rai


= --Apple-Mail-13--719262017-- From mlm.michael.miller@gmail.com Wed Apr 21 07:38:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881163A6AA9 for ; Wed, 21 Apr 2010 07:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDGN4f13Po3a for ; Wed, 21 Apr 2010 07:38:08 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 853C53A6C78 for ; Wed, 21 Apr 2010 07:08:04 -0700 (PDT) Received: by bwz25 with SMTP id 25so8185443bwz.28 for ; Wed, 21 Apr 2010 07:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=BTNgm8HTqHxn4NH735Kgr5upAKHusMCk08Av/SNCgyI=; b=f4EIY4Z4c4paTyoBVA4SsNvVAAPeoJDhos0z9JSG8eqagK0xuH2Nud+FS7fryjlWRK T2jbdb+3U2ooRTVelxCtdWYnRPVFPb3T2MyUSrzF7aQAdsRdYYm/uKLLXzys+o03DBfK PmT9n7Fxoffpnm+k0S9CiY4rFiIuEbU/qhYdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LtNpv1ekOjBpURUrG70aYzSk48ob7u9eYEbFIdLz4+vnOSBydt+q7jAPjtv77vuAve uth6sseGsZ0k/z2tLK8+VmQr6JAIjSa3y2u2vIryD+fnaSEuuZ7PgrBRl74YlI/osat+ w6NEy3JedYzETDs4uz8ErJWBtxqY3p4K/vTi4= MIME-Version: 1.0 Received: by 10.204.50.201 with HTTP; Wed, 21 Apr 2010 07:07:49 -0700 (PDT) Date: Wed, 21 Apr 2010 10:07:49 -0400 Received: by 10.204.7.194 with SMTP id e2mr73762bke.103.1271858869997; Wed, 21 Apr 2010 07:07:49 -0700 (PDT) Message-ID: From: Michael Miller To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=0015174c1b362691ac0484bfb838 Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 14:38:09 -0000 --0015174c1b362691ac0484bfb838 Content-Type: text/plain; charset=ISO-8859-1 > Hi, > > >>> People can correct me if I'm wrong - my impression is that the > >>> *intent* of the keep stuff and the options ping stuff is different, > >>> at least in emphasis. I am thinking the focus of keep is on keeping > >>> nat pinholes open, while the focus of options ping is on > >>> determination of which neighbors are up/down. > >> > >> That's also my understanding. > >> > >>> But each may be suitable for the other purpose itself. So there is > >>> overlap, at least in the eyes of some. > >>> > >>> And of course there is also some perceived overlap between detecting > >>> neighbors that are down and overload control. > >>> > >>> So to an extent its a matter of whether to characterize this ping > >>> work as part of one of those other charters, or as something > >>> independent of them. What is your take on that? > >> > >> I fully agree that the OPTIONS "ping" can be viewed as overlapping > >> with the other two drafts. > >> > >> As you know, it was not the intent of the "ping" mechanism to serve as > >> an overload mechanism, nor was it intended as a means of keeping > pinholes open. > >> > >> I think both the keep and overload work is needed, as they work to > >> solve specific problems. > >> > >> Likewise, I think we need the "ping" mechanism in places where the > >> other two would not provide the desired device status information. We > >> would not need keep or overload between some devices. > > > >I don't *in principle* have a problem with treating these as separate > things. But then we must ensure that they don't have unintended > >(negative) interactions. That should be managed by careful scoping and by > ensuring that they take account of one another. > > > >Christer indicated that there was a previous decision to include > proxy-proxy keep-alives in the -keep draft. Christer - do you know where > that decision might be documented? The existing goal list is very > >vague on this. > > I haven't checked the meeting minutes, but the use-case was in the slides I > presented at the Dublin meeting. > > Regards, > > Christer > Hi, I'm new to this process, so please be patience with me. The draft looks good and I just want to make sure of a couple points: 1-We have endpoints that require Notify or Invite to be used for this ping. I think by saying use the method OPTIONS I am hoping that is the only way to perform this function. 2-Should we come up with a recommend (or default value) to be used on how often we should send. Concerns is that some devices may not reply back if they get so many in a 30 second period (for an example). Michael Miller Global Crossing. > > --0015174c1b362691ac0484bfb838 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

>>> People can correct me if I'm wrong - my impression is that= the
>>> *intent* of the keep stuff and the options ping stuff is diffe= rent,
>>> at least in emphasis. I am thinking the focus of keep is on ke= eping
>>> nat pinholes open, while the focus of options ping is on
>>> determination of which neighbors are up/down.
>>
>> That's also my understanding.
>>
>>> But each may be suitable for the other purpose itself. So ther= e is
>>> overlap, at least in the eyes of some.
>>>
>>> And of course there is also some perceived overlap between det= ecting
>>> neighbors that are down and overload control.
>>>
>>> So to an extent its a matter of whether to characterize this p= ing
>>> work as part of one of those other charters, or as something >>> independent of them. What is your take on that?
>>
>> I fully agree that the OPTIONS "ping" can be viewed as o= verlapping
>> with the other two drafts.
>>
>> As you know, it was not the intent of the "ping" mechani= sm to serve as
>> an overload mechanism, nor was it intended as a means of keeping p= inholes open.
>>
>> I think both the keep and overload work is needed, as they work to=
>> solve specific problems.
>>
>> Likewise, I think we need the "ping" mechanism in places= where the
>> other two would not provide the desired device status information.= =A0We
>> would not need keep or overload between some devices.
>
>I don't *in principle* have a problem with treating these as separa= te things. But then we must ensure that they don't have unintended
>(negative) interactions. That should be managed by careful scoping and = by ensuring that they take account of one another.
>
>Christer indicated that there was a previous decision to include proxy-= proxy keep-alives in the -keep draft. Christer - do you know where that dec= ision might be documented? The existing goal list is very
>vague on this.

I haven't checked the meeting minutes, but the use-case was in the slid= es I presented at the Dublin meeting.

Regards,

Christer

Hi, I'm new to this process, so pleas= e be patience with me.

The draft looks good and I just want to make = sure of a couple points:
1-We have endpoints that require Notify or Invi= te to be used for this ping.=A0 I think by saying use the method OPTIONS I = am hoping that is the only way to perform this function.
2-Should we come up with a recommend (or default value) to be used on how o= ften we should send.=A0 Concerns is that some devices may not reply back if= they get so many in a 30 second period (for an example).

Michael Mi= ller
Global Crossing.
=A0


--0015174c1b362691ac0484bfb838-- From rbarnes@bbn.com Thu Apr 22 12:24:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B7F3A69E3 for ; Thu, 22 Apr 2010 12:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMNEm3ebyt+r for ; Thu, 22 Apr 2010 12:24:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DAF473A6A82 for ; Thu, 22 Apr 2010 12:06:58 -0700 (PDT) Received: from [192.1.255.202] (port=54249 helo=col-dhcp-192-1-255-202.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O51jc-000BUJ-7I for sipcore@ietf.org; Thu, 22 Apr 2010 15:06:48 -0400 Message-Id: <0F2ED3DB-B6B1-40A8-96E2-8F149F984AA5@bbn.com> From: Richard Barnes To: sipcore@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Apr 2010 15:06:47 -0400 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Announcement: Emergency Services Workshop 7 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:24:51 -0000 Dear colleagues, We're pleased to announce that registration is open for the seventh Emergency Services Workshop, to be held 11-13 May 2010, at the University of Maryland, in College Park, MD, USA. A registration link, as well as agenda and travel information, can be found on the ESW website: We invite talks of 30-60 minutes on topics related to IP emergency services, especially around the following topics: -- Standards development activities related to emergency communications -- Prototypes of standards-based IP emergency services -- Internet-based authority-to-citizen alerts and early warning -- Automatic IP geolocation technologies and deployment considerations -- Implementation and deployment of IP-based emergency calling systems Please send proposals for presentations to . Background: The Emergency Services Workshop series is an ongoing effort in the emergency services community to coordinate global standards and technologies for emergency calling and emergency notification. The primary focus of the workshop series is foster coordination among the many standards development organizations (SDOs) involved in emergency services as they all work toward a global solution for emergency communications using Internet technologies. In addition, the workshops try to bring in operational and regulatory perspectives on emergency services, so that these experiences and requirements can be incorporated into ongoing technical development processes. Participation is open all stakeholders in the emergency communications system, including industry (e.g., equipment vendors or telecommunications companies) as well as government (e.g., regulatory bodies or emergency response organizations). Thanks for your interest, The ESW Coordination Team From paulej@packetizer.com Fri Apr 23 08:49:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E863A6A4A for ; Fri, 23 Apr 2010 08:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSW1OInyE1J4 for ; Fri, 23 Apr 2010 08:48:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 5091F3A6972 for ; Fri, 23 Apr 2010 08:48:58 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3NFmclJ001753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Apr 2010 11:48:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272037724; bh=PgYOveGB0bNUkUqhe70AXGlbF5Y5nKgmgzCL0q+bG/E=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=AeKQ7d6Xx/iFzO4dZBSzOFp4oDueesQtlSWEf5oQEFLa9ua+R2fM6SrRIMzPMWUlS sdJnMFqURa8ca4iQ9PXFL6R9aEAq6i4F1s2Ewfok8ZF+QXvc1EYrpS6OIHfQVxjHBm 0pUre+STsuGLGmidMrFRZ9LwDjOBPhrx4zOmzwCg= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3NFmcuK025673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Apr 2010 11:48:38 -0400 From: "Paul E. Jones" To: "'Michael Miller'" , References: In-Reply-To: Date: Fri, 23 Apr 2010 11:48:16 -0400 Message-ID: <02a301cae2fc$639733d0$2ac59b70$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A4_01CAE2DA.DC8593D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhYEQnG1hxN/bkR5u99urZQgoQ/gBmDOSg Content-Language: en-us Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:49:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02A4_01CAE2DA.DC8593D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael, It was our intent to recommend use of OPTIONS only for "ping". The very fact you've got a couple of implementations that use different messages for the same purpose is evidence that we need to settle on one way. Having multiple ways to do this is clearly not in the best interest of customers. As for the frequency of sending messages, I'm torn on this one. I've heard numbers that vary considerably. Since this is something done between devices that have some kind of relationship, I'd prefer to let the frequency be determined by administrators. That is what we put in Section 7. However, if there are strong preferences to recommend an interval, I'll change it. But, I think we could only recommend something, not require it. Paul From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Michael Miller Sent: Wednesday, April 21, 2010 10:08 AM To: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Hi, >>> People can correct me if I'm wrong - my impression is that the >>> *intent* of the keep stuff and the options ping stuff is different, >>> at least in emphasis. I am thinking the focus of keep is on keeping >>> nat pinholes open, while the focus of options ping is on >>> determination of which neighbors are up/down. >> >> That's also my understanding. >> >>> But each may be suitable for the other purpose itself. So there is >>> overlap, at least in the eyes of some. >>> >>> And of course there is also some perceived overlap between detecting >>> neighbors that are down and overload control. >>> >>> So to an extent its a matter of whether to characterize this ping >>> work as part of one of those other charters, or as something >>> independent of them. What is your take on that? >> >> I fully agree that the OPTIONS "ping" can be viewed as overlapping >> with the other two drafts. >> >> As you know, it was not the intent of the "ping" mechanism to serve as >> an overload mechanism, nor was it intended as a means of keeping pinholes open. >> >> I think both the keep and overload work is needed, as they work to >> solve specific problems. >> >> Likewise, I think we need the "ping" mechanism in places where the >> other two would not provide the desired device status information. We >> would not need keep or overload between some devices. > >I don't *in principle* have a problem with treating these as separate things. But then we must ensure that they don't have unintended >(negative) interactions. That should be managed by careful scoping and by ensuring that they take account of one another. > >Christer indicated that there was a previous decision to include proxy-proxy keep-alives in the -keep draft. Christer - do you know where that decision might be documented? The existing goal list is very >vague on this. I haven't checked the meeting minutes, but the use-case was in the slides I presented at the Dublin meeting. Regards, Christer Hi, I'm new to this process, so please be patience with me. The draft looks good and I just want to make sure of a couple points: 1-We have endpoints that require Notify or Invite to be used for this ping. I think by saying use the method OPTIONS I am hoping that is the only way to perform this function. 2-Should we come up with a recommend (or default value) to be used on how often we should send. Concerns is that some devices may not reply back if they get so many in a 30 second period (for an example). Michael Miller Global Crossing. ------=_NextPart_000_02A4_01CAE2DA.DC8593D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

 

It was our intent to recommend use of OPTIONS only for = “ping”.  The very fact you’ve got a couple of implementations that use = different messages for the same purpose is evidence that we need to settle on one way.  Having multiple ways to do this is clearly not in the best = interest of customers.

 

As for the frequency of sending messages, I’m torn = on this one.  I’ve heard numbers that vary considerably.  Since = this is something done between devices that have some kind of relationship, = I’d prefer to let the frequency be determined by administrators.  That = is what we put in Section 7.  However, if there are strong preferences to recommend an interval, I’ll change it.  But, I think we could = only recommend something, not require it.

 

Paul

 

From:= sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Michael Miller
Sent: Wednesday, April 21, 2010 10:08 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] FW: I-D = Action:draft-jones-sip-options-ping-00.txt

 

 

Hi,

>>> People can correct me if I'm wrong - my impression is that = the
>>> *intent* of the keep stuff and the options ping stuff is different,
>>> at least in emphasis. I am thinking the focus of keep is on keeping
>>> nat pinholes open, while the focus of options ping is = on
>>> determination of which neighbors are up/down.
>>
>> That's also my understanding.
>>
>>> But each may be suitable for the other purpose itself. So = there is
>>> overlap, at least in the eyes of some.
>>>
>>> And of course there is also some perceived overlap between detecting
>>> neighbors that are down and overload control.
>>>
>>> So to an extent its a matter of whether to characterize = this ping
>>> work as part of one of those other charters, or as = something
>>> independent of them. What is your take on that?
>>
>> I fully agree that the OPTIONS "ping" can be viewed = as overlapping
>> with the other two drafts.
>>
>> As you know, it was not the intent of the "ping" = mechanism to serve as
>> an overload mechanism, nor was it intended as a means of = keeping pinholes open.
>>
>> I think both the keep and overload work is needed, as they work = to
>> solve specific problems.
>>
>> Likewise, I think we need the "ping" mechanism in = places where the
>> other two would not provide the desired device status = information.  We
>> would not need keep or overload between some devices.
>
>I don't *in principle* have a problem with treating these as = separate things. But then we must ensure that they don't have unintended
>(negative) interactions. That should be managed by careful scoping = and by ensuring that they take account of one another.
>
>Christer indicated that there was a previous decision to include proxy-proxy keep-alives in the -keep draft. Christer - do you know where = that decision might be documented? The existing goal list is very
>vague on this.

I haven't checked the meeting minutes, but the use-case was in the = slides I presented at the Dublin meeting.

Regards,

Christer


Hi, I'm new to this process, so please be patience with me.

The draft looks good and I just want to make sure of a couple = points:
1-We have endpoints that require Notify or Invite to be used for this ping.  I think by saying use the method OPTIONS I am hoping that is = the only way to perform this function.
2-Should we come up with a recommend (or default value) to be used on = how often we should send.  Concerns is that some devices may not reply back = if they get so many in a 30 second period (for an example).

Michael Miller
Global Crossing.
 

 

 

------=_NextPart_000_02A4_01CAE2DA.DC8593D0-- From dean.willis@softarmor.com Fri Apr 23 09:26:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03F93A69F7 for ; Fri, 23 Apr 2010 09:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIXo6Z2mbam4 for ; Fri, 23 Apr 2010 09:26:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5D4F93A69EC for ; Fri, 23 Apr 2010 09:25:53 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3NGPbSl024201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Apr 2010 11:25:39 -0500 Message-Id: <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> From: Dean Willis To: "Paul E. Jones" In-Reply-To: <02a301cae2fc$639733d0$2ac59b70$@com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Apr 2010 11:25:32 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> X-Mailer: Apple Mail (2.936) Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 16:26:46 -0000 On Apr 23, 2010, at 10:48 AM, Paul E. Jones wrote: > Michael, > > It was our intent to recommend use of OPTIONS only for =93ping=94. = The =20 > very fact you=92ve got a couple of implementations that use different =20= > messages for the same purpose is evidence that we need to settle on =20= > one way. Having multiple ways to do this is clearly not in the best =20= > interest of customers. There's probably been some discussion of this that has just slipped =20 out of my head, but we may wish to consider that OPTIONS gets =20 "heavier" with every additional SIP extension. Eventually, it'll get =20 too big for UDP, and become fairly useless for pinging. Factor in that some people seem to be implementing OPTIONS to provide =20= a different answer based on "who's asking", and we add the overhead of =20= (optionally) authenticating the request, making an options-selection =20= based on what the requester is authorized to see, and then formulating =20= the specific reply. Two alternatives suggest themselves to me: 1) Defining a new method, like PING, specifically constructed to have =20= no semantic other than "Are you there?" 2) Holding open a long-lived dialog with the node you are "pinging" =20 and using keepalive (and or session-timer) to make sure it's still =20 there. At least this lets the AAA process happen only once (for some =20 values of authentication) and lets us reuse a long-lived TCP (or TLS) =20= connection if appropriate. I somewhat prefer the second; it has better backward-compatibility, =20 and helps discomfit all those people I've been telling not to bill =20 based on INVITE/BYE for so long. -- Dean= From paulej@packetizer.com Fri Apr 23 09:59:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2333A6A21 for ; Fri, 23 Apr 2010 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xuJz9BDjuS4 for ; Fri, 23 Apr 2010 09:59:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 0D74F3A6945 for ; Fri, 23 Apr 2010 09:59:43 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3NGxOZZ005010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Apr 2010 12:59:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272041970; bh=wpOB3jYAdgGam5hEWmKCCGbrGYsToMkl62VflHg5enI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RtQynOkSiLL6WyDWq/zFNyIWQPLkkolpSYzG/5nyT6y7Dh5q91K8LWxSbomdsP9lm 1F2pD9Ky9akcs0e0CLgrEAQ41gHp8Tk+/bUgJNdP/8e3zxS5Z2wleSr7/YaxNawbqV 8yz7zpTVVyIJMwlcpX8IdVFmL1qpcz7t/lOkMjDA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3NGxMRB025847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Apr 2010 12:59:22 -0400 From: "Paul E. Jones" To: "'Dean Willis'" References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> In-Reply-To: <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> Date: Fri, 23 Apr 2010 12:59:01 -0400 Message-ID: <02c001cae306$45e49e40$d1addac0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrjAaLXy55LPAnlQ/yYCr/vgxjs3wAAGGgw Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 16:59:47 -0000 Dean, > Factor in that some people seem to be implementing OPTIONS to provide > a different answer based on "who's asking", and we add the overhead of > (optionally) authenticating the request, making an options-selection > based on what the requester is authorized to see, and then formulating > the specific reply. Your concerns are valid, but devices implementing a "ping" know they're doing that, and would not have to fatten the OPTIONS message. They also would not need to authenticate the request, either. At a minimal, they respond in all cases, and as one step toward "security" (if the "ping" needed it), one could employ an ACL. > 1) Defining a new method, like PING, specifically constructed to have > no semantic other than "Are you there?" >From an architectural purity perspective, I like this. The problem is that it requires changes to every stack in the field. It also means we have one more way to do "ping", since I suspect people will continue to use OPTIONS. There was also a suggestion to have a tag to indicate that the OPTIONS is for "ping", though I think the Request URI could serve the same purpose. One should not ping sip:paulej@packetizer.com, while one might ping sip:192.168.1.10 or sip:ping@192.168.1.10 and the responding entity should formulate a reasonable (non-heavy) reply. > 2) Holding open a long-lived dialog with the node you are "pinging" > and using keepalive (and or session-timer) to make sure it's still > there. At least this lets the AAA process happen only once (for some > values of authentication) and lets us reuse a long-lived TCP (or TLS) > connection if appropriate. This likewise requires a bit of change on most devices to understand that such sessions are "ping" sessions. It also requires a bit more state management on both devices. It's not horrible, but not nearly as light-weight as sending an OPTIONS "ping" every now and then. Further, consider that sending a "ping" is not really necessary for devices that know (through other means) that the peer device is alive (e.g., active dialogs starting/stopping). This approach would not benefit from that. > I somewhat prefer the second; it has better backward-compatibility, > and helps discomfit all those people I've been telling not to bill > based on INVITE/BYE for so long. Billing? We don't need no stinkin' bills ;-) Obviously, I'm partial to the OOD OPTIONS "ping" method. It's fairly widely (albeit inconsistently) implemented. Other options seem to require more work in terms of specification and implementation. Paul From HKaplan@acmepacket.com Fri Apr 23 10:06:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0532B3A6A00 for ; Fri, 23 Apr 2010 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VCNENvRtQFL for ; Fri, 23 Apr 2010 10:06:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 14ED03A6829 for ; Fri, 23 Apr 2010 10:06:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Apr 2010 13:06:06 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Apr 2010 13:06:06 -0400 From: Hadriel Kaplan To: Dean Willis , "Paul E. Jones" Date: Fri, 23 Apr 2010 13:05:31 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjB0KZN94JM2VhTkWH9c5+J41Egw== Message-ID: <01cbq5rbnyfl3h2332oh1w6g.1272041943239@email.android.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 17:06:20 -0000 SSB0aGluayBpZiB3ZSBqdXN0IGFncmVlIG9uIGEgY29tbW9uIGV4cGxpY2l0IHRhcmdldCB1c2Vy bmFtZSwgdGhlbiBhbGwgdGhvc2UgaXNzdWVzIGFyZSBhdm9pZGVkLiAgV2UnZCBqdXN0IHNwZWNp ZnkgdGhlIHVzZXIgaWRlbnRpZmllcyBhIGxvZ2ljYWwgVUEgaW4gdGhlIHByb3h5L3doYXRldmVy LCB3aGljaCBpcyBvbmx5IHRoZXJlIGZvciBwaW5naW5nLiAgVGhlIHB1cnBvc2Ugb2YgdGhlIHJl cXVlc3Qgd291bGQgdGh1cyBiZSBleHBsaWNpdC4KCkFuZCB0aGVyZSdzIG5vIHBvaW50IGluIGF1 dGhlbnRpY2F0aW5nLCBzaW5jZSB0aGUgNDAxIGl0c2VsZiBpcyBhIHJlc3BvbnNlLCBhbmQgYmVz aWRlcyB0aGUgaW5mb3JtYXRpb24gcmV0dXJuZWQgaXMgYmVuaWduLg== From victor.pascual.avila@gmail.com Fri Apr 23 10:26:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA943A6A96 for ; Fri, 23 Apr 2010 10:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK4vItsLaY1m for ; Fri, 23 Apr 2010 10:26:26 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id C90343A6A95 for ; Fri, 23 Apr 2010 10:26:25 -0700 (PDT) Received: by bwz25 with SMTP id 25so11498371bwz.28 for ; Fri, 23 Apr 2010 10:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gJ31Pgg1ciDBvWIYbWjVSSpSBzNX83OfloDx4ZkFLSc=; b=sB7BkIlSfBry0prEl6ZDqHNrcXbzx8dqrWakDpE3o+m8lFIy9y11TOdPZmDvymEx71 BpHWiUmb+vHGULHF6iK56mXCv6bS57o+3BTBCLYzlb86sWfnxVY/ZfWLsxuOikfmIIA2 cQjHukdbTr4KssR1IqJ4UbjIQklbNVCd316nU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mngr4UqNVVX6oLitJpY0T0T5tKGQPzxvIYNAKkEGhS6AP8V1fjofgQ2IopPkH3Zlfm 2jVwvp6rdkDKt7SvGYR9o6u+20apUatlc4cE/xCnTitSnrg7/D+bIGyVdpDzOPQlFeF5 8ep01rhr/LYQAMD9GrDLhnJRILnAA8IPf3nZ4= MIME-Version: 1.0 Received: by 10.204.32.77 with SMTP id b13mr207587bkd.113.1272043571801; Fri, 23 Apr 2010 10:26:11 -0700 (PDT) Received: by 10.204.66.73 with HTTP; Fri, 23 Apr 2010 10:26:11 -0700 (PDT) In-Reply-To: <01cbq5rbnyfl3h2332oh1w6g.1272041943239@email.android.com> References: <01cbq5rbnyfl3h2332oh1w6g.1272041943239@email.android.com> Date: Fri, 23 Apr 2010 19:26:11 +0200 Message-ID: From: Victor Pascual Avila To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Miller , "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 17:26:27 -0000 Dumb question: if nodes A and B were exchanging traffic over both UDP and TCP, should they exchange "PING" messages for/over every transport? -Victor On Fri, Apr 23, 2010 at 7:05 PM, Hadriel Kaplan wr= ote: > I think if we just agree on a common explicit target username, then all t= hose issues are avoided. =C2=A0We'd just specify the user identifies a logi= cal UA in the proxy/whatever, which is only there for pinging. =C2=A0The pu= rpose of the request would thus be explicit. > > And there's no point in authenticating, since the 401 itself is a respons= e, and besides the information returned is benign. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --=20 Victor Pascual =C3=81vila From pkyzivat@cisco.com Fri Apr 23 10:28:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FBC3A698B for ; Fri, 23 Apr 2010 10:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.045 X-Spam-Level: X-Spam-Status: No, score=-10.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpeQeAPq8Lzc for ; Fri, 23 Apr 2010 10:28:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A52EE3A693E for ; Fri, 23 Apr 2010 10:28:04 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAZ10UtAZnwN/2dsb2JhbACcKnGkEJorhQsE X-IronPort-AV: E=Sophos;i="4.52,262,1270425600"; d="scan'208";a="104600917" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2010 17:27:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3NHRrx6022947; Fri, 23 Apr 2010 17:27:53 GMT Message-ID: <4BD1D895.8030900@cisco.com> Date: Fri, 23 Apr 2010 13:27:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> In-Reply-To: <02c001cae306$45e49e40$d1addac0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 17:28:06 -0000 [ as individual ] Paul E. Jones wrote: > Dean, > >> Factor in that some people seem to be implementing OPTIONS to provide >> a different answer based on "who's asking", and we add the overhead of >> (optionally) authenticating the request, making an options-selection >> based on what the requester is authorized to see, and then formulating >> the specific reply. > > Your concerns are valid, but devices implementing a "ping" know they're > doing that, and would not have to fatten the OPTIONS message. They also > would not need to authenticate the request, either. At a minimal, they > respond in all cases, and as one step toward "security" (if the "ping" > needed it), one could employ an ACL. ... > There was also a suggestion to have a tag to indicate that the OPTIONS is > for "ping", though I think the Request URI could serve the same purpose. One > should not ping sip:paulej@packetizer.com, while one might ping > sip:192.168.1.10 or sip:ping@192.168.1.10 and the responding entity should > formulate a reasonable (non-heavy) reply. I'm bothered by this - it makes too many assumptions about usage. The *sender* knows when the options is a ping and when it is not, but the recipient doesn't. Making a decision based on the form of the R-URI presumes that non-ping users of options never use an ip address as the R-URI. Requiring the R-URI to be ping@ip reserves a user part, and also is just a sleazy way of adding another indicator to the message to indicate its intended use. One possibility would be to use an option tag: Required:ping. That would ensure the other party knows this is a ping. (And of course if that fails you could remove the tag, and realize you were not getting a specialized ping implementation.) But that itself requires parsing the message enough to recognize the option tag. I know of at least one implementation that optimizes OPTIONS deep in the stack - replying immediately without ever passing it to the applications layer, and without parsing much of the message. But it depends on knowing its in an environment where that is acceptable. I'd certainly like to see the pros/cons debated thoroughly. Thanks, Paul From paulej@packetizer.com Fri Apr 23 11:00:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3AD3A6A28 for ; Fri, 23 Apr 2010 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZOBTWiL1v2i for ; Fri, 23 Apr 2010 11:00:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 9858A3A6AA0 for ; Fri, 23 Apr 2010 11:00:16 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3NHxsMf007622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Apr 2010 14:00:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272045600; bh=HG9ECiX9S24efzoc25pdVOF5TzolBjefm+dc8scCarM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=szNYA6x2EDB93gjkqUfLzUTib/MATJYUo90GdAPalEY77Pnwz9OpNpFo3vCztgcAb MquvJNGvrZ1Ojztff/uN9z85+ZceuwchhcoTSKQfag3ZP2i+OeZlhzHacAzYIJAto2 GAM/FMmWt+qYsUYjikhLvA9x7vkYFfiDXAiNkqoA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3NHxr6D026090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Apr 2010 13:59:53 -0400 From: "Paul E. Jones" To: "'Victor Pascual Avila'" , "'Hadriel Kaplan'" References: <01cbq5rbnyfl3h2332oh1w6g.1272041943239@email.android.com> In-Reply-To: Date: Fri, 23 Apr 2010 13:59:32 -0400 Message-ID: <02cf01cae30e$ba0668f0$2e133ad0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrjChoRew26dBgHTj+/8xZ0GRq0HgABH/4Q Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 18:00:22 -0000 Victor, I suppose they could, but I wouldn't. I'd configure the use of whatever = transport made sense to ping the peer device, which might include = Henry's infamous carrier pigeon. Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Victor Pascual Avila > Sent: Friday, April 23, 2010 1:26 PM > To: Hadriel Kaplan > Cc: Michael Miller; Paul E. Jones; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt >=20 > Dumb question: if nodes A and B were exchanging traffic over both UDP > and TCP, should they exchange "PING" messages for/over every > transport? >=20 > -Victor >=20 > On Fri, Apr 23, 2010 at 7:05 PM, Hadriel Kaplan > wrote: > > I think if we just agree on a common explicit target username, then > all those issues are avoided. We'd just specify the user identifies a > logical UA in the proxy/whatever, which is only there for pinging. = The > purpose of the request would thus be explicit. > > > > And there's no point in authenticating, since the 401 itself is a > response, and besides the information returned is benign. > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 >=20 >=20 > -- > Victor Pascual =C3=81vila > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Fri Apr 23 11:55:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65D83A6AB2 for ; Fri, 23 Apr 2010 11:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgJ53J8uVNaf for ; Fri, 23 Apr 2010 11:55:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D25DC3A681D for ; Fri, 23 Apr 2010 11:55:26 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3NItBDd025385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Apr 2010 13:55:13 -0500 Message-Id: <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BD1D895.8030900@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Apr 2010 13:55:06 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , sipcore@ietf.org, 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 18:55:27 -0000 On Apr 23, 2010, at 12:27 PM, Paul Kyzivat wrote: > > One possibility would be to use an option tag: Required:ping. That > would ensure the other party knows this is a ping. (And of course if > that fails you could remove the tag, and realize you were not > getting a specialized ping implementation.) > Nah, that just requires somebody to support the ping extension; it doesn't tell them to apply that extension to this OPTIONS request. > But that itself requires parsing the message enough to recognize the > option tag. I know of at least one implementation that optimizes > OPTIONS deep in the stack - replying immediately without ever > passing it to the applications layer, and without parsing much of > the message. But it depends on knowing its in an environment where > that is acceptable. How does the implementation know which options are supported at the application level? It probably doesn't, and is sending a arong options- set in the response. -- Dean From dean.willis@softarmor.com Fri Apr 23 11:59:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0733A6ABF for ; Fri, 23 Apr 2010 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESLbwVXf+Itf for ; Fri, 23 Apr 2010 11:59:58 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6A6193A6ABD for ; Fri, 23 Apr 2010 11:59:57 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3NIxjGN025419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 23 Apr 2010 13:59:46 -0500 Message-Id: <38E85A90-BCC1-4643-906B-4DA78D65A73F@softarmor.com> From: Dean Willis To: sipcore@ietf.org In-Reply-To: <20100423132754.91575E07CC@rfc-editor.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Apr 2010 13:59:40 -0500 References: <20100423132754.91575E07CC@rfc-editor.org> X-Mailer: Apple Mail (2.936) Subject: [sipcore] Discussion on Table 2 relative to RFC3329 errata (2170) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 18:59:59 -0000 On Apr 23, 2010, at 8:27 AM, RFC Errata System wrote: > > > Original Text > ------------- > The second INVITE (4) and the ACK (8) contain a Security-Verify > header field that mirrors the Security-Server header field received > in the 421. > > Corrected Text > -------------- > The second INVITE (4) contains a Security-Verify > header field that mirrors the Security-Server header field received > in the 421. > > Notes > ----- > RFC 3329 Section 2.6, Table 1: Summary of Header Usage. indicates > that Security-Client, Security-Server, Security-Verify are "Not > applicable" to the SIP ACK request. > > RFC 3261 says "Not applicable" means that the header field MUST NOT > be present in a request. If one is placed in a request by mistake, > it MUST be ignored by the UAS receiving the request." > We've been discussing the role of Table 2. Here, said table (as modified by the RFC in question) is being viewed as authoritative on the inclusion of Security-Verify in the examples used by that RFC. Clearly, we have a mismatch between the specification and its table 2 modification. Is Table 2 here helping us catch spec errors, or is it just confusing the specification writer? -- dean From pkyzivat@cisco.com Fri Apr 23 12:25:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0E43A691A for ; Fri, 23 Apr 2010 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.044 X-Spam-Level: X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z90tSaKl3ERf for ; Fri, 23 Apr 2010 12:25:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E85823A6ACC for ; Fri, 23 Apr 2010 12:25:44 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACaR0UtAZnwN/2dsb2JhbACcLHGkTJoshQsE X-IronPort-AV: E=Sophos;i="4.52,263,1270425600"; d="scan'208";a="104641376" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2010 19:25:34 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3NJPXS3009073; Fri, 23 Apr 2010 19:25:33 GMT Message-ID: <4BD1F428.2030108@cisco.com> Date: Fri, 23 Apr 2010 15:25:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> In-Reply-To: <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , sipcore@ietf.org, 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 19:25:51 -0000 Dean, OK, you caught me falling into that trap too. :-( In any case, once you are going to mandate something new, it doesn't matter much whether it is an option tag or a method. Either way you have to implement something new. Similarly, if you mandate that a particular R-URI format is to be treated differently, that also is something new to implement. The *advantage* of OPTIONS is that it can be used as a ping without the recipient having any knowledge that is the purpose. But if it is unsuitable for use with those that don't understand ping as something special, then it has no advantage. I guess the argument remains that if you use some special form of ping that will still work for the clueless, but which can be optimized by the clueful, then you have the best of both worlds. For that to work well, the discriminator should be something that is certain not to cause trouble for the clueless, and that doesn't limit the clueful who also use OPTIONS for non-ping purposes. I think that rules out R-URI values. But it could include new header fields. Note that you have to implement *something* new in the UAS if you want to optimize pings. So implementing a new header should not be a big deal. Thanks, Paul Dean Willis wrote: > > On Apr 23, 2010, at 12:27 PM, Paul Kyzivat wrote: > >> >> One possibility would be to use an option tag: Required:ping. That >> would ensure the other party knows this is a ping. (And of course if >> that fails you could remove the tag, and realize you were not getting >> a specialized ping implementation.) >> > > > Nah, that just requires somebody to support the ping extension; it > doesn't tell them to apply that extension to this OPTIONS request. > >> But that itself requires parsing the message enough to recognize the >> option tag. I know of at least one implementation that optimizes >> OPTIONS deep in the stack - replying immediately without ever passing >> it to the applications layer, and without parsing much of the message. >> But it depends on knowing its in an environment where that is acceptable. > > How does the implementation know which options are supported at the > application level? It probably doesn't, and is sending a arong > options-set in the response. > > -- > Dean > > From christer.holmberg@ericsson.com Fri Apr 23 14:56:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7563A6898 for ; Fri, 23 Apr 2010 14:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak4E-h-WIJ1G for ; Fri, 23 Apr 2010 14:56:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4734E3A68AF for ; Fri, 23 Apr 2010 14:56:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-6c-4bd217890abb Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 1E.16.23532.98712DB4; Fri, 23 Apr 2010 23:56:25 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 23 Apr 2010 23:56:25 +0200 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Fri, 23 Apr 2010 23:56:24 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjFoZdTnNwR8+PRUiQ1gZAXdzWIAAF4DL8 Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> In-Reply-To: <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 21:56:39 -0000 Hi, >> One possibility would be to use an option tag: Required:ping. That >> would ensure the other party knows this is a ping. (And of course if >> that fails you could remove the tag, and realize you were not >> getting a specialized ping implementation.) > > > >Nah, that just requires somebody to support the ping extension; it >doesn't tell them to apply that extension to this OPTIONS request. I don't think you can make such general assumption. It needs to be specifie= d per option tag. For example, if you receive an INVITE with Require:100rel, you must not onl= y support the extension - you must also use it when sending provisional res= ponses (see RFC3262, section 3, paragraph 2). If you don't think is correct we'd need to update RFC3262. In addition, the scope of an option-tag can be a single transaction, or wid= er.=20 For example, just because I require 100rel in the initial INVITE, it doesn'= t mean (at least that is my understanding) I have implicitly also required = it in each subsequent re-INVITE. The scope of Require:sec-agree, on the other hand, is for the whole session= .=20 Is there ANY option-tag defined, where we specify that Require only means m= ust-support-but-is-not-required-to-use? Anyway, if we move forward with options-ping, I DO think there should be a = way to identify the OPTIONS as a ping, so that the receiver e.g. doens't ne= ed to include all supported capabilities etc in the response - or expect th= em in the request. Regards, Christer= From dean.willis@softarmor.com Fri Apr 23 15:11:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC473A68D5 for ; Fri, 23 Apr 2010 15:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWvgh1ARki3x for ; Fri, 23 Apr 2010 15:11:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E832A3A68C1 for ; Fri, 23 Apr 2010 15:11:03 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3NM9uaW026824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Apr 2010 17:09:58 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Apr 2010 17:09:51 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 22:11:14 -0000 On Apr 23, 2010, at 4:56 PM, Christer Holmberg wrote: > Hi, > >>> One possibility would be to use an option tag: Required:ping. That >>> would ensure the other party knows this is a ping. (And of course if >>> that fails you could remove the tag, and realize you were not >>> getting a specialized ping implementation.) >> >> >> >> Nah, that just requires somebody to support the ping extension; it >> doesn't tell them to apply that extension to this OPTIONS request. > > I don't think you can make such general assumption. It needs to be > specified per option tag. > > For example, if you receive an INVITE with Require:100rel, you must > not only support the extension - you must also use it when sending > provisional responses (see RFC3262, section 3, paragraph 2). > We've had this discussion before: 100rel was badly written in this respect. For example, what do you do if you receive a request that has Require: 100rel but not Supported: 100rel? > If you don't think is correct we'd need to update RFC3262. It's on my list of things to do Someday When I Have The Time. > > In addition, the scope of an option-tag can be a single transaction, > or wider. > > For example, just because I require 100rel in the initial INVITE, it > doesn't mean (at least that is my understanding) I have implicitly > also required it in each subsequent re-INVITE. > > The scope of Require:sec-agree, on the other hand, is for the whole > session. > > Is there ANY option-tag defined, where we specify that Require only > means must-support-but-is-not-required-to-use? Path and Service-Route and answer-mode come to mind. I edited them . . . > > Anyway, if we move forward with options-ping, I DO think there > should be a way to identify the OPTIONS as a ping, so that the > receiver e.g. doens't need to include all supported capabilities etc > in the response - or expect them in the request. Yes, that would be useful. -- Dean From HKaplan@acmepacket.com Fri Apr 23 15:15:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9076B3A6856 for ; Fri, 23 Apr 2010 15:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcu-AC81ZlsY for ; Fri, 23 Apr 2010 15:15:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 74B4F3A696B for ; Fri, 23 Apr 2010 15:15:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Apr 2010 18:14:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Apr 2010 18:14:50 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Paul E. Jones" Date: Fri, 23 Apr 2010 18:14:20 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjCl2tSiYgUbAMQjawrgQptxXx9AAJkQDQ Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> In-Reply-To: <4BD1D895.8030900@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 22:15:15 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: Friday, April 23, 2010 1:28 PM >=20 > Making a decision based on the form of the R-URI presumes that non-ping > users of options never use an ip address as the R-URI. Requiring the > R-URI to be ping@ip reserves a user part, and also is just a sleazy way > of adding another indicator to the message to indicate its intended use. Actually in a weird way I think doing a specific username may be the right = thing to do. Think about it from an email perspective. When you check on = the status and settings of an email list using SMTP, do you (a) send a new = different SMTP message type, or (b) address a normal message to the actual = logical administrative code for the list? You send a normal message to use= rlist-request@emailserver.com. =20 And logically the thing being "pinged" is a higher layer, because the respo= nse provides an administrative status as well. (even though in code one wou= ld probably do this at a low level)=20 Put it another way: in theory you could send a SUBSCRIBE to this logical ad= min-UA in that proxy so that it Notifies you when it goes admin up/down. T= hat logical UA is a resource in the proxy, and could be addressed as such.= =20 -hadriel From pkyzivat@cisco.com Fri Apr 23 15:45:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A491F3A691E for ; Fri, 23 Apr 2010 15:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCzOkEdiiPsq for ; Fri, 23 Apr 2010 15:45:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D56363A6891 for ; Fri, 23 Apr 2010 15:44:59 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANq/0UtAZnwN/2dsb2JhbACcL3GjN5okgnIMgg0E X-IronPort-AV: E=Sophos;i="4.52,264,1270425600"; d="scan'208";a="104696312" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2010 22:44:48 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3NMimEa017663; Fri, 23 Apr 2010 22:44:48 GMT Message-ID: <4BD222E4.9060309@cisco.com> Date: Fri, 23 Apr 2010 18:44:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 22:45:01 -0000 I will grant you that having per-user policies for what to include in OPTIONS would be possible. But using that approach here means reserving a specific username. Which one are we allowed to pick that won't impact somebody? (I expect there are people out there named "ping" who might not like having their user name preempted.) AFAIK we have never preempted a user name, except for Anonymous, which is only preempted in the anonymous.invalid domain. I'd much rather see a special uri parameter to designate this behavior. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Friday, April 23, 2010 1:28 PM >> >> Making a decision based on the form of the R-URI presumes that non-ping >> users of options never use an ip address as the R-URI. Requiring the >> R-URI to be ping@ip reserves a user part, and also is just a sleazy way >> of adding another indicator to the message to indicate its intended use. > > Actually in a weird way I think doing a specific username may be the right thing to do. Think about it from an email perspective. When you check on the status and settings of an email list using SMTP, do you (a) send a new different SMTP message type, or (b) address a normal message to the actual logical administrative code for the list? You send a normal message to userlist-request@emailserver.com. > > And logically the thing being "pinged" is a higher layer, because the response provides an administrative status as well. (even though in code one would probably do this at a low level) > > Put it another way: in theory you could send a SUBSCRIBE to this logical admin-UA in that proxy so that it Notifies you when it goes admin up/down. That logical UA is a resource in the proxy, and could be addressed as such. > > -hadriel > From christer.holmberg@ericsson.com Fri Apr 23 15:54:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02543A67FD for ; Fri, 23 Apr 2010 15:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07f8C1UIh2y5 for ; Fri, 23 Apr 2010 15:54:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B2EC73A63EB for ; Fri, 23 Apr 2010 15:54:20 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-2c-4bd22510fcf8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 62.C2.23740.01522DB4; Sat, 24 Apr 2010 00:54:08 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 24 Apr 2010 00:54:08 +0200 From: Christer Holmberg To: Dean Willis Date: Sat, 24 Apr 2010 00:54:07 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjMeHyBve7FR3MQy2SKE2Z41nfQwAAm3oR Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael, Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 22:54:22 -0000 Hi, >>>> One possibility would be to use an option tag: Required:ping. That >>>> would ensure the other party knows this is a ping. (And of course if >>>> that fails you could remove the tag, and realize you were not >>>> getting a specialized ping implementation.) >>> >>> >>> >>> Nah, that just requires somebody to support the ping extension; it >>> doesn't tell them to apply that extension to this OPTIONS request. >> >> I don't think you can make such general assumption. It needs to be >> specified per option tag. >> >> For example, if you receive an INVITE with Require:100rel, you must >> not only support the extension - you must also use it when sending >> provisional responses (see RFC3262, section 3, paragraph 2). >> > >We've had this discussion before: 100rel was badly written in this respect= . > >For example, what do you do if you receive a request that has Require:100r= el but not Supported: 100rel? Assuming I support 100rel I would send my 18x responses reliably, because I= would assume, based on the text in 3262, that Require:100 implicitly indic= ates that the UAC also supports it. >>If you don't think is correct we'd need to update RFC3262. > >It's on my list of things to do Someday When I Have The Time. So, you want to say that a UAS must not send reliable responses in case the= INVITE only contains Require:100rel, but not Supported:100rel? In that cas= e I think "Someday" may have been a long time ago :) And, I also think you have the same issue with the "preconditions" option-t= ag. Are you going to update 3312/4032 also? And, what about sec-agree? >> In addition, the scope of an option-tag can be a single transaction, >> or wider. >> >> For example, just because I require 100rel in the initial INVITE, it >> doesn't mean (at least that is my understanding) I have implicitly >> also required it in each subsequent re-INVITE. >> >> The scope of Require:sec-agree, on the other hand, is for the whole >> session. >> >> Is there ANY option-tag defined, where we specify that Require only >> means must-support-but-is-not-required-to-use? > >Path and Service-Route and answer-mode come to mind. I edited them . . . I don't think we have an option-tag for Service-Route, do we? And, as far as I remember, RFC 3327 doesn't say anything about the usage of= the "path" option-tag in Require. Regards, Christer= From dean.willis@softarmor.com Fri Apr 23 15:54:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132C13A687E for ; Fri, 23 Apr 2010 15:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVyUUD1VwhEK for ; Fri, 23 Apr 2010 15:54:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 48CF73A63EB for ; Fri, 23 Apr 2010 15:54:43 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3NMs2jR027186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Apr 2010 17:54:04 -0500 Message-Id: <2DDA13E2-4954-41BA-B1FE-3A86A40E2175@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BD222E4.9060309@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Apr 2010 17:53:57 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> <4BD222E4.9060309@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 22:54:44 -0000 On Apr 23, 2010, at 5:44 PM, Paul Kyzivat wrote: > > I'd much rather see a special uri parameter to designate this > behavior. > That would be so cool! If only we had a way to pass URI parameters across proxies that do RFC 3261 contact-routing... Which of corse if why I've been standing on that particular soapbox for ten years or so. The best Idea I've heard along these lines is to stop REGISTERing Contact and start PUBLISHing a Route, as suggested by Adam early in MARTINI's life cycle. Perhaps we'll get there someday. -- Dean From HKaplan@acmepacket.com Fri Apr 23 16:00:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4223A63EB for ; Fri, 23 Apr 2010 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Ys8EGxVSbR for ; Fri, 23 Apr 2010 16:00:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ADD103A69EB for ; Fri, 23 Apr 2010 16:00:56 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Apr 2010 19:00:45 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Apr 2010 19:00:45 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 23 Apr 2010 19:00:44 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjNqNXvc0i80PuQ9mfd0/HT7LHbgAAiqS6 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 23:00:59 -0000 "root" obviously. ;) But seriously, picking a crazy username that won't collide is not that hard= . The question is if it's the right thing to do. Paul Kyzivat wrote: I will grant you that having per-user policies for what to include in OPTIONS would be possible. But using that approach here means reserving a specific username. Which one are we allowed to pick that won't impact somebody? (I expect there are people out there named "ping" who might not like having their user name preempted.) AFAIK we have never preempted a user name, except for Anonymous, which is only preempted in the anonymous.invalid domain. I'd much rather see a special uri parameter to designate this behavior. Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beha= lf >> Of Paul Kyzivat >> Sent: Friday, April 23, 2010 1:28 PM >> >> Making a decision based on the form of the R-URI presumes that non-ping >> users of options never use an ip address as the R-URI. Requiring the >> R-URI to be ping@ip reserves a user part, and also is just a sleazy way >> of adding another indicator to the message to indicate its intended use. > > Actually in a weird way I think doing a specific username may be the righ= t thing to do. Think about it from an email perspective. When you check o= n the status and settings of an email list using SMTP, do you (a) send a ne= w different SMTP message type, or (b) address a normal message to the actua= l logical administrative code for the list? You send a normal message to u= serlist-request@emailserver.com. > > And logically the thing being "pinged" is a higher layer, because the res= ponse provides an administrative status as well. (even though in code one w= ould probably do this at a low level) > > Put it another way: in theory you could send a SUBSCRIBE to this logical = admin-UA in that proxy so that it Notifies you when it goes admin up/down. = That logical UA is a resource in the proxy, and could be addressed as such= . > > -hadriel > From christer.holmberg@ericsson.com Sat Apr 24 00:30:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A2A3A6AF2 for ; Sat, 24 Apr 2010 00:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHNWnYrEyT45 for ; Sat, 24 Apr 2010 00:30:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9C68D28C0DB for ; Sat, 24 Apr 2010 00:30:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-d2-4bd29e267d74 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D6.D4.23532.62E92DB4; Sat, 24 Apr 2010 09:30:46 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.153]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 24 Apr 2010 09:30:46 +0200 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Sat, 24 Apr 2010 09:28:28 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjFoZdTnNwR8+PRUiQ1gZAXdzWIAAaTVSV Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> In-Reply-To: <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 07:30:59 -0000 Hi, >>One possibility would be to use an option tag: Required:ping. That >>would ensure the other party knows this is a ping. (And of course if >>that fails you could remove the tag, and realize you were not >>getting a specialized ping implementation.) > > > >Nah, that just requires somebody to support the ping extension; it >doesn't tell them to apply that extension to this OPTIONS request. In this specific case, does it really matter? As long as you only want SOME response, does it really matter? You will eit= her get a 200 or a 420 response. Regards, Christer= From sanjsinh@cisco.com Sat Apr 24 11:23:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDA73A6A56 for ; Sat, 24 Apr 2010 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rmYhDaHt7uq for ; Sat, 24 Apr 2010 11:22:58 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E4ABA3A6A59 for ; Sat, 24 Apr 2010 11:22:31 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGrT0kutJV2d/2dsb2JhbACcMnGgLpkQhQwEgzk X-IronPort-AV: E=Sophos;i="4.52,267,1270425600"; d="scan'208";a="104723551" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2010 18:22:20 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o3OIMIxJ009196; Sat, 24 Apr 2010 18:22:18 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Apr 2010 13:22:18 -0500 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: Sat, 24 Apr 2010 13:22:15 -0500 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA016C5244@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjFoZdTnNwR8+PRUiQ1gZAXdzWIAAaTVSVABa2mvA= References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Dean Willis" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 24 Apr 2010 18:22:18.0900 (UTC) FILETIME=[12F6FD40:01CAE3DB] Cc: "Paul E. Jones" , sipcore@ietf.org, Michael Miller Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 18:23:03 -0000 It matters in the sense what the UAS returns in 200 OK response to OPTIONS. If it supports that extension, it will return a success response without it's full capabilities, as will be required with normal OPTIONS processing. Sanjay > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Saturday, April 24, 2010 12:58 PM > To: Dean Willis; Paul Kyzivat (pkyzivat) > Cc: Paul E. Jones; sipcore@ietf.org; 'Michael Miller' > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt >=20 > Hi, >=20 > >>One possibility would be to use an option tag: Required:ping. That > >>would ensure the other party knows this is a ping. (And of course if > >>that fails you could remove the tag, and realize you were not > >>getting a specialized ping implementation.) > > > > > > > >Nah, that just requires somebody to support the ping extension; it > >doesn't tell them to apply that extension to this OPTIONS request. >=20 > In this specific case, does it really matter? >=20 > As long as you only want SOME response, does it really matter? You will either get a > 200 or a 420 response. >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Sat Apr 24 13:43:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779443A67D2 for ; Sat, 24 Apr 2010 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kNySlUNGBc5 for ; Sat, 24 Apr 2010 13:43:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 97F273A65A6 for ; Sat, 24 Apr 2010 13:43:40 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3OKhLK8001648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 24 Apr 2010 15:43:23 -0500 Message-Id: <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Apr 2010 15:43:16 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 20:43:41 -0000 On Apr 23, 2010, at 5:54 PM, Christer Holmberg wrote: >> >> For example, what do you do if you receive a request that has >> Require:100rel but not Supported: 100rel? > > Assuming I support 100rel I would send my 18x responses reliably, > because I would assume, based on the text in 3262, that Require:100 > implicitly indicates that the UAC also supports it. > So, 3262 has a bug in it. Putting an option tag in Require clearly doesn't men you support the feature, only that you require the UAS to do so. >>> If you don't think is correct we'd need to update RFC3262. >> >> It's on my list of things to do Someday When I Have The Time. > > So, you want to say that a UAS must not send reliable responses in > case the INVITE only contains Require:100rel, but not Supported: > 100rel? In that case I think "Someday" may have been a long time > ago :) I think at a minimum that 3262 should say that a UAC putting a Require: 100rel MUST also put Supported: 100rel > > And, I also think you have the same issue with the "preconditions" > option-tag. Are you going to update 3312/4032 also? > I suspect it needs it. > And, what about sec-agree? It's clearly got bugs. > >>> In addition, the scope of an option-tag can be a single transaction, >>> or wider. >>> >>> For example, just because I require 100rel in the initial INVITE, it >>> doesn't mean (at least that is my understanding) I have implicitly >>> also required it in each subsequent re-INVITE. >>> >>> The scope of Require:sec-agree, on the other hand, is for the whole >>> session. >>> >>> Is there ANY option-tag defined, where we specify that Require only >>> means must-support-but-is-not-required-to-use? >> >> Path and Service-Route and answer-mode come to mind. I edited >> them . . . > > I don't think we have an option-tag for Service-Route, do we? > > And, as far as I remember, RFC 3327 doesn't say anything about the > usage of the "path" option-tag in Require. Right. The UAS is free to use path if the UAC supports it. It doesn't decide whether or not to use the extension based on a Require. -- Dean From christer.holmberg@ericsson.com Sun Apr 25 02:57:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0593A6929 for ; Sun, 25 Apr 2010 02:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWwsnEFypwIW for ; Sun, 25 Apr 2010 02:57:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AFA883A688B for ; Sun, 25 Apr 2010 02:57:58 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-68-4bd4121924ed Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 31.D7.23740.91214DB4; Sun, 25 Apr 2010 11:57:45 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 25 Apr 2010 11:57:45 +0200 From: Christer Holmberg To: "Sanjay Sinha (sanjsinh)" , Dean Willis , "Paul Kyzivat (pkyzivat)" Date: Sun, 25 Apr 2010 11:55:12 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjFoZdTnNwR8+PRUiQ1gZAXdzWIAAaTVSVABa2mvAAILPkwQ== Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , <00FC4AA684E90E4DA2FF71021CD5A6CA016C5244@XMB-RCD-101.cisco.com> In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA016C5244@XMB-RCD-101.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: "Paul E. Jones" , "sipcore@ietf.org" , Michael Miller Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 09:57:59 -0000 Hi, >It matters in the sense what the UAS returns in 200 OK response to >OPTIONS. If it supports that extension, it will return a success >response without it's full capabilities, as will be required with normal >OPTIONS processing. But, from a ping perspective, why does it matter what the response code it?= Why does it matter whether the receiver supports the functionality or not? Of course, if you also expect the receiver to send pings towards you, then = you may need to know whether it supports the mechanism. But, if you are the= only one sending pings, all you want is A response, isn't it? Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Saturday, April 24, 2010 12:58 PM > To: Dean Willis; Paul Kyzivat (pkyzivat) > Cc: Paul E. Jones; sipcore@ietf.org; 'Michael Miller' > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt > > Hi, > > >>One possibility would be to use an option tag: Required:ping. That > >>would ensure the other party knows this is a ping. (And of course if > >>that fails you could remove the tag, and realize you were not > >>getting a specialized ping implementation.) > > > > > > > >Nah, that just requires somebody to support the ping extension; it > >doesn't tell them to apply that extension to this OPTIONS request. > > In this specific case, does it really matter? > > As long as you only want SOME response, does it really matter? You will either get a > 200 or a 420 response. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Sun Apr 25 12:25:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A093A6A28 for ; Sun, 25 Apr 2010 12:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.517 X-Spam-Level: X-Spam-Status: No, score=-4.517 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhtST1a6ZSMm for ; Sun, 25 Apr 2010 12:25:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 243253A6980 for ; Sun, 25 Apr 2010 12:25:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-a2-4bd49716e2d6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 52.E9.23532.61794DB4; Sun, 25 Apr 2010 21:25:10 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sun, 25 Apr 2010 21:25:10 +0200 From: Christer Holmberg To: Dean Willis Date: Sun, 25 Apr 2010 21:25:10 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrj7st0VC4r17FrT4msJ3bif/HqbAAbww9Q Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> In-Reply-To: <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael, Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 19:25:28 -0000 Hi, >>> For example, what do you do if you receive a request that has >>> Require:100rel but not Supported: 100rel? >> >> Assuming I support 100rel I would send my 18x responses reliably, >> because I would assume, based on the text in 3262, that Require:100 >> implicitly indicates that the UAC also supports it. >> > >So, 3262 has a bug in it. Putting an option tag in Require clearly doesn't= men you support the feature, only that you require the UAS to do so. Upon what text do you base "clearly"?=20 If it's so clear, why have we ended up with a number of RFCs which would be= incorrect? >>>> If you don't think is correct we'd need to update RFC3262. >>> >>>It's on my list of things to do Someday When I Have The Time. >> >>So, you want to say that a UAS must not send reliable responses in >>case the INVITE only contains Require:100rel, but not Supported: >>100rel? In that case I think "Someday" may have been a long time >>ago :) > >I think at a minimum that 3262 should say that a UAC putting a Require: 10= 0rel MUST also put Supported: 100rel If we would be doing 3262 today I would not necessarily disagree with you. = Today, I just think you're going to end up with backward compability issues= . >>>And, I also think you have the same issue with the "preconditions" optio= n-tag. Are you going to update 3312/4032 also? >> >>I suspect it needs it. >> >>And, what about sec-agree? >> >It's clearly got bugs. I love this protocol... Also, in some cases the Require header in a *response* seems to have differ= ent meanings.=20 For example, "Require: outbound" in a response seems to indicate that the r= egistrar has done somthing, while "timer" seems to require the UAC to do so= mething (ie not only require to support some extension). So, if Require only means "you must support", why would someone send 'Requi= re: x' in a response if the associated request already contained 'Supported= : x'? The UAC has already indicated support, so there is no need to say you= -must-support... Regards, Christer= From sanjsinh@cisco.com Sun Apr 25 21:00:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6DF3A6A64 for ; Sun, 25 Apr 2010 21:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysRuU0rU5s5D for ; Sun, 25 Apr 2010 21:00:37 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0BCBB3A6AE6 for ; Sun, 25 Apr 2010 21:00:28 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANqs1EutJV2b/2dsb2JhbACcNHGmQph6hQwEgzk X-IronPort-AV: E=Sophos;i="4.52,271,1270425600"; d="scan'208";a="105109812" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2010 04:00:16 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o3Q40GOu021242; Mon, 26 Apr 2010 04:00:16 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 23:00:16 -0500 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: Sun, 25 Apr 2010 23:00:12 -0500 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA016C530F@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrjFoZdTnNwR8+PRUiQ1gZAXdzWIAAaTVSVABa2mvAAILPkwQAlJxdw References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , <00FC4AA684E90E4DA2FF71021CD5A6CA016C5244@XMB-RCD-101.cisco.com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Dean Willis" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 26 Apr 2010 04:00:16.0493 (UTC) FILETIME=[FAD581D0:01CAE4F4] Cc: "Paul E. Jones" , sipcore@ietf.org, Michael Miller Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 04:00:38 -0000 It is true that all the receiver wants is some response. And for that, the receiving node does not even have to support OPTIONS. If it does not, then it will send 405 response. That is enough for the sender to know that the ping was successful. But I think that we are talking about case where 200 OK is considered as successful ping. For that case, Dean was suggesting an options tag for the receiver to sends a ping 200 OK response as compared to 200 OK response for an OPTIONS, which is to query capabilities. Maybe all confusion is due to overloading of OPTIONS. Thanks Sanjay > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, April 25, 2010 3:25 PM > To: Sanjay Sinha (sanjsinh); Dean Willis; Paul Kyzivat (pkyzivat) > Cc: Paul E. Jones; sipcore@ietf.org; Michael Miller > Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt >=20 > Hi, >=20 > >It matters in the sense what the UAS returns in 200 OK response to > >OPTIONS. If it supports that extension, it will return a success > >response without it's full capabilities, as will be required with normal > >OPTIONS processing. >=20 > But, from a ping perspective, why does it matter what the response code it? Why does > it matter whether the receiver supports the functionality or not? >=20 > Of course, if you also expect the receiver to send pings towards you, then you may > need to know whether it supports the mechanism. But, if you are the only one sending > pings, all you want is A response, isn't it? > >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of > > Christer Holmberg > > Sent: Saturday, April 24, 2010 12:58 PM > > To: Dean Willis; Paul Kyzivat (pkyzivat) > > Cc: Paul E. Jones; sipcore@ietf.org; 'Michael Miller' > > Subject: Re: [sipcore] FW: I-D > Action:draft-jones-sip-options-ping-00.txt > > > > Hi, > > > > >>One possibility would be to use an option tag: Required:ping. That > > >>would ensure the other party knows this is a ping. (And of course if > > >>that fails you could remove the tag, and realize you were not > > >>getting a specialized ping implementation.) > > > > > > > > > > > >Nah, that just requires somebody to support the ping extension; it > > >doesn't tell them to apply that extension to this OPTIONS request. > > > > In this specific case, does it really matter? > > > > As long as you only want SOME response, does it really matter? You > will either get a > > 200 or a 420 response. > > > > Regards, > > > > Christer > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From sanjsinh@cisco.com Sun Apr 25 21:16:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109BA3A6847 for ; Sun, 25 Apr 2010 21:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m34yaU7cXdqA for ; Sun, 25 Apr 2010 21:16:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 56B853A67F7 for ; Sun, 25 Apr 2010 21:16:38 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF+w1EutJV2c/2dsb2JhbACcNHGmHZh8hQwEgzk X-IronPort-AV: E=Sophos;i="4.52,271,1270425600"; d="scan'208";a="105112454" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2010 04:16:25 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o3Q4GP7q027295; Mon, 26 Apr 2010 04:16:25 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 23:16:25 -0500 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: Sun, 25 Apr 2010 23:16:23 -0500 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA016C5316@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrj7st0VC4r17FrT4msJ3bif/HqbAAbww9QACZPsmA= References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com>, , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Dean Willis" X-OriginalArrivalTime: 26 Apr 2010 04:16:25.0566 (UTC) FILETIME=[3C724FE0:01CAE4F7] Cc: "Paul E. Jones" , Michael@core3.amsl.com, sipcore@ietf.org, Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 04:16:40 -0000 Without "Require" in the response, how does the UAC know that the UAS supports that extension, if the UAC had added a Supported header in the request? Thanks Sanjay > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Monday, April 26, 2010 12:55 AM > To: Dean Willis > Cc: Paul E. Jones; sipcore@ietf.org; Michael@core3.amsl.com; Miller' > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt >=20 > Hi, >=20 > >>> For example, what do you do if you receive a request that has > >>> Require:100rel but not Supported: 100rel? > >> > >> Assuming I support 100rel I would send my 18x responses reliably, > >> because I would assume, based on the text in 3262, that Require:100 > >> implicitly indicates that the UAC also supports it. > >> > > > >So, 3262 has a bug in it. Putting an option tag in Require clearly doesn't men you > support the feature, only that you require the UAS to do so. >=20 > Upon what text do you base "clearly"? >=20 > If it's so clear, why have we ended up with a number of RFCs which would be > incorrect? >=20 > >>>> If you don't think is correct we'd need to update RFC3262. > >>> > >>>It's on my list of things to do Someday When I Have The Time. > >> > >>So, you want to say that a UAS must not send reliable responses in > >>case the INVITE only contains Require:100rel, but not Supported: > >>100rel? In that case I think "Someday" may have been a long time > >>ago :) > > > >I think at a minimum that 3262 should say that a UAC putting a Require: 100rel > MUST also put Supported: 100rel >=20 > If we would be doing 3262 today I would not necessarily disagree with you. Today, I > just think you're going to end up with backward compability issues. >=20 > >>>And, I also think you have the same issue with the "preconditions" option-tag. Are > you going to update 3312/4032 also? > >> > >>I suspect it needs it. > >> > >>And, what about sec-agree? > >> > >It's clearly got bugs. >=20 > I love this protocol... >=20 > Also, in some cases the Require header in a *response* seems to have different > meanings. >=20 > For example, "Require: outbound" in a response seems to indicate that the registrar has > done somthing, while "timer" seems to require the UAC to do something (ie not only > require to support some extension). >=20 > So, if Require only means "you must support", why would someone send 'Require: x' > in a response if the associated request already contained 'Supported: x'? The UAC has > already indicated support, so there is no need to say you-must-support... >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Apr 26 00:02:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3473A67F0 for ; Mon, 26 Apr 2010 00:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX+kRxxcWT3o for ; Mon, 26 Apr 2010 00:02:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E2A223A67F9 for ; Mon, 26 Apr 2010 00:02:21 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-cc-4bd53a700411 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 77.97.23740.07A35DB4; Mon, 26 Apr 2010 09:02:08 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 26 Apr 2010 09:02:08 +0200 From: Christer Holmberg To: "Sanjay Sinha (sanjsinh)" , Dean Willis Date: Mon, 26 Apr 2010 09:02:05 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrj7st0VC4r17FrT4msJ3bif/HqbAAbww9QACZPsmAABcjhsA== Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com>, , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <00FC4AA684E90E4DA2FF71021CD5A6CA016C5316@XMB-RCD-101.cisco.com> In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA016C5316@XMB-RCD-101.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: "Paul E. Jones" , "Michael@core3.amsl.com" , "sipcore@ietf.org" , Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 07:02:23 -0000 Hi,=20 >Without "Require" in the response, how does the UAC know that the UAS supp= orts that extension, if the UAC had added a=20 >Supported header in the request? According to Dean "Require" doesn't say anything about what the UAS support= s, or doesn't support. It only says what the receiver must support. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of > > Christer Holmberg > > Sent: Monday, April 26, 2010 12:55 AM > > To: Dean Willis > > Cc: Paul E. Jones; sipcore@ietf.org; Michael@core3.amsl.com; Miller' > > Subject: Re: [sipcore] FW: I-D > Action:draft-jones-sip-options-ping-00.txt > >=20 > > Hi, > >=20 > > >>> For example, what do you do if you receive a request that has=20 > > >>> Require:100rel but not Supported: 100rel? > > >> > > >> Assuming I support 100rel I would send my 18x responses=20 > reliably,=20 > > >> because I would assume, based on the text in 3262, that=20 > Require:100=20 > > >> implicitly indicates that the UAC also supports it. > > >> > > > > > >So, 3262 has a bug in it. Putting an option tag in Require clearly > doesn't men you > > support the feature, only that you require the UAS to do so. > >=20 > > Upon what text do you base "clearly"? > >=20 > > If it's so clear, why have we ended up with a number of RFCs which > would be > > incorrect? > >=20 > > >>>> If you don't think is correct we'd need to update RFC3262. > > >>> > > >>>It's on my list of things to do Someday When I Have The Time. > > >> > > >>So, you want to say that a UAS must not send reliable=20 > responses in=20 > > >>case the INVITE only contains Require:100rel, but not Supported: > > >>100rel? In that case I think "Someday" may have been a=20 > long time ago=20 > > >>:) > > > > > >I think at a minimum that 3262 should say that a UAC putting a > Require: 100rel > > MUST also put Supported: 100rel > >=20 > > If we would be doing 3262 today I would not necessarily=20 > disagree with > you. Today, I > > just think you're going to end up with backward compability issues. > >=20 > > >>>And, I also think you have the same issue with the=20 > "preconditions" > option-tag. Are > > you going to update 3312/4032 also? > > >> > > >>I suspect it needs it. > > >> > > >>And, what about sec-agree? > > >> > > >It's clearly got bugs. > >=20 > > I love this protocol... > >=20 > > Also, in some cases the Require header in a *response* seems to have > different > > meanings. > >=20 > > For example, "Require: outbound" in a response seems to=20 > indicate that > the registrar has > > done somthing, while "timer" seems to require the UAC to do=20 > something > (ie not only > > require to support some extension). > >=20 > > So, if Require only means "you must support", why would someone send > 'Require: x' > > in a response if the associated request already contained=20 > 'Supported: > x'? The UAC has > > already indicated support, so there is no need to say > you-must-support... > >=20 > > Regards, > >=20 > > Christer > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > = From dean.willis@softarmor.com Mon Apr 26 02:13:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489C33A6AE6 for ; Mon, 26 Apr 2010 02:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkzIGrVJAEQj for ; Mon, 26 Apr 2010 02:13:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CA28D28C103 for ; Mon, 26 Apr 2010 02:13:19 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3Q9D0EA012906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 04:13:02 -0500 Message-Id: <5BD6692A-3AAC-4C57-B40E-9D6BC4ED656F@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 04:12:55 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , <00FC4AA684E90E4DA2FF71021CD5A6CA016C5244@XMB-RCD-101.cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Sanjay Sinha \(sanjsinh\)" , "Paul E. Jones" , "sipcore@ietf.org" , Michael Miller Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:13:47 -0000 On Apr 25, 2010, at 4:55 AM, Christer Holmberg wrote: > Hi, > >> It matters in the sense what the UAS returns in 200 OK response to >> OPTIONS. If it supports that extension, it will return a success >> response without it's full capabilities, as will be required with >> normal >> OPTIONS processing. > > But, from a ping perspective, why does it matter what the response > code it? Why does it matter whether the receiver supports the > functionality or not? > > Of course, if you also expect the receiver to send pings towards > you, then you may need to know whether it supports the mechanism. > But, if you are the only one sending pings, all you want is A > response, isn't it? > Then you don't need an option tag and don't need to be able to Require the extension. It's just an optimization parameter; if the UAS sees a recognizable "ping" flag, then it can return an optimized options-free response. If it doesn't understand the flag, it returns a conventional response. Sounds like a great candidate for a new header field. Note that I've generally believed that header fields should be easy to register, given that they're our only really way to pass parameters since we broke URI-parameters with contact-routing. Maybe we can define an "OPtions-Mode" header field, and register the value "ping" here -- and add additional Options-Mode values here in the future if needed. -- Dean From dean.willis@softarmor.com Mon Apr 26 02:34:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7D63A6B0A for ; Mon, 26 Apr 2010 02:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbLs9qcJnxN8 for ; Mon, 26 Apr 2010 02:34:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1327D3A6B1C for ; Mon, 26 Apr 2010 02:32:54 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3Q9WYO6013020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 04:32:36 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 04:32:28 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:34:06 -0000 On Apr 25, 2010, at 2:25 PM, Christer Holmberg wrote: > Hi, > >>>> For example, what do you do if you receive a request that has >>>> Require:100rel but not Supported: 100rel? >>> >>> Assuming I support 100rel I would send my 18x responses reliably, >>> because I would assume, based on the text in 3262, that Require:100 >>> implicitly indicates that the UAC also supports it. >>> >> >> So, 3262 has a bug in it. Putting an option tag in Require clearly >> doesn't men you support the feature, only that you require the UAS >> to do so. > > Upon what text do you base "clearly"? RFC 3261: 20.32 Require says (verbatim): "The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although an optional header field, the Require MUST NOT be ignored if it is present. The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs." The above clearly indicates that the usual use of the option-tag in Require is to indicate that there is other data in the request, typically header fields, which the UAS MUST be able to understand in order to process the request. It does NOT say that the presence of the Require changes the behavior of the UAS in any other way; it's the presence of those header fields (or other extension flags) in the request that changes the behavior. All the Require does is cause the UAS to reject the request if it doesn't understand that other data. This changes the default behavior of a UAS, which is to silently ignore "other data" that it does not understand. Note that having a Require for a new request type is rather useless, as we're less liberal-in-what-we -accept with request types and reject unknowns anyhow. In other words, un-Required extensions appearing in a known request type are ignored if not understood, whereas Required extensions that are not understood cause the request to be rejected. Note also that the prohibition of non-standards-track option-tags is spelled out in RFC 3261. > > If it's so clear, why have we ended up with a number of RFCs which > would be incorrect? > It's an overly complicated design for our simple minds? I didn't say I LIKE the way this works in RFC 3261, just that I mostly (ok, sortof) understand it. >>> >> It's clearly got bugs. > > I love this protocol... > Yes, it gives us so much to work on. Much better than knitting or jigsaw puzzles on a cold winter night! > Also, in some cases the Require header in a *response* seems to have > different meanings. Very true. At the moment, I can't say where the meaning of Require in a response comes from. RFC 3261 does not, AFAIK, say anything about it. We seem to have invented it on the fly without formal specification, using an error in RFC 3261's table 2/3 to justify the approach. Perhaps a more formal specification would be a good idea. > > For example, "Require: outbound" in a response seems to indicate > that the registrar has done somthing, while "timer" seems to require > the UAC to do something (ie not only require to support some > extension). > > So, if Require only means "you must support", why would someone send > 'Require: x' in a response if the associated request already > contained 'Supported: x'? The UAC has already indicated support, so > there is no need to say you-must-support... I dunno. Maybe somebody wrote a specification based on not understanding Require in the request and we were too tired of arguing about it to stop the publication? -- Dean From dean.willis@softarmor.com Mon Apr 26 02:40:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3631C3A6452 for ; Mon, 26 Apr 2010 02:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfvE11RGCLMR for ; Mon, 26 Apr 2010 02:40:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 389193A68A7 for ; Mon, 26 Apr 2010 02:40:22 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3Q9e3eX013143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 04:40:04 -0500 Message-Id: <244B0642-4D22-4DCC-9A43-18E732C8B722@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 04:39:57 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com>, , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <00FC4AA684E90E4DA2FF71021CD5A6CA016C5316@XMB-RCD-101.cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Sanjay Sinha \(sanjsinh\)" , "Paul E. Jones" , "Michael@core3.amsl.com" , "sipcore@ietf.org" , Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:40:26 -0000 On Apr 26, 2010, at 2:02 AM, Christer Holmberg wrote: > > Hi, > >> Without "Require" in the response, how does the UAC know that the >> UAS supports that extension, if the UAC had added a >> Supported header in the request? > > According to Dean "Require" doesn't say anything about what the UAS > supports, or doesn't support. It only says what the receiver must > support. Not quite. The UAS is (by definition) the receiver of any request, and the Require says that if the UAS does not support the required option, then it must reject the request. Other than that, the Require doesn't invoke any specific behavior in the UAS. So for example a INVITE with a "Require: explodemyphone" doesn't make the phone blow up, but would cause the phone to reject the request if it doesn't know how to blow up. It'd be some other header field, like "Explodemyphone:withsmokeandfire". In the absence of a Require, a phone that didn't know how to explode would just ignore that part of the request and alert in the usual fashion. Also, an INVITE with a "Require:explodemyphone" but that lacked an "Explodemyphone" header field would be accepted by a phone that knows how to explode, but said phone probably wouldn't explode as a result (especially not with both smoke and fire!) -- Dean From christer.holmberg@ericsson.com Mon Apr 26 03:43:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E8E3A6950 for ; Mon, 26 Apr 2010 03:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SVGQEItwIdL for ; Mon, 26 Apr 2010 03:43:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 85ED33A68D5 for ; Mon, 26 Apr 2010 03:43:10 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-92-4bd56e315329 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0F.AA.23740.13E65DB4; Mon, 26 Apr 2010 12:42:57 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 26 Apr 2010 12:42:57 +0200 From: Christer Holmberg To: Dean Willis Date: Mon, 26 Apr 2010 12:42:55 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrlJm4nr8YntN9qTfqaT904lvaDnAABfomw Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael, Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:43:14 -0000 Hi,=20 >>>So, 3262 has a bug in it. Putting an option tag in Require clearly=20 >>>doesn't men you support the feature, only that you require=20 >>>the UAS to do so. >> >>Upon what text do you base "clearly"? >=20 >RFC 3261: 20.32 Require says (verbatim): >"The Require header field is used by UACs to tell UASs about=20 >options that the UAC expects the UAS to support in order to=20 >process the request. Although an optional header field, the=20 >Require MUST NOT be ignored if it is present. The Require=20 >header field contains a list of option tags, described in=20 >Section 19.2. Each option tag defines a SIP extension that=20 >MUST be understood to process the request. Frequently, this=20 >is used to indicate that a specific set of extension header=20 >fields need to be understood. A UAC compliant to this=20 >specification MUST only include option tags corresponding to=20 >standards-track RFCs." >=20 >The above clearly indicates that the usual use of the=20 >option-tag in Require is to indicate that there is other data=20 >in the request, typically header fields, which the UAS MUST=20 >be able to understand in order to process the request. It=20 >does NOT say that the presence of the Require changes the=20 >behavior of the UAS in any other way; it's the presence of=20 >those header fields (or other extension flags) in the request=20 >that changes the behavior. All the Require does is cause the=20 >UAS to reject the request if it doesn't understand that other data. =20 >This changes the default behavior of a UAS, which is to=20 >silently ignore "other data" that it does not understand.=20 >Note that having a Require for a new request type is rather=20 >useless, as we're less liberal-in-what-we -accept with=20 >request types and reject unknowns anyhow. >In other words, un-Required extensions appearing in a known=20 >request type are ignored if not understood, whereas Required=20 >extensions that are not understood cause the request to be rejected. >Note also that the prohibition of non-standards-track=20 >option-tags is spelled out in RFC 3261. Section 8.1.1.9 says: "If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it MUST insert a Require header field into the request listing the option tag for that extension." I think the "that the UAC will apply" could be read as indicating that the = UAC also supports the extension. >>Also, in some cases the Require header in a *response* seems to have =20 >>different meanings. >=20 >Very true. At the moment, I can't say where the meaning of=20 >Require in a response comes from. RFC 3261 does not, AFAIK, say anything a= bout =20 >it. We seem to have invented it on the fly without formal =20 >specification, using an error in RFC 3261's table 2/3 to justify the =20 >approach. Perhaps a more formal specification would be a good idea. >=20 >>For example, "Require: outbound" in a response seems to indicate =20 >>that the registrar has done somthing, while "timer" seems=20 >>to require the UAC to do something (ie not only require to support some = =20 >>extension). >>=20 >>So, if Require only means "you must support", why would someone send =20 >>'Require: x' in a response if the associated request already =20 >>contained 'Supported: x'? The UAC has already indicated support, so =20 >>there is no need to say you-must-support... >=20 >I dunno. Maybe somebody wrote a specification based on not =20 >understanding Require in the request and we were too tired of=20 >arguing about it to stop the publication? Well, it's not only one specification... Regards, Christer From christer.holmberg@ericsson.com Mon Apr 26 03:45:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5973A68FE for ; Mon, 26 Apr 2010 03:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pefKHOxp+pfn for ; Mon, 26 Apr 2010 03:45:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A0D133A6817 for ; Mon, 26 Apr 2010 03:45:33 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9e-4bd56ec03178 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 41.0B.23740.0CE65DB4; Mon, 26 Apr 2010 12:45:20 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 26 Apr 2010 12:45:20 +0200 From: Christer Holmberg To: Dean Willis Date: Mon, 26 Apr 2010 12:45:18 +0200 Thread-Topic: Meaning of Require in response [was: I-D Action:draft-jones-sip-options-ping-00.txt] Thread-Index: AcrlJomHKQrF+sFZQ8OkcfsQcn0qVAABsqKg Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com><32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com><02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com>, , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <00FC4AA684E90E4DA2FF71021CD5A6CA016C5316@XMB-RCD-101.cisco.com> <244B0642-4D22-4DCC-9A43-18E732C8B722@softarmor.com> In-Reply-To: <244B0642-4D22-4DCC-9A43-18E732C8B722@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Sanjay Sinha \(sanjsinh\)" , "Paul E. Jones" , "Michael@core3.amsl.com" , "sipcore@ietf.org" , Miller' Subject: [sipcore] Meaning of Require in response [was: I-D Action:draft-jones-sip-options-ping-00.txt] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:45:34 -0000 Hi,=20 >>>Without "Require" in the response, how does the UAC know=20 >>>that the UAS supports that extension, if the UAC had added a Supported=20 >>>header in the request? >> >>According to Dean "Require" doesn't say anything about what the UAS=20 >>supports, or doesn't support. It only says what the receiver must=20 >>support. >=20 >Not quite. The UAS is (by definition) the receiver of any=20 >request, and the Require says that if the UAS does not=20 >support the required option, then it must reject the request. Note that the text above was about Require in a response (in which case the= UAC is the receiver). Regards, Christer From pkyzivat@cisco.com Mon Apr 26 05:43:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CD53A6BA1 for ; Mon, 26 Apr 2010 05:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.346 X-Spam-Level: X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt1Tmzd9fFTS for ; Mon, 26 Apr 2010 05:43:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 226273A6993 for ; Mon, 26 Apr 2010 05:43:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALsm1UtAZnwM/2dsb2JhbACcO3GmKplFhQwE X-IronPort-AV: E=Sophos;i="4.52,273,1270425600"; d="scan'208";a="105086026" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2010 12:43:33 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3QChXOn018791; Mon, 26 Apr 2010 12:43:33 GMT Message-ID: <4BD58A77.2090109@cisco.com> Date: Mon, 26 Apr 2010 08:43:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , "Paul E. Jones" , "sipcore@ietf.org" Subject: [sipcore] The semantics of Require. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 12:43:51 -0000 If this discussion is to continue, can we at least have a relevant subject rather than hijacking the discussion options ping? I agree in principle with Dean's point. But from a practical perspective I think we just acknowledge that the definition of certain options added on additional semantics. I think we should just grandfather that but refrain from making the same mistake in the future. Thanks, Paul Christer Holmberg wrote: > Hi, > >>>> So, 3262 has a bug in it. Putting an option tag in Require clearly >>>> doesn't men you support the feature, only that you require >>>> the UAS to do so. >>> Upon what text do you base "clearly"? >> RFC 3261: 20.32 Require says (verbatim): >> "The Require header field is used by UACs to tell UASs about >> options that the UAC expects the UAS to support in order to >> process the request. Although an optional header field, the >> Require MUST NOT be ignored if it is present. The Require >> header field contains a list of option tags, described in >> Section 19.2. Each option tag defines a SIP extension that >> MUST be understood to process the request. Frequently, this >> is used to indicate that a specific set of extension header >> fields need to be understood. A UAC compliant to this >> specification MUST only include option tags corresponding to >> standards-track RFCs." >> >> The above clearly indicates that the usual use of the >> option-tag in Require is to indicate that there is other data >> in the request, typically header fields, which the UAS MUST >> be able to understand in order to process the request. It >> does NOT say that the presence of the Require changes the >> behavior of the UAS in any other way; it's the presence of >> those header fields (or other extension flags) in the request >> that changes the behavior. All the Require does is cause the >> UAS to reject the request if it doesn't understand that other data. >> This changes the default behavior of a UAS, which is to >> silently ignore "other data" that it does not understand. >> Note that having a Require for a new request type is rather >> useless, as we're less liberal-in-what-we -accept with >> request types and reject unknowns anyhow. >> In other words, un-Required extensions appearing in a known >> request type are ignored if not understood, whereas Required >> extensions that are not understood cause the request to be rejected. >> Note also that the prohibition of non-standards-track >> option-tags is spelled out in RFC 3261. > > Section 8.1.1.9 says: > > "If the UAC wishes to insist that a UAS understand an extension that > the UAC will apply to the request in order to process the request, it > MUST insert a Require header field into the request listing the > option tag for that extension." > > I think the "that the UAC will apply" could be read as indicating that the UAC also supports the extension. > >>> Also, in some cases the Require header in a *response* seems to have >>> different meanings. >> Very true. At the moment, I can't say where the meaning of >> Require in a response comes from. RFC 3261 does not, AFAIK, say anything about >> it. We seem to have invented it on the fly without formal >> specification, using an error in RFC 3261's table 2/3 to justify the >> approach. Perhaps a more formal specification would be a good idea. >> >>> For example, "Require: outbound" in a response seems to indicate >>> that the registrar has done somthing, while "timer" seems >>> to require the UAC to do something (ie not only require to support some >>> extension). >>> >>> So, if Require only means "you must support", why would someone send >>> 'Require: x' in a response if the associated request already >>> contained 'Supported: x'? The UAC has already indicated support, so >>> there is no need to say you-must-support... >> I dunno. Maybe somebody wrote a specification based on not >> understanding Require in the request and we were too tired of >> arguing about it to stop the publication? > > Well, it's not only one specification... > > Regards, > > Christer > From pkyzivat@cisco.com Mon Apr 26 05:52:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95ED3A6BA1 for ; Mon, 26 Apr 2010 05:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP9cNvd+EWoO for ; Mon, 26 Apr 2010 05:52:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A3E493A6B96 for ; Mon, 26 Apr 2010 05:52:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABMp1UtAZnwN/2dsb2JhbACcO3GmKJlFhQwE X-IronPort-AV: E=Sophos;i="4.52,273,1270425600"; d="scan'208";a="105227067" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2010 12:52:22 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3QCqMFi009036; Mon, 26 Apr 2010 12:52:22 GMT Message-ID: <4BD58C85.80303@cisco.com> Date: Mon, 26 Apr 2010 08:52:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> <4BD222E4.9060309@cisco.com> <2DDA13E2-4954-41BA-B1FE-3A86A40E2175@softarmor.com> In-Reply-To: <2DDA13E2-4954-41BA-B1FE-3A86A40E2175@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 12:52:36 -0000 Dean, The loss of parameters on retargeting is a valid issue in general, and may be a reason not to use a parameter in this case. But it isn't a problem for the use case contemplated because that case doesn't expect there to be retargeting. But haven't we decided to solve the uri parameter problem with H-I? Thanks, Paul Dean Willis wrote: > > On Apr 23, 2010, at 5:44 PM, Paul Kyzivat wrote: >> >> I'd much rather see a special uri parameter to designate this behavior. >> > > That would be so cool! > > If only we had a way to pass URI parameters across proxies that do RFC > 3261 contact-routing... > > Which of corse if why I've been standing on that particular soapbox for > ten years or so. > > The best Idea I've heard along these lines is to stop REGISTERing > Contact and start PUBLISHing a Route, as suggested by Adam early in > MARTINI's life cycle. Perhaps we'll get there someday. > > -- > Dean > > From pkyzivat@cisco.com Mon Apr 26 05:55:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04AA3A6BA9 for ; Mon, 26 Apr 2010 05:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.422 X-Spam-Level: X-Spam-Status: No, score=-9.422 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSaBjRaz3MAo for ; Mon, 26 Apr 2010 05:55:46 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8842C3A6BAA for ; Mon, 26 Apr 2010 05:55:46 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD8q1UtAZnwN/2dsb2JhbACcO3GmQZlIgnMMgg0E X-IronPort-AV: E=Sophos;i="4.52,273,1270425600"; d="scan'208";a="105228119" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2010 12:55:34 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3QCtY68010078; Mon, 26 Apr 2010 12:55:34 GMT Message-ID: <4BD58D45.3000709@cisco.com> Date: Mon, 26 Apr 2010 08:55:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 12:55:47 -0000 Hadriel Kaplan wrote: > "root" obviously. ;) > But seriously, picking a crazy username that won't collide is not that hard. The question is if it's the right thing to do. I don't believe in reserving names from other people's namespaces after the fact, on general principles. You cannot know how they use their namespace. You can reduce the probability of collision by making the value very obscure, but then it is very obscure. So IMO it is the wrong thing to do. Thanks, Paul > Paul Kyzivat wrote: > > > I will grant you that having per-user policies for what to include in > OPTIONS would be possible. > > But using that approach here means reserving a specific username. Which > one are we allowed to pick that won't impact somebody? (I expect there > are people out there named "ping" who might not like having their user > name preempted.) > > AFAIK we have never preempted a user name, except for Anonymous, which > is only preempted in the anonymous.invalid domain. I'd much rather see a > special uri parameter to designate this behavior. > > Thanks, > Paul > > Hadriel Kaplan wrote: >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Friday, April 23, 2010 1:28 PM >>> >>> Making a decision based on the form of the R-URI presumes that non-ping >>> users of options never use an ip address as the R-URI. Requiring the >>> R-URI to be ping@ip reserves a user part, and also is just a sleazy way >>> of adding another indicator to the message to indicate its intended use. >> Actually in a weird way I think doing a specific username may be the right thing to do. Think about it from an email perspective. When you check on the status and settings of an email list using SMTP, do you (a) send a new different SMTP message type, or (b) address a normal message to the actual logical administrative code for the list? You send a normal message to userlist-request@emailserver.com. >> >> And logically the thing being "pinged" is a higher layer, because the response provides an administrative status as well. (even though in code one would probably do this at a low level) >> >> Put it another way: in theory you could send a SUBSCRIBE to this logical admin-UA in that proxy so that it Notifies you when it goes admin up/down. That logical UA is a resource in the proxy, and could be addressed as such. >> >> -hadriel >> > From HKaplan@acmepacket.com Mon Apr 26 10:04:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993C528C1F1 for ; Mon, 26 Apr 2010 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkYnGi103SP7 for ; Mon, 26 Apr 2010 10:04:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D675128C1B4 for ; Mon, 26 Apr 2010 09:59:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Apr 2010 12:59:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Apr 2010 12:59:41 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 26 Apr 2010 12:59:39 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrlP+OzuXUinO+lTB2l+ZmLEny5kAAHOmdA Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06C04F@mail> References: <4BD58D45.3000709@cisco.com> In-Reply-To: <4BD58D45.3000709@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: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:04:47 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 26, 2010 8:56 AM >=20 > Hadriel Kaplan wrote: > > "root" obviously. ;) > > But seriously, picking a crazy username that won't collide is not that > hard. The question is if it's the right thing to do. >=20 > I don't believe in reserving names from other people's namespaces after > the fact, on general principles. You cannot know how they use their > namespace. You can reduce the probability of collision by making the > value very obscure, but then it is very obscure. >=20 > So IMO it is the wrong thing to do. So you think it's the wrong thing to do NOT because indicating the specific= resource being targeted is the wrong thing, but rather that we can't safel= y pick a username??=20 There are solutions to that, for example: sip:80737871;phone-context=3Diana.org@proxy.com;user=3Dphone or this: urn:admin:ping But we could also bite the bullet and define a namespace concept for these = types of things, because ping is not the first or last time we'll need it. = For example a SUBSCRIBE to overload info, if we go that way for overload, = could use such a target resource identifier concept. As could draft-ietf-s= ipping-policy-package. -hadriel From HKaplan@acmepacket.com Mon Apr 26 10:21:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D343A3A6874 for ; Mon, 26 Apr 2010 10:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJXUpRB7SbDR for ; Mon, 26 Apr 2010 10:21:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 358973A6A2D for ; Mon, 26 Apr 2010 10:19:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Apr 2010 13:19:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Apr 2010 13:19:38 -0400 From: Hadriel Kaplan To: Christer Holmberg , Dean Willis Date: Mon, 26 Apr 2010 13:19:37 -0400 Thread-Topic: Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) Thread-Index: AcrlJm4nr8YntN9qTfqaT904lvaDnAABfomwAA1oqFA= Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Miller' , "Paul E. Jones" , "sipcore@ietf.org" , "'Michael@core3.amsl.com" <'Michael@core3.amsl.com> Subject: [sipcore] Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:21:13 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Monday, April 26, 2010 6:43 AM >=20 > Section 8.1.1.9 says: >=20 > "If the UAC wishes to insist that a UAS understand an extension that > the UAC will apply to the request in order to process the request, it > MUST insert a Require header field into the request listing the > option tag for that extension." >=20 > I think the "that the UAC will apply" could be read as indicating that th= e > UAC also supports the extension. Dean's point is that the Require does indeed mean the UA must support the e= xtension - but it does not mean it is *using* the extension nor even demand= ing the extension be used, for this particular transaction/dialog/whatever.= It's the header/param which indicates the actual usage, and the option-ta= g just says "you must understand the header or param". That way the proces= sing of the Require/Supported header fields can be handled separately from = whatever logic/layer handles the extension logic itself. We've had this debate before. :) We all agreed there were RFCs which used it to mean both "I understand" and= "I am using" the extension, and we wouldn't deprecate/change them. But I'= m not sure we ever agreed on what we'd do going forward. -hadriel From pkyzivat@cisco.com Mon Apr 26 10:21:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3D33A6874 for ; Mon, 26 Apr 2010 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.345 X-Spam-Level: X-Spam-Status: No, score=-10.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ680iVDQOTc for ; Mon, 26 Apr 2010 10:21:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CC73E28C1BC for ; Mon, 26 Apr 2010 10:20:01 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFto1UtAZnwM/2dsb2JhbACcPXGpJ5l+hQsE X-IronPort-AV: E=Sophos;i="4.52,274,1270425600"; d="scan'208";a="105174865" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2010 17:19:50 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3QHJn6L005877; Mon, 26 Apr 2010 17:19:49 GMT Message-ID: <4BD5CB2A.1040300@cisco.com> Date: Mon, 26 Apr 2010 13:19:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <4BD58D45.3000709@cisco.com> <430FC6BDED356B4C8498F634416644A91A7A06C04F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06C04F@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:21:21 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, April 26, 2010 8:56 AM >> >> Hadriel Kaplan wrote: >>> "root" obviously. ;) >>> But seriously, picking a crazy username that won't collide is not that >> hard. The question is if it's the right thing to do. >> >> I don't believe in reserving names from other people's namespaces after >> the fact, on general principles. You cannot know how they use their >> namespace. You can reduce the probability of collision by making the >> value very obscure, but then it is very obscure. >> >> So IMO it is the wrong thing to do. > > So you think it's the wrong thing to do NOT because indicating the specific resource being targeted is the wrong thing, but rather that we can't safely pick a username?? Yes. I have no problem, in principle, with having a class of "standard" resource names, as long as we came up with an acceptable way to define them without treading on anyone's toes. > There are solutions to that, for example: > sip:80737871;phone-context=iana.org@proxy.com;user=phone Yeah, that could work, but its really ugly. > or this: > urn:admin:ping That could work too, but then you couldn't use the R-URI for routing, so you would have to include a Route header to get it where you want it. Still, that might work. It could even fit within the existing service URN scheme. > But we could also bite the bullet and define a namespace concept for these types of things, because ping is not the first or last time we'll need it. For example a SUBSCRIBE to overload info, if we go that way for overload, could use such a target resource identifier concept. As could draft-ietf-sipping-policy-package. What did you have in mind? another URI parameter? E.g. sip:ping@bar.com;namespace=sipstuff That raises all sorts of ugly issues. I like the URN better. The URN mechanism defines namespaces. It won't collide with anything, and those that don't support it will (hopefully) just return 404 or 416. Then you can just be happy with the error, or simply fall back to a "normal" OPTIONS. But there are no doubt many other ways to skin this cat. Thanks, Paul From dean.willis@softarmor.com Mon Apr 26 10:23:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7902728C19E for ; Mon, 26 Apr 2010 10:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmiEhilMLuZk for ; Mon, 26 Apr 2010 10:23:11 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 32DA53A6A1F for ; Mon, 26 Apr 2010 10:21:19 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3QHJbir017977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 12:19:38 -0500 Message-Id: <2EE702F1-9E8A-4141-9EDF-57CC02526542@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BD58C85.80303@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 12:19:31 -0500 References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> <4BD222E4.9060309@cisco.com> <2DDA13E2-4954-41BA-B1FE-3A86A40E2175@softarmor.com> <4BD58C85.80303@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:23:21 -0000 On Apr 26, 2010, at 7:52 AM, Paul Kyzivat wrote: > Dean, > > The loss of parameters on retargeting is a valid issue in general, > and may be a reason not to use a parameter in this case. But it > isn't a problem for the use case contemplated because that case > doesn't expect there to be retargeting. How does it know? > > But haven't we decided to solve the uri parameter problem with H-I? We keep saying that. I haven't seen it work yet. I retain the opinion that it's a bad solution to the problem. -- Dean From pkyzivat@cisco.com Mon Apr 26 10:51:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8891528C1D6 for ; Mon, 26 Apr 2010 10:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.347 X-Spam-Level: X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M09GOtJDLR3n for ; Mon, 26 Apr 2010 10:51:42 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 243A628C203 for ; Mon, 26 Apr 2010 10:51:26 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGJv1UtAZnwM/2dsb2JhbACcP3GpbJoAhQsE X-IronPort-AV: E=Sophos;i="4.52,274,1270425600"; d="scan'208";a="105184151" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2010 17:51:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3QHpDmV016972; Mon, 26 Apr 2010 17:51:13 GMT Message-ID: <4BD5D292.4050409@cisco.com> Date: Mon, 26 Apr 2010 13:51:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com> <430FC6BDED356B4C8498F634416644A91A7A06BEF4@mail> <4BD222E4.9060309@cisco.com> <2DDA13E2-4954-41BA-B1FE-3A86A40E2175@softarmor.com> <4BD58C85.80303@cisco.com> <2EE702F1-9E8A-4141-9EDF-57CC02526542@softarmor.com> In-Reply-To: <2EE702F1-9E8A-4141-9EDF-57CC02526542@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:51:43 -0000 chair hat off: Dean Willis wrote: > > On Apr 26, 2010, at 7:52 AM, Paul Kyzivat wrote: > >> Dean, >> >> The loss of parameters on retargeting is a valid issue in general, and >> may be a reason not to use a parameter in this case. But it isn't a >> problem for the use case contemplated because that case doesn't expect >> there to be retargeting. > > How does it know? I should let him answer. My impression is either: - Max-Forwards:1 or - R-URI is ip address with no user part, and an *expectation* that this will not be redirected, or that if it is, then it isn't a use case of interest. >> But haven't we decided to solve the uri parameter problem with H-I? > > We keep saying that. I haven't seen it work yet. I retain the opinion > that it's a bad solution to the problem. Well, I don't like it either. Yet that *seems* to be the consensus. Thanks, Paul From christer.holmberg@ericsson.com Mon Apr 26 10:53:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C0C28C1DB for ; Mon, 26 Apr 2010 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=1.358, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY1PXy-IHYBO for ; Mon, 26 Apr 2010 10:53:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 34C1C28C1F0 for ; Mon, 26 Apr 2010 10:53:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-95-4bd5d308c52b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D4.DC.23532.803D5DB4; Mon, 26 Apr 2010 19:53:12 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 26 Apr 2010 19:53:12 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , Dean Willis Date: Mon, 26 Apr 2010 19:53:11 +0200 Thread-Topic: Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) Thread-Index: AcrlJm4nr8YntN9qTfqaT904lvaDnAABfomwAA1oqFAAARlw4A== Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Miller' , "Paul E. Jones" , "sipcore@ietf.org" , "'Michael@core3.amsl.com" <'Michael@core3.amsl.com> Subject: Re: [sipcore] Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:53:37 -0000 Hi,=20 >>Section 8.1.1.9 says: >>=20 >>"If the UAC wishes to insist that a UAS understand an extension that=20 >>the UAC will apply to the request in order to process the request, it=20 >>MUST insert a Require header field into the request listing the option=20 >>tag for that extension." >>=20 >>I think the "that the UAC will apply" could be read as indicating that=20 >>the UAC also supports the extension. > >Dean's point is that the Require does indeed mean the UA must support the = extension - but it does not mean it is *using* the extension nor even deman= ding the extension be used, for this particular=20 >transaction/dialog/whatever.=20 Yes, I know. >It's the header/param which indicates the actual usage, and the option-tag= just says "you must understand the header or param". That way the process= ing of the Require/Supported header fields can be=20 >handled separately from whatever logic/layer handles the extension logic i= tself. So, how does this work for 100rel? The INVITE request does not contain any = of the extension specific header fields (RSeq and RAck). They will be used = when the UAS starts using the extension. Yes, I know, you say we don't deprcate/change 100rel, but what if we have s= imilar extensions in the future, where the option-tag is the only thing you= initially send? >We've had this debate before. :) > >We all agreed there were RFCs which used it to mean both "I understand" an= d "I am using" the extension, and we wouldn't deprecate/change them. > >But I'm not sure we ever agreed on what we'd do going forward. It would be really good if we could document the outcome of such debates, r= ather than leaving them in an e-mail somewhere... Regards, Christer From HKaplan@acmepacket.com Mon Apr 26 11:03:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DA728C1F3 for ; Mon, 26 Apr 2010 11:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff6KlEUoZgLa for ; Mon, 26 Apr 2010 11:03:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D6EF53A6774 for ; Mon, 26 Apr 2010 11:03:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Apr 2010 14:02:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Apr 2010 14:02:50 -0400 From: Hadriel Kaplan To: Christer Holmberg Date: Mon, 26 Apr 2010 14:02:48 -0400 Thread-Topic: Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) Thread-Index: AcrlJm4nr8YntN9qTfqaT904lvaDnAABfomwAA1oqFAAARlw4AAAyk0Q Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06C088@mail> References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:03:04 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, April 26, 2010 1:53 PM >=20 > So, how does this work for 100rel? The INVITE request does not contain an= y > of the extension specific header fields (RSeq and RAck). They will be use= d > when the UAS starts using the extension. >=20 > Yes, I know, you say we don't deprcate/change 100rel, but what if we have > similar extensions in the future, where the option-tag is the only thing > you initially send? We would make sure they don't just send an option-tag only. In some cases = this would just mean a placebo header gets defined and used, like for RFC 4= 488 norefersub where a "Refer-Sub: false" is used. -hadriel From pkyzivat@cisco.com Mon Apr 26 11:09:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1AB3A68DD for ; Mon, 26 Apr 2010 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVHpIWYEy46K for ; Mon, 26 Apr 2010 11:09:30 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 261BB28C1E4 for ; Mon, 26 Apr 2010 11:09:13 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACF01UtAZnwM/2dsb2JhbACcQXGqDZoJhQsE X-IronPort-AV: E=Sophos;i="4.52,274,1270425600"; d="scan'208";a="105332013" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2010 18:07:24 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3QI7Oj0026222; Mon, 26 Apr 2010 18:07:24 GMT Message-ID: <4BD5D65D.5010204@cisco.com> Date: Mon, 26 Apr 2010 14:07:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' , "'Michael@core3.amsl.com" <'Michael@core3.amsl.com>, "Paul E. Jones" Subject: Re: [sipcore] Semantics of option-tags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:09:34 -0000 Christer Holmberg wrote: > Hi, > >>> Section 8.1.1.9 says: >>> >>> "If the UAC wishes to insist that a UAS understand an extension that >>> the UAC will apply to the request in order to process the request, it >>> MUST insert a Require header field into the request listing the option >>> tag for that extension." >>> >>> I think the "that the UAC will apply" could be read as indicating that >>> the UAC also supports the extension. >> Dean's point is that the Require does indeed mean the UA must support the extension - but it does not mean it is *using* the extension nor even demanding the extension be used, for this particular >> transaction/dialog/whatever. > > Yes, I know. > >> It's the header/param which indicates the actual usage, and the option-tag just says "you must understand the header or param". That way the processing of the Require/Supported header fields can be >> handled separately from whatever logic/layer handles the extension logic itself. > > So, how does this work for 100rel? The INVITE request does not contain any of the extension specific header fields (RSeq and RAck). They will be used when the UAS starts using the extension. 100rel botched it, so now its grandfathered. > Yes, I know, you say we don't deprcate/change 100rel, but what if we have similar extensions in the future, where the option-tag is the only thing you initially send? If we have similar things in the future, then shame on us for approving them. >> We've had this debate before. :) >> >> We all agreed there were RFCs which used it to mean both "I understand" and "I am using" the extension, and we wouldn't deprecate/change them. >> >> But I'm not sure we ever agreed on what we'd do going forward. > > It would be really good if we could document the outcome of such debates, rather than leaving them in an e-mail somewhere... Yes, it would be good. Where would you propose to put it? Is it a problem we need to solve? Or do we already have it under control for future options. Thanks, Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gao.yang2@zte.com.cn Mon Apr 26 21:07:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851CA28C1DA for ; Mon, 26 Apr 2010 21:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.806 X-Spam-Level: X-Spam-Status: No, score=-98.806 tagged_above=-999 required=5 tests=[AWL=2.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeNvWQJgFvjB for ; Mon, 26 Apr 2010 21:07:58 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 28C373A6AD5 for ; Mon, 26 Apr 2010 21:06:57 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Tue, 27 Apr 2010 12:02:59 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.5143419512; Tue, 27 Apr 2010 12:06:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3R44VjD017223; Tue, 27 Apr 2010 12:04:44 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4BD58A77.2090109@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 27 Apr 2010 12:02:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-27 12:04:38, Serialize complete at 2010-04-27 12:04:38 Content-Type: multipart/alternative; boundary="=_alternative 00165E6E48257712_=" X-MAIL: mse2.zte.com.cn o3R44VjD017223 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] The semantics of Require. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 04:07:59 -0000 This is a multipart message in MIME format. --=_alternative 00165E6E48257712_= Content-Type: text/plain; charset="US-ASCII" Hi Paul, Yes. Under semantic analysis, Require(from UAC) only means the demand of UAS's capability. To expressing the semantics of demanding UAS's specific behavior (in specific conditions) needs something new. Relating, if UAS want the UAC's specific behavior (in specific conditions) should use the same *new header*, Require is not proper. So, Require 100rel from both UAC and UAS is misapplication. And it seams that we should clarify that we haven't had tool with the semantics of demanding the peer's specific behavior (in specific conditions). But I prefer there's no correction for RFC3262 just for this reason. Thanks, Gao > If this discussion is to continue, can we at least have a relevant > subject rather than hijacking the discussion options ping? > > I agree in principle with Dean's point. But from a practical perspective > I think we just acknowledge that the definition of certain options added > on additional semantics. I think we should just grandfather that but > refrain from making the same mistake in the future. > > Thanks, > Paul > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00165E6E48257712_= Content-Type: text/html; charset="US-ASCII"
Hi Paul,

Yes. Under semantic analysis, Require(from UAC) only means the demand of UAS's capability.

To expressing the semantics of demanding UAS's specific behavior (in specific conditions) needs something new. Relating, if UAS want the UAC's specific behavior (in specific conditions) should use the same *new header*, Require is not proper. So, Require 100rel from both UAC and UAS is misapplication.

And it seams that we should clarify that we haven't had tool with the semantics of demanding the peer's specific behavior (in specific conditions). But I prefer there's no correction for RFC3262 just for this reason.

Thanks,

Gao  

> If this discussion is to continue, can we at least have a relevant
> subject rather than hijacking the discussion options ping?
>
> I agree in principle with Dean's point. But from a practical perspective
> I think we just acknowledge that the definition of certain options added
> on additional semantics. I think we should just grandfather that but
> refrain from making the same mistake in the future.
>
>    Thanks,
>    Paul
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00165E6E48257712_=-- From gao.yang2@zte.com.cn Mon Apr 26 21:56:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC07428C23A for ; Mon, 26 Apr 2010 21:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.892 X-Spam-Level: X-Spam-Status: No, score=-96.892 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vra3jP0aafBK for ; Mon, 26 Apr 2010 21:56:30 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 847883A67AC for ; Mon, 26 Apr 2010 21:55:32 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Tue, 27 Apr 2010 12:51:58 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.5143419512; Tue, 27 Apr 2010 12:55:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o3R4t5At078122; Tue, 27 Apr 2010 12:55:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 27 Apr 2010 12:53:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-27 12:54:58, Serialize complete at 2010-04-27 12:54:58 Content-Type: multipart/alternative; boundary="=_alternative 001AFB8948257712_=" X-MAIL: mse2.zte.com.cn o3R4t5At078122 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] The semantics of Require. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 04:56:31 -0000 This is a multipart message in MIME format. --=_alternative 001AFB8948257712_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlJ3Mgb25lIGV4Y2VwdGlvbiBvZiBteSBhbmFseXNpcy4gVGhhdCBpcyB0aGUg b3B0aW9uLXRhZydzIGRlZmluaXRpb24gDQppdHNlbGYgaGFzIGJlaGF2aW9yIHNwZWNpZmljYXRp b24uDQoNClRoZW4gSSByZS1yZWFkIDEwMHJlbCdzIGRlZmluaXRpb24uIEl0IHNlZW1zIGlzIGlu IHRoaXMgY2xhc3MuIA0KDQpOYW1lOiAxMDByZWwNCg0KICAgICAgRGVzY3JpcHRpb246IFRoaXMg b3B0aW9uIHRhZyBpcyBmb3IgcmVsaWFiaWxpdHkgb2YgcHJvdmlzaW9uYWwNCiAgICAgICAgIHJl c3BvbnNlcy4gIFdoZW4gcHJlc2VudCBpbiBhIFN1cHBvcnRlZCBoZWFkZXIsIGl0IGluZGljYXRl cw0KICAgICAgICAgdGhhdCB0aGUgVUEgY2FuIHNlbmQgb3IgcmVjZWl2ZSByZWxpYWJsZSBwcm92 aXNpb25hbCByZXNwb25zZXMuDQogICAgICAgICBXaGVuIHByZXNlbnQgaW4gYSBSZXF1aXJlIGhl YWRlciBpbiBhIHJlcXVlc3QsIGl0IGluZGljYXRlcw0KICAgICAgICAgdGhhdCB0aGUgVUFTIE1V U1Qgc2VuZCBhbGwgcHJvdmlzaW9uYWwgcmVzcG9uc2VzIHJlbGlhYmx5Lg0KICAgICAgICAgV2hl biBwcmVzZW50IGluIGEgUmVxdWlyZSBoZWFkZXIgaW4gYSByZWxpYWJsZSBwcm92aXNpb25hbA0K ICAgICAgICAgcmVzcG9uc2UsIGl0IGluZGljYXRlcyB0aGF0IHRoZSByZXNwb25zZSBpcyB0byBi ZSBzZW50DQogICAgICAgICByZWxpYWJseS4NCg0KSXQgaXMgYSBtZXNzIGZyb20gZGVmaW50aW9u IGFzcGVjdC4gQnV0IGl0IG1pZ2h0IGJlIHJpZ2h0Lg0KDQpUaGFua3MsDQoNCkdhbyANCg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwg ICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlh bmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0t LSDXqreiyMsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQgyrG85CAyMDEwLTA0LTI3IDEyOjE2 IC0tLS0tDQoNCkdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkDQoyMDEwLTA0LTI3IDEyOjAyDQoN CsrVvP7Iyw0KUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBjaXNjby5jb20+DQqzrcvNDQpDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgInNpcGNvcmVAaWV0 Zi5vcmciIA0KPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpSZTogW3NpcGNvcmVdIFRoZSBzZW1h bnRpY3Mgb2YgUmVxdWlyZS4NCg0KDQoNCg0KDQoNCkhpIFBhdWwsDQoNClllcy4gVW5kZXIgc2Vt YW50aWMgYW5hbHlzaXMsIFJlcXVpcmUoZnJvbSBVQUMpIG9ubHkgbWVhbnMgdGhlIGRlbWFuZCBv ZiANClVBUydzIGNhcGFiaWxpdHkuDQoNClRvIGV4cHJlc3NpbmcgdGhlIHNlbWFudGljcyBvZiBk ZW1hbmRpbmcgVUFTJ3Mgc3BlY2lmaWMgYmVoYXZpb3IgKGluIA0Kc3BlY2lmaWMgY29uZGl0aW9u cykgbmVlZHMgc29tZXRoaW5nIG5ldy4gUmVsYXRpbmcsIGlmIFVBUyB3YW50IHRoZSBVQUMncyAN CnNwZWNpZmljIGJlaGF2aW9yIChpbiBzcGVjaWZpYyBjb25kaXRpb25zKSBzaG91bGQgdXNlIHRo ZSBzYW1lICpuZXcgDQpoZWFkZXIqLCBSZXF1aXJlIGlzIG5vdCBwcm9wZXIuIFNvLCBSZXF1aXJl IDEwMHJlbCBmcm9tIGJvdGggVUFDIGFuZCBVQVMgDQppcyBtaXNhcHBsaWNhdGlvbi4NCg0KQW5k IGl0IHNlYW1zIHRoYXQgd2Ugc2hvdWxkIGNsYXJpZnkgdGhhdCB3ZSBoYXZlbid0IGhhZCB0b29s IHdpdGggdGhlIA0Kc2VtYW50aWNzIG9mIGRlbWFuZGluZyB0aGUgcGVlcidzIHNwZWNpZmljIGJl aGF2aW9yIChpbiBzcGVjaWZpYyANCmNvbmRpdGlvbnMpLiBCdXQgSSBwcmVmZXIgdGhlcmUncyBu byBjb3JyZWN0aW9uIGZvciBSRkMzMjYyIGp1c3QgZm9yIHRoaXMgDQpyZWFzb24uDQoNClRoYW5r cywNCg0KR2FvIA0KDQo+IElmIHRoaXMgZGlzY3Vzc2lvbiBpcyB0byBjb250aW51ZSwgY2FuIHdl IGF0IGxlYXN0IGhhdmUgYSByZWxldmFudCANCj4gc3ViamVjdCByYXRoZXIgdGhhbiBoaWphY2tp bmcgdGhlIGRpc2N1c3Npb24gb3B0aW9ucyBwaW5nPw0KPiANCj4gSSBhZ3JlZSBpbiBwcmluY2lw bGUgd2l0aCBEZWFuJ3MgcG9pbnQuIEJ1dCBmcm9tIGEgcHJhY3RpY2FsIHBlcnNwZWN0aXZlIA0K DQo+IEkgdGhpbmsgd2UganVzdCBhY2tub3dsZWRnZSB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIGNl cnRhaW4gb3B0aW9ucyBhZGRlZCANCg0KPiBvbiBhZGRpdGlvbmFsIHNlbWFudGljcy4gSSB0aGlu ayB3ZSBzaG91bGQganVzdCBncmFuZGZhdGhlciB0aGF0IGJ1dCANCj4gcmVmcmFpbiBmcm9tIG1h a2luZyB0aGUgc2FtZSBtaXN0YWtlIGluIHRoZSBmdXR1cmUuDQo+IA0KPiAgICBUaGFua3MsDQo+ ICAgIFBhdWwNCj4gDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001AFB8948257712_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlcmUncyBvbmUgZXhjZXB0aW9uIG9m IG15IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPmFuYWx5c2lzPC9mb250PjwvdHQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi4NClRoYXQgaXMgPGI+dGhlIG9wdGlvbi10YWcncyBkZWZp bml0aW9uIGl0c2VsZiBoYXMgYmVoYXZpb3Igc3BlY2lmaWNhdGlvbjwvYj4uPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVuIEkgcmUtcmVhZCAxMDBy ZWwncyBkZWZpbml0aW9uLg0KSXQgc2VlbXMgaXMgaW4gdGhpcyBjbGFzcy4gPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+TmFtZTogMTAwcmVsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgRGVzY3JpcHRpb246IFRoaXMNCm9wdGlvbiB0YWcgaXMgZm9yIHJlbGlhYmlsaXR5 IG9mIHByb3Zpc2lvbmFsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Jlc3BvbnNlcy4NCiZuYnNwO1do ZW4gcHJlc2VudCBpbiBhIFN1cHBvcnRlZCBoZWFkZXIsIGl0IGluZGljYXRlczwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0aGF0DQp0aGUgVUEgY2FuIHNlbmQgb3IgcmVjZWl2ZSByZWxpYWJsZSBwcm92 aXNpb25hbCByZXNwb25zZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doZW4NCnByZXNlbnQgaW4g YSBSZXF1aXJlIGhlYWRlciBpbiBhIHJlcXVlc3QsIGl0IGluZGljYXRlczwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt0aGF0DQp0aGUgVUFTIE1VU1Qgc2VuZCBhbGwgcHJvdmlzaW9uYWwgcmVzcG9uc2Vz IHJlbGlhYmx5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGVuDQpwcmVzZW50IGluIGEgUmVxdWly ZSBoZWFkZXIgaW4gYSByZWxpYWJsZSBwcm92aXNpb25hbDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDty ZXNwb25zZSwNCml0IGluZGljYXRlcyB0aGF0IHRoZSByZXNwb25zZSBpcyB0byBiZSBzZW50PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3JlbGlhYmx5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+SXQgaXMgYSBtZXNzIGZyb20gZGVmaW50aW9uIGFzcGVjdC4N CkJ1dCBpdCBtaWdodCBiZSByaWdodC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkdhbyAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3 MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNl cmlmIj4tLS0tLSDXqreiyMsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQNCsqxvOQgMjAxMC0w NC0yNyAxMjoxNiAtLS0tLTwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5HYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZDwvYj48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNC0yNyAxMjowMjwvZm9udD4NCjx0ZCB3aWR0aD01OSU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5QYXVsIEt5eml2YXQgJmx0O3BreXpp dmF0QGNpc2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkNocmlzdGVyIEhvbG1iZXJnICZs dDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7LA0KJnF1b3Q7c2lwY29yZUBpZXRm Lm9yZyZxdW90OyAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbc2lwY29yZV0gVGhlIHNlbWFudGljcyBvZiBSZXF1aXJlLjwvZm9udD48YSBocmVmPU5vdGVz Oi8vTkpNQUlMMDEvNDgyNTcxNjkwMDJERjhFRS9EQUJBOTc1QjlGQjExM0VCODUyNTY0QjUwMDEy ODNFQS8xRkU3MDAxOUJEQTM0RTI3NDgyNTc3MTEwMDQ1QzIwNT7BtL3TPC9hPjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBQYXVsLDwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WWVzLiBVbmRlciBzZW1hbnRpYyBhbmFs eXNpcywgUmVxdWlyZShmcm9tIFVBQykgb25seQ0KbWVhbnMgdGhlIGRlbWFuZCBvZiBVQVMncyBj YXBhYmlsaXR5LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VG8gZXhw cmVzc2luZyB0aGUgc2VtYW50aWNzIG9mIGRlbWFuZGluZyBVQVMncyBzcGVjaWZpYw0KYmVoYXZp b3IgKGluIHNwZWNpZmljIGNvbmRpdGlvbnMpIG5lZWRzIHNvbWV0aGluZyBuZXcuIFJlbGF0aW5n LCBpZiBVQVMNCndhbnQgdGhlIFVBQydzIHNwZWNpZmljIGJlaGF2aW9yIChpbiBzcGVjaWZpYyBj b25kaXRpb25zKSBzaG91bGQgdXNlIHRoZQ0Kc2FtZSAqbmV3IGhlYWRlciosIFJlcXVpcmUgaXMg bm90IHByb3Blci4gU28sIFJlcXVpcmUgMTAwcmVsIGZyb20gYm90aA0KVUFDIGFuZCBVQVMgaXMg bWlzYXBwbGljYXRpb24uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5B bmQgaXQgc2VhbXMgdGhhdCB3ZSBzaG91bGQgY2xhcmlmeSB0aGF0IHdlIGhhdmVuJ3QNCmhhZCB0 b29sIHdpdGggPGI+dGhlIHNlbWFudGljcyBvZiBkZW1hbmRpbmcgdGhlIHBlZXIncyBzcGVjaWZp YyBiZWhhdmlvcg0KKGluIHNwZWNpZmljIGNvbmRpdGlvbnMpPC9iPi4gQnV0IEkgcHJlZmVyIHRo ZXJlJ3Mgbm8gY29ycmVjdGlvbiBmb3IgUkZDMzI2Mg0KanVzdCBmb3IgdGhpcyByZWFzb24uPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5HYW8gJm5ic3A7PGJyPg0KPGJyPg0KJmd0OyBJ ZiB0aGlzIGRpc2N1c3Npb24gaXMgdG8gY29udGludWUsIGNhbiB3ZSBhdCBsZWFzdCBoYXZlIGEg cmVsZXZhbnQNCjxicj4NCiZndDsgc3ViamVjdCByYXRoZXIgdGhhbiBoaWphY2tpbmcgdGhlIGRp c2N1c3Npb24gb3B0aW9ucyBwaW5nPzxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFncmVlIGluIHBy aW5jaXBsZSB3aXRoIERlYW4ncyBwb2ludC4gQnV0IGZyb20gYSBwcmFjdGljYWwgcGVyc3BlY3Rp dmUNCjxicj4NCiZndDsgSSB0aGluayB3ZSBqdXN0IGFja25vd2xlZGdlIHRoYXQgdGhlIGRlZmlu aXRpb24gb2YgY2VydGFpbiBvcHRpb25zDQphZGRlZCA8YnI+DQomZ3Q7IG9uIGFkZGl0aW9uYWwg c2VtYW50aWNzLiBJIHRoaW5rIHdlIHNob3VsZCBqdXN0IGdyYW5kZmF0aGVyIHRoYXQgYnV0DQo8 YnI+DQomZ3Q7IHJlZnJhaW4gZnJvbSBtYWtpbmcgdGhlIHNhbWUgbWlzdGFrZSBpbiB0aGUgZnV0 dXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhhbmtzLDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO1BhdWw8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 001AFB8948257712_=-- From christer.holmberg@ericsson.com Tue Apr 27 04:54:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97483A68FE for ; Tue, 27 Apr 2010 04:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.25 X-Spam-Level: X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEyfD+0S5i+0 for ; Tue, 27 Apr 2010 04:54:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 70F0C3A6968 for ; Tue, 27 Apr 2010 04:53:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-30-4bd6d049ad3b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id EA.C1.23532.940D6DB4; Tue, 27 Apr 2010 13:53:45 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 27 Apr 2010 13:53:45 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Tue, 27 Apr 2010 13:53:45 +0200 Thread-Topic: Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) Thread-Index: AcrlJm4nr8YntN9qTfqaT904lvaDnAABfomwAA1oqFAAARlw4AAAyk0QACVYaPc= Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> , <430FC6BDED356B4C8498F634416644A91A7A06C088@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06C088@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Semantics of option-tags (was:draft-jones-sip-options-ping-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 11:54:17 -0000 Hi, >> So, how does this work for 100rel? The INVITE request does not contain a= ny >> of the extension specific header fields (RSeq and RAck). They will be us= ed >> when the UAS starts using the extension. >> >> Yes, I know, you say we don't deprcate/change 100rel, but what if we hav= e >> similar extensions in the future, where the option-tag is the only thing >> you initially send? > >We would make sure they don't just send an option-tag only. In some cases= this would just mean a placebo header gets defined and used, like for RFC = 4488 norefersub where a "Refer-Sub: false" is used. In many cases the extension does have associated information elements (head= er fields, SDP parameters etc), but they still don't say anything about whe= ther the receiver should use the required extension or not. They simply pro= vide additional information associated with the extension. Preconditions is= a good example. I just wonder why a UA would require support of some extension, if it doesn= 't also require the usage of it... Exactly HOW it is then used can of cours= e depend on header field values etc. Regards, Christer= From christer.holmberg@ericsson.com Tue Apr 27 05:03:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DBF3A6987 for ; Tue, 27 Apr 2010 05:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoZ8NH8OVCcV for ; Tue, 27 Apr 2010 05:03:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 757DA3A6982 for ; Tue, 27 Apr 2010 05:03:45 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-15-4bd6d293a443 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 98.4F.23740.392D6DB4; Tue, 27 Apr 2010 14:03:31 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 27 Apr 2010 14:03:31 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 27 Apr 2010 14:03:31 +0200 Thread-Topic: [sipcore] Semantics of option-tags Thread-Index: Acrla454EviiQ/R9Rr2OzxT7amhVnAAlMc4O Message-ID: References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> , <4BD5D65D.5010204@cisco.com> In-Reply-To: <4BD5D65D.5010204@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: Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' , "'Michael@core3.amsl.com" <'Michael@core3.amsl.com>, "Paul E. Jones" Subject: Re: [sipcore] Semantics of option-tags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 12:03:49 -0000 Hi, >>Yes, I know, you say we don't deprcate/change 100rel, but what if we have= similar extensions in the future, where the option-tag is the only thing y= ou initially send? > >If we have similar things in the future, then shame on us for approving th= em. Yes, but "we" (referring to the people active in the WG at this point) will= not be here forever. This should be clear also to people defining SIP exte= nsion in 100 years from now :) In addition, even if we are not going to change existing extensions, I am n= ot sure all of them are very clear on what Require really means. Maybe some= of the assume that Require also indciates UAC support, but it is not state= d anywhere. So, I guess we would need to check that. >>>We've had this debate before. :) >>> >>>We all agreed there were RFCs which used it to mean both "I understand" = and "I am using" the extension, and we wouldn't deprecate/change them. >>> >>>But I'm not sure we ever agreed on what we'd do going forward. >> >>It would be really good if we could document the outcome of such debates,= rather than leaving them in an e-mail somewhere... > >Yes, it would be good. Where would you propose to put it? > >Is it a problem we need to solve? Or do we already have it under control f= or future options. There are two things we need to consider: 1. Even if "we" have it under control - is it clearly enough specified? 2. As described above, even if we won't change the meaning of Require in ex= isting extensions, is it always clear what Require actually means in those = extensions? Regards, Christer= From pkyzivat@cisco.com Tue Apr 27 06:46:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4264F28C0F0 for ; Tue, 27 Apr 2010 06:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.346 X-Spam-Level: X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKJxhdAZUnKs for ; Tue, 27 Apr 2010 06:46:04 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CAC743A6A81 for ; Tue, 27 Apr 2010 06:45:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALOH1ktAZnwN/2dsb2JhbACcTXGmPpoghQ4E X-IronPort-AV: E=Sophos;i="4.52,280,1270425600"; d="scan'208";a="105513024" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2010 13:45:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3RDjRWa010462; Tue, 27 Apr 2010 13:45:27 GMT Message-ID: <4BD6EA76.7000003@cisco.com> Date: Tue, 27 Apr 2010 09:45:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> , <430FC6BDED356B4C8498F634416644A91A7A06C088@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] Semantics of option-tags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 13:46:05 -0000 Christer Holmberg wrote: > Hi, > >>> So, how does this work for 100rel? The INVITE request does not contain any >>> of the extension specific header fields (RSeq and RAck). They will be used >>> when the UAS starts using the extension. >>> >>> Yes, I know, you say we don't deprcate/change 100rel, but what if we have >>> similar extensions in the future, where the option-tag is the only thing >>> you initially send? >> We would make sure they don't just send an option-tag only. In some cases this would just mean a placebo header gets defined and used, like for RFC 4488 norefersub where a "Refer-Sub: false" is used. > > In many cases the extension does have associated information elements (header fields, SDP parameters etc), but they still don't say anything about whether the receiver should use the required extension or not. They simply provide additional information associated with the extension. Preconditions is a good example. > > I just wonder why a UA would require support of some extension, if it doesn't also require the usage of it... Exactly HOW it is then used can of course depend on header field values etc. Well, the simplest case of this is when "support" means ability/willingness to receive and act upon something in a message. In that case the UAC might Require that because it *might* need to send something that requires it. OTOH the circumstance where it would send that might never come up, and so the required support may never be employed. Another case might be a conflict between capability and policy. The UAS might be capable of supporting some option, but unwilling to do so, in some circumstances, due to policy. It thus may have to wait until the circumstances where the option would be used to evaluate the policy and decide what to do. Thanks, Paul From pkyzivat@cisco.com Tue Apr 27 06:50:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14963A69CF for ; Tue, 27 Apr 2010 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vndPm2-ajSMD for ; Tue, 27 Apr 2010 06:50:40 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6646F3A6A66 for ; Tue, 27 Apr 2010 06:50:30 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKKI1ktAZnwN/2dsb2JhbACcTXGmWZoghQ4E X-IronPort-AV: E=Sophos;i="4.52,280,1270425600"; d="scan'208";a="105654501" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 13:50:17 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3RDoHor012509; Tue, 27 Apr 2010 13:50:17 GMT Message-ID: <4BD6EB98.9000701@cisco.com> Date: Tue, 27 Apr 2010 09:50:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <02a301cae2fc$639733d0$2ac59b70$@com> <32A7449E-341E-4B0D-B0C9-5F95731C2F2B@softarmor.com> <02c001cae306$45e49e40$d1addac0$@com> <4BD1D895.8030900@cisco.com>, <50D76842-FE81-4AEC-ADD7-D3039D3A491F@softarmor.com> , , <20F20E85-AB18-40CB-9AB8-76F19D849A8E@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C058@mail> , <4BD5D65D.5010204@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' , "'Michael@core3.amsl.com" <'Michael@core3.amsl.com>, "Paul E. Jones" Subject: Re: [sipcore] Semantics of option-tags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 13:50:41 -0000 Christer, I expect you know by now that my inclination is to carefully "dot every 'i' and cross every 't'", so philosophically I am entirely with you. But from a practical perspective I see this as a very low priority issue. If we happen to be doing something else that we could reasonably piggy back this on, then I would go for it. But I can't get very worked up over initiating an effort specifically to do this. Thanks, Paul Christer Holmberg wrote: > Hi, > >>> Yes, I know, you say we don't deprcate/change 100rel, but what if we have similar extensions in the future, where the option-tag is the only thing you initially send? >> If we have similar things in the future, then shame on us for approving them. > > Yes, but "we" (referring to the people active in the WG at this point) will not be here forever. This should be clear also to people defining SIP extension in 100 years from now :) > > In addition, even if we are not going to change existing extensions, I am not sure all of them are very clear on what Require really means. Maybe some of the assume that Require also indciates UAC support, but it is not stated anywhere. So, I guess we would need to check that. > >>>> We've had this debate before. :) >>>> >>>> We all agreed there were RFCs which used it to mean both "I understand" and "I am using" the extension, and we wouldn't deprecate/change them. >>>> >>>> But I'm not sure we ever agreed on what we'd do going forward. >>> It would be really good if we could document the outcome of such debates, rather than leaving them in an e-mail somewhere... >> Yes, it would be good. Where would you propose to put it? >> >> Is it a problem we need to solve? Or do we already have it under control for future options. > > There are two things we need to consider: > > 1. Even if "we" have it under control - is it clearly enough specified? > > 2. As described above, even if we won't change the meaning of Require in existing extensions, is it always clear what Require actually means in those extensions? > > Regards, > > Christer From paulej@packetizer.com Tue Apr 27 12:39:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2CE3A68E1 for ; Tue, 27 Apr 2010 12:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb5q2uUBVWgl for ; Tue, 27 Apr 2010 12:39:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id DFB9A3A6A07 for ; Tue, 27 Apr 2010 12:39:36 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3RJdE6x005816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Apr 2010 15:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272397160; bh=ljngGd39/bK1NR3b4QpCD+d8HM9Av380vcY+aCCP/OU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qxuRgslTIPXr4YrdaPz7cx/7D6RRlV5BUhWQJKnEuj98pddmH5qY/ROvQOK3Rf8WJ 1P/eE1nwQkqzu/bFiAtTIFEyhHZeXMrM/8CY52tkChcRSdYWnaPS+Y6wLSdNQTFNxg O4N5C5w63bjhrEEkc4vGPKimmKT6uWBtA4CNbIeA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3RJdDjc017416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Apr 2010 15:39:14 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Hadriel Kaplan'" References: <4BD58D45.3000709@cisco.com> In-Reply-To: <4BD58D45.3000709@cisco.com> Date: Tue, 27 Apr 2010 15:39:09 -0400 Message-ID: <004f01cae641$4e690a90$eb3b1fb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrlP8aIzfuGROhmTIen9U2EzICceQBAVNww Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:39:40 -0000 I don't think we should reserve a name. Use of options "ping" should be between two devices that have some kind of established relationship and the "ping" address should be known only locally. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 26, 2010 8:56 AM > To: Hadriel Kaplan > Cc: Paul E. Jones; 'Michael Miller'; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > > > Hadriel Kaplan wrote: > > "root" obviously. ;) > > But seriously, picking a crazy username that won't collide is not > that hard. The question is if it's the right thing to do. > > I don't believe in reserving names from other people's namespaces after > the fact, on general principles. You cannot know how they use their > namespace. You can reduce the probability of collision by making the > value very obscure, but then it is very obscure. > > So IMO it is the wrong thing to do. > > Thanks, > Paul > > > Paul Kyzivat wrote: > > > > > > I will grant you that having per-user policies for what to include in > > OPTIONS would be possible. > > > > But using that approach here means reserving a specific username. > Which > > one are we allowed to pick that won't impact somebody? (I expect > there > > are people out there named "ping" who might not like having their > user > > name preempted.) > > > > AFAIK we have never preempted a user name, except for Anonymous, > which > > is only preempted in the anonymous.invalid domain. I'd much rather > see a > > special uri parameter to designate this behavior. > > > > Thanks, > > Paul > > > > Hadriel Kaplan wrote: > >>> -----Original Message----- > >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: Friday, April 23, 2010 1:28 PM > >>> > >>> Making a decision based on the form of the R-URI presumes that non- > ping > >>> users of options never use an ip address as the R-URI. Requiring > the > >>> R-URI to be ping@ip reserves a user part, and also is just a sleazy > way > >>> of adding another indicator to the message to indicate its intended > use. > >> Actually in a weird way I think doing a specific username may be the > right thing to do. Think about it from an email perspective. When you > check on the status and settings of an email list using SMTP, do you > (a) send a new different SMTP message type, or (b) address a normal > message to the actual logical administrative code for the list? You > send a normal message to userlist-request@emailserver.com. > >> > >> And logically the thing being "pinged" is a higher layer, because > the response provides an administrative status as well. (even though in > code one would probably do this at a low level) > >> > >> Put it another way: in theory you could send a SUBSCRIBE to this > logical admin-UA in that proxy so that it Notifies you when it goes > admin up/down. That logical UA is a resource in the proxy, and could > be addressed as such. > >> > >> -hadriel > >> > > > From pkyzivat@cisco.com Tue Apr 27 12:51:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E673A6B6A for ; Tue, 27 Apr 2010 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZq2hM90pxIl for ; Tue, 27 Apr 2010 12:51:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8E59F3A6B76 for ; Tue, 27 Apr 2010 12:50:06 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA3d1ktAZnwM/2dsb2JhbACcUnGnJJoWgnMMgg8E X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105642591" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2010 19:49:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RJnrhK012638; Tue, 27 Apr 2010 19:49:53 GMT Message-ID: <4BD73FE1.7050105@cisco.com> Date: Tue, 27 Apr 2010 15:49:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> In-Reply-To: <004f01cae641$4e690a90$eb3b1fb0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:51:45 -0000 Paul E. Jones wrote: > I don't think we should reserve a name. Use of options "ping" should be > between two devices that have some kind of established relationship and the > "ping" address should be known only locally. IIUC, you are saying that any specific options-ping behavior should be the result of *configuration* of the UAC and UAS. And then can I infer that recognition that in incoming OPIONS is a ping would be based on source address and/or use of a "special" address that is configured into the UAC rather than reserved. Is that right? Thanks, Paul (K) > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, April 26, 2010 8:56 AM >> To: Hadriel Kaplan >> Cc: Paul E. Jones; 'Michael Miller'; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >> >> >> >> Hadriel Kaplan wrote: >>> "root" obviously. ;) >>> But seriously, picking a crazy username that won't collide is not >> that hard. The question is if it's the right thing to do. >> >> I don't believe in reserving names from other people's namespaces after >> the fact, on general principles. You cannot know how they use their >> namespace. You can reduce the probability of collision by making the >> value very obscure, but then it is very obscure. >> >> So IMO it is the wrong thing to do. >> >> Thanks, >> Paul >> >>> Paul Kyzivat wrote: >>> >>> >>> I will grant you that having per-user policies for what to include in >>> OPTIONS would be possible. >>> >>> But using that approach here means reserving a specific username. >> Which >>> one are we allowed to pick that won't impact somebody? (I expect >> there >>> are people out there named "ping" who might not like having their >> user >>> name preempted.) >>> >>> AFAIK we have never preempted a user name, except for Anonymous, >> which >>> is only preempted in the anonymous.invalid domain. I'd much rather >> see a >>> special uri parameter to designate this behavior. >>> >>> Thanks, >>> Paul >>> >>> Hadriel Kaplan wrote: >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Friday, April 23, 2010 1:28 PM >>>>> >>>>> Making a decision based on the form of the R-URI presumes that non- >> ping >>>>> users of options never use an ip address as the R-URI. Requiring >> the >>>>> R-URI to be ping@ip reserves a user part, and also is just a sleazy >> way >>>>> of adding another indicator to the message to indicate its intended >> use. >>>> Actually in a weird way I think doing a specific username may be the >> right thing to do. Think about it from an email perspective. When you >> check on the status and settings of an email list using SMTP, do you >> (a) send a new different SMTP message type, or (b) address a normal >> message to the actual logical administrative code for the list? You >> send a normal message to userlist-request@emailserver.com. >>>> And logically the thing being "pinged" is a higher layer, because >> the response provides an administrative status as well. (even though in >> code one would probably do this at a low level) >>>> Put it another way: in theory you could send a SUBSCRIBE to this >> logical admin-UA in that proxy so that it Notifies you when it goes >> admin up/down. That logical UA is a resource in the proxy, and could >> be addressed as such. >>>> -hadriel >>>> > > > From christer.holmberg@ericsson.com Tue Apr 27 13:00:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC423A696A for ; Tue, 27 Apr 2010 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.246 X-Spam-Level: X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=1.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sbBCJtdfImm for ; Tue, 27 Apr 2010 13:00:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0AEA73A69DA for ; Tue, 27 Apr 2010 13:00:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-01-4bd7423abaa1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id EA.3B.23532.A3247DB4; Tue, 27 Apr 2010 21:59:54 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 27 Apr 2010 21:59:54 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "Paul E. Jones" Date: Tue, 27 Apr 2010 21:59:53 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrmQwz3sEh+WZiPSrOVz7cuzXEXwgAAO7rg Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> In-Reply-To: <4BD73FE1.7050105@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: 'Michael Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:00:13 -0000 Hi,=20 >> I don't think we should reserve a name. Use of options "ping" should=20 >> be between two devices that have some kind of established relationship=20 >> and the "ping" address should be known only locally. > >IIUC, you are saying that any specific options-ping behavior should be the= result of *configuration* of the UAC and UAS. And then can I infer that re= cognition that in incoming OPIONS is a ping would be=20 >based on source address and/or use of a "special" address that is configur= ed into the UAC rather than reserved. Or a URI parameter. I assume the pings will use a pre-defined route, and wo= uld not be re-targeted etc. Maybe we can also assume that they will be used= between adjacent nodes. Regards, Christer =20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, April 26, 2010 8:56 AM >> To: Hadriel Kaplan >> Cc: Paul E. Jones; 'Michael Miller'; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >> >> >> >> Hadriel Kaplan wrote: >>> "root" obviously. ;) >>> But seriously, picking a crazy username that won't collide is not >> that hard. The question is if it's the right thing to do. >> >> I don't believe in reserving names from other people's namespaces=20 >> after the fact, on general principles. You cannot know how they use=20 >> their namespace. You can reduce the probability of collision by=20 >> making the value very obscure, but then it is very obscure. >> >> So IMO it is the wrong thing to do. >> >> Thanks, >> Paul >> >>> Paul Kyzivat wrote: >>> >>> >>> I will grant you that having per-user policies for what to include=20 >>> in OPTIONS would be possible. >>> >>> But using that approach here means reserving a specific username. >> Which >>> one are we allowed to pick that won't impact somebody? (I expect >> there >>> are people out there named "ping" who might not like having their >> user >>> name preempted.) >>> >>> AFAIK we have never preempted a user name, except for Anonymous, >> which >>> is only preempted in the anonymous.invalid domain. I'd much rather >> see a >>> special uri parameter to designate this behavior. >>> >>> Thanks, >>> Paul >>> >>> Hadriel Kaplan wrote: >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org]=20 >>>>> On >> Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Friday, April 23, 2010 1:28 PM >>>>> >>>>> Making a decision based on the form of the R-URI presumes that=20 >>>>> non- >> ping >>>>> users of options never use an ip address as the R-URI. Requiring >> the >>>>> R-URI to be ping@ip reserves a user part, and also is just a=20 >>>>> sleazy >> way >>>>> of adding another indicator to the message to indicate its=20 >>>>> intended >> use. >>>> Actually in a weird way I think doing a specific username may be=20 >>>> the >> right thing to do. Think about it from an email perspective. When=20 >> you check on the status and settings of an email list using SMTP, do=20 >> you >> (a) send a new different SMTP message type, or (b) address a normal=20 >> message to the actual logical administrative code for the list? You=20 >> send a normal message to userlist-request@emailserver.com. >>>> And logically the thing being "pinged" is a higher layer, because >> the response provides an administrative status as well. (even though=20 >> in code one would probably do this at a low level) >>>> Put it another way: in theory you could send a SUBSCRIBE to this >> logical admin-UA in that proxy so that it Notifies you when it goes=20 >> admin up/down. That logical UA is a resource in the proxy, and could=20 >> be addressed as such. >>>> -hadriel >>>> >=20 >=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From paulej@packetizer.com Tue Apr 27 13:18:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFF23A6801 for ; Tue, 27 Apr 2010 13:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srs-cBhzN1z0 for ; Tue, 27 Apr 2010 13:18:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D97013A68DD for ; Tue, 27 Apr 2010 13:18:13 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3RKH6wT010851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Apr 2010 16:17:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272399432; bh=0xerilWDTYprkyHyJ56AQ0Hz4QgdfcfqrqZEvu0I2MQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=oxf0xnc4pwPeQG20RyycjFUpZIxfAyvwY87iRlytzgox/FpIZfa49pLXrtq6XgI9P 6494QD/UtftHQdqVgg9TRs9bADNL/rrTbtDSt9C9nVSQK6GNXMUYtXmP0hDj8AZT6V PbFf20kv6K76YOlLisxK8AEjir13dOrcc2guxguU= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3RKH5IY017507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Apr 2010 16:17:06 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> In-Reply-To: <4BD73FE1.7050105@cisco.com> Date: Tue, 27 Apr 2010 16:17:01 -0400 Message-ID: <005b01cae646$9892b0d0$c9b81270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrmQtKolkNBY8tUQ02YzbQpw5eBCwAAvuIA Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:18:15 -0000 Paul, > Paul E. Jones wrote: > > I don't think we should reserve a name. Use of options "ping" should > be > > between two devices that have some kind of established relationship > and the > > "ping" address should be known only locally. > > IIUC, you are saying that any specific options-ping behavior should be > the result of *configuration* of the UAC and UAS. And then can I infer > that recognition that in incoming OPIONS is a ping would be based on > source address and/or use of a "special" address that is configured > into > the UAC rather than reserved. > > Is that right? I don't think behavior of OPTIONS "ping" should be unspecified (as it is today). I'm only saying that we should not reserve in a specification a particular address (e.g., "sip:ping@host") to which SIP OPTIONS should be directed. A vendor might want to process OPTIONS "ping" messages addressed as sip:192.168.1.10 or sip:ping@example.com, and I see no reason to specify what that is. We might specify that either form may be used. What I had written in the draft originally was that OPTIONS should be addressed only as sip:hostport, but I removed that paragraph from my working draft since I can see some value in allowing a user part in the URI. Paul From paulej@packetizer.com Tue Apr 27 13:19:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09D93A68DD for ; Tue, 27 Apr 2010 13:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpJJMpbEuTCB for ; Tue, 27 Apr 2010 13:19:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 76D973A6A0E for ; Tue, 27 Apr 2010 13:19:31 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3RKJ7Dv011079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Apr 2010 16:19:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272399553; bh=sjr5sS6EM0NSaN5VcCac+jlVoQY61/Z9VyH6iO6czW8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=rrc6yiZf4DyK6oGqjS9AsTskn/WuJjkTXq1VlKfMsm6xtMIbcJSdrEdmJOwFo32s/ dN2gAgnFok853YJzmytcNUoqrG0L7+VHwlE0R9ByF0292dkn+2EN6LZBJnqQEMA1O1 lYZzQGGJruuHT7IxIh7TCLLoxzuLdIDhOkotfi+o= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3RKJ7l1017528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Apr 2010 16:19:07 -0400 From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> In-Reply-To: Date: Tue, 27 Apr 2010 16:19:02 -0400 Message-ID: <005e01cae646$e0d22c90$a27685b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrmQwz3sEh+WZiPSrOVz7cuzXEXwgAAO7rgAACqyhA= Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:19:40 -0000 > Or a URI parameter. I assume the pings will use a pre-defined route, > and would not be re-targeted etc. Maybe we can also assume that they > will be used between adjacent nodes. What we wrote in the draft in that regard is that SIP messages must be sent directly to the IP address of the peer. The intent is that these messages are not going to be sent to any intermediaries. Paul From pkyzivat@cisco.com Tue Apr 27 15:26:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441D03A6AA7 for ; Tue, 27 Apr 2010 15:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaEDW5cJb-Xn for ; Tue, 27 Apr 2010 15:26:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1F7203A6812 for ; Tue, 27 Apr 2010 15:26:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGAB10tAZnwM/2dsb2JhbACcX3GmNJoLhQ4E X-IronPort-AV: E=Sophos;i="4.52,283,1270425600"; d="scan'208";a="105823408" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 22:26:30 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RMQU7p028375; Tue, 27 Apr 2010 22:26:30 GMT Message-ID: <4BD76496.50905@cisco.com> Date: Tue, 27 Apr 2010 18:26:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> In-Reply-To: <005b01cae646$9892b0d0$c9b81270$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 22:26:44 -0000 Paul E. Jones wrote: > Paul, > >> Paul E. Jones wrote: >>> I don't think we should reserve a name. Use of options "ping" should >> be >>> between two devices that have some kind of established relationship >> and the >>> "ping" address should be known only locally. >> IIUC, you are saying that any specific options-ping behavior should be >> the result of *configuration* of the UAC and UAS. And then can I infer >> that recognition that in incoming OPIONS is a ping would be based on >> source address and/or use of a "special" address that is configured >> into >> the UAC rather than reserved. >> >> Is that right? > > I don't think behavior of OPTIONS "ping" should be unspecified (as it is > today). I'm only saying that we should not reserve in a specification a > particular address (e.g., "sip:ping@host") to which SIP OPTIONS should be > directed. A vendor might want to process OPTIONS "ping" messages addressed > as sip:192.168.1.10 or sip:ping@example.com, and I see no reason to specify > what that is. We might specify that either form may be used. > > What I had written in the draft originally was that OPTIONS should be > addressed only as sip:hostport, but I removed that paragraph from my working > draft since I can see some value in allowing a user part in the URI. I think I understand, but I still not certain I do. I think you are saying that: - there are potentially two behaviors in response to OPTIONS: . the "ping" behavior, which is potentially simpler and more optimized . the "normal" (non ping) behavior, which may have extra detail and be bigger and/or more expensive to produce. - that there is *some* feature of the incoming OPTIONS message that the recipient uses to distinguish which behavior to apply. - that the particular feature used to make that distinction may vary from one UAS to another. Its the responsibility of the UAC (e.g. via configuration) to know what it is that the UAS will used to decide, and then to construct the OPTIONS appropriately depending on which behavior it wants. Is that right? Thanks, Paul From HKaplan@acmepacket.com Tue Apr 27 19:10:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297883A6A38 for ; Tue, 27 Apr 2010 19:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9VfCjk9NbEF for ; Tue, 27 Apr 2010 19:10:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C01623A6A8E for ; Tue, 27 Apr 2010 19:10:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Apr 2010 22:10:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 22:10:17 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Tue, 27 Apr 2010 22:10:11 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrmQtKolkNBY8tUQ02YzbQpw5eBCwAAvuIAAAwhLqA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1349@mail> References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> In-Reply-To: <005b01cae646$9892b0d0$c9b81270$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 02:10:36 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, April 27, 2010 4:17 PM > To: 'Paul Kyzivat' >=20 > I don't think behavior of OPTIONS "ping" should be unspecified (as it is > today). I'm only saying that we should not reserve in a specification a > particular address (e.g., "sip:ping@host") to which SIP OPTIONS should be > directed. A vendor might want to process OPTIONS "ping" messages > addressed > as sip:192.168.1.10 or sip:ping@example.com, and I see no reason to > specify > what that is. We might specify that either form may be used. The rub with that is it doesn't remove the per-hop interop configuration th= at a draft such as this one is trying to remove/avoid. I'm not saying that= makes the draft useless, because at least it would avoid the response-code= configuration portion - but just wondering why we can't avoid the intended= target issue as well. BTW, defining the syntax for the intent of the request can be done multiple= ways, and I was only suggesting that agreeing on a specific user name woul= d be one way. (it's always seemed to me to be a hack that requests intende= d for a Proxy to process as a logical UA are not addressed to a specific lo= gical UA/resource, but instead just inferred by the Proxy as being for it) But there are other ways of skinning that cat. It would be nice to agree o= n one way, though, to avoid more config. -hadriel From adam@nostrum.com Tue Apr 27 20:20:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A893A6A6A for ; Tue, 27 Apr 2010 20:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_50=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4rxpTklORgZ for ; Tue, 27 Apr 2010 20:20:47 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C5F323A680A for ; Tue, 27 Apr 2010 20:20:46 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3S3KVXv046652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 22:20:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BD7A97F.1040302@nostrum.com> Date: Tue, 27 Apr 2010 22:20:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <2124358845.955737178@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79FCEC48@mail>, <4BCDF20A.5050401@ericsson.com> <841CC12A-6362-49DB-BC04-75F849E7D944@softarmor.com> <738ADC59-0184-4CE5-90A3-B4AF47556E2D@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C0DA@mail> <2C8E9939-208D-44B8-8670-432E79944018@softarmor.com> <4BD796F0.2050809@nostrum.com> <430FC6BDED356B4C8498F634416644A91A8A5F134F@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F134F@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: [sipcore] OPTIONS, except not (was Re: [RAI] Option-tag registration) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 03:20:52 -0000 [as participant] Moving this conversation from RAI to SIPCORE, since it seems more appropriate over here now. On 4/27/10 21:30, Apr 27, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, April 27, 2010 10:01 PM >> To: Dean Willis >> >> This is really, really starting to sound like a new method. >> > Why? Creating a new method doesn't avoid the issue of intended target routing. (a legacy proxy would forward it like any other unknown method) > It's not just the target routing. Taken in aggregate, this thread has basically taken the position that it "works just like OPTIONS, except for everything." The removal of OPTIONS' actual raison d'être -- the querying of capabilities -- is clearly a last straw. I know that OPTIONS has the benefit of being one of the Fourteen True Methods handed down to Moses on Mount Sinai, but if we're really looking at something intended as a liveness check -- as opposed to a capabilities query -- let's go ahead and do it correctly. This is a new thing, let's make it a new thing. /a From HKaplan@acmepacket.com Tue Apr 27 20:50:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFC93A6A0F for ; Tue, 27 Apr 2010 20:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqoz+72igDcP for ; Tue, 27 Apr 2010 20:50:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 027C23A69E5 for ; Tue, 27 Apr 2010 20:50:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Apr 2010 23:49:58 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 23:49:57 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 27 Apr 2010 23:49:45 -0400 Thread-Topic: OPTIONS, except not (was Re: [RAI] Option-tag registration) Thread-Index: AcrmgdPT4bucNcnSSK6iH/YFxg56ngAAddZg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1361@mail> References: <2124358845.955737178@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79FCEC48@mail>, <4BCDF20A.5050401@ericsson.com> <841CC12A-6362-49DB-BC04-75F849E7D944@softarmor.com> <738ADC59-0184-4CE5-90A3-B4AF47556E2D@softarmor.com> <430FC6BDED356B4C8498F634416644A91A7A06C0DA@mail> <2C8E9939-208D-44B8-8670-432E79944018@softarmor.com> <4BD796F0.2050809@nostrum.com> <430FC6BDED356B4C8498F634416644A91A8A5F134F@mail> <4BD7A97F.1040302@nostrum.com> In-Reply-To: <4BD7A97F.1040302@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS, except not (was Re: [RAI] Option-tag registration) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 03:50:11 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 27, 2010 11:21 PM > To: Hadriel Kaplan >=20 > It's not just the target routing. Taken in aggregate, this thread has > basically taken the position that it "works just like OPTIONS, except > for everything." The removal of OPTIONS' actual raison d'=EAtre -- the > querying of capabilities -- is clearly a last straw. But really the capabilities piece is the "everything" part of a "except for= everything". I mean the rest of it (status codes, max-forwards, etc.) was= actually stuff rfc3261 talked about applying to OPTIONS. So except for th= e capabilities piece, Paul's draft is just trying to be more explicit about= what OPTIONS already legitimately does I think. No? But I do think it should query capabilities. It just may be the capabiliti= es of the target are very, very limited. :) -hadriel From paulej@packetizer.com Tue Apr 27 21:31:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565983A6885 for ; Tue, 27 Apr 2010 21:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBUc6CXwzwZx for ; Tue, 27 Apr 2010 21:31:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 53C5C3A6ACD for ; Tue, 27 Apr 2010 21:31:09 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3S4Uljx031375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 00:30:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272429052; bh=kyuAL+rKT9CnbIi7gTjHoifiJWy15GstDOp+rFCd3NU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=B8B9bIks9eEK4Cti3ffkKNX8zKx9VAfSwNhC4I4XmPRt1dUFEEjWFsZln7vDsc17B VVQAs0B/+zpRWQek3Gx7k1/Qm2VooUHbu1LykxPYcAqQmBRI281smREX5PLnktUeCA ksMb73T25ujn8rLOAr0I/oHYBGAV0qnmLYyKCIwo= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3S4Uk2d018492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 00:30:46 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> In-Reply-To: <4BD76496.50905@cisco.com> Date: Wed, 28 Apr 2010 00:30:41 -0400 Message-ID: <005301cae68b$8f7d8110$ae788330$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrmWLMcDr8YWb2MTQa7l7QyPRJGXgAJiY7A Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 04:31:10 -0000 Paul, > I think you are saying that: > > - there are potentially two behaviors in response to OPTIONS: > . the "ping" behavior, which is potentially simpler > and more optimized > . the "normal" (non ping) behavior, which may have extra > detail and be bigger and/or more expensive to produce. I would expect that if a device claims support for the draft we've submitted, then it will always provide an "optimized" implementation (whatever that means). Likely, it will return a 200 with some fairly static payload or another code that makes sense. The "normal" reply would suggest the device does not support the draft, right? That's a case I'm not interested in what such a device would do. I guess the question here is how we know whether an OPTIONS is for "ping" or to query for OPTIONS. What I suggested is that manufacturers would design their boxes to support the draft -- and the draft tries to align with 3261. There should be some address to which ping messages are directed, which my preference would be the IP address of the device. The reason for my suggesting that is that, generally, one does not establish a session with the IP address of an SBC :-) That said, I can see where it might be useful to have a ping@example.com type address for such things as IP phones or even SBCs. In any case, the "ping" address should be an address that the manufacturer discloses and the peer entity should be configured to use. > - that there is *some* feature of the incoming OPTIONS message > that the recipient uses to distinguish which behavior to apply. I'm not opposed to it, but it seems like overkill. If one were to build an SBC that expects to receive an OPTIONS "ping" at "sip:ping@192.168.1.10" and the feature tag (or whatever) for "ping" is not there, do you really think the box would behave differently? > - that the particular feature used to make that distinction > may vary from one UAS to another. Its the responsibility > of the UAC (e.g. via configuration) to know what it is that > the UAS will used to decide, and then to construct the OPTIONS > appropriately depending on which behavior it wants. > > Is that right? If we feel that some kind of tag is necessary to identify a request as a "ping", I would certainly not want it to vary by implementation. However, I'm not yet convinced we even need such a feature tag, as I think the Request URI would suffice. Paul From dean.willis@softarmor.com Tue Apr 27 21:56:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CD493A6A0F for ; Tue, 27 Apr 2010 21:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n6gXiTZvFH2 for ; Tue, 27 Apr 2010 21:56:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E96473A6AB5 for ; Tue, 27 Apr 2010 21:56:04 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3S4tk1q001490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Apr 2010 23:55:47 -0500 Message-Id: <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> From: Dean Willis To: "Paul E. Jones" In-Reply-To: <005301cae68b$8f7d8110$ae788330$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Apr 2010 23:55:40 -0500 References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> X-Mailer: Apple Mail (2.936) Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 04:56:06 -0000 On Apr 27, 2010, at 11:30 PM, Paul E. Jones wrote: > > I guess the question here is how we know whether an OPTIONS is for > "ping" or > to query for OPTIONS. What I suggested is that manufacturers would > design > their boxes to support the draft -- and the draft tries to align > with 3261. > There should be some address to which ping messages are directed, > which my > preference would be the IP address of the device. The reason for my > suggesting that is that, generally, one does not establish a session > with > the IP address of an SBC :-) That said, I can see where it might be > useful > to have a ping@example.com type address for such things as IP phones > or even > SBCs. In any case, the "ping" address should be an address that the > manufacturer discloses and the peer entity should be configured to > use. In my experience, everybody uses IP addresses for almost everything. It's a mistake to assume DNS in a real-world deployment outside of the occasional user-configured proxy. So if we don't want any of the behavior of OPTIONS why not just do a coaxial STUN request on the SIP port, as one would do for outbound? It's MUCH lighter weight and doesn't even need text parsing. > >> - that there is *some* feature of the incoming OPTIONS message >> that the recipient uses to distinguish which behavior to apply. > > I'm not opposed to it, but it seems like overkill. If one were to > build an > SBC that expects to receive an OPTIONS "ping" at "sip:ping@192.168.1.10 > " and > the feature tag (or whatever) for "ping" is not there, do you really > think > the box would behave differently? Yes. Because if it's got a reasonable SIP stack and I send it an OPTIONS request, I expect to see a legitimate OPTIONS response. >> - that the particular feature used to make that distinction >> may vary from one UAS to another. Its the responsibility >> of the UAC (e.g. via configuration) to know what it is that >> the UAS will used to decide, and then to construct the OPTIONS >> appropriately depending on which behavior it wants. >> >> Is that right? > > If we feel that some kind of tag is necessary to identify a request > as a > "ping", I would certainly not want it to vary by implementation. > However, > I'm not yet convinced we even need such a feature tag, as I think the > Request URI would suffice. The tag could be encoded in the R-URI, in the user-name, a parameter on the user-name, as a request-URI parameter, or as part of the target host name. Or it could be a new header field inside the body of the request. That's got the best backward compatibility of any of the options discussed. -- dean From dean.willis@softarmor.com Tue Apr 27 22:01:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1276F3A6AFD for ; Tue, 27 Apr 2010 22:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EkqFA13SFY3 for ; Tue, 27 Apr 2010 22:01:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 671B13A6BA6 for ; Tue, 27 Apr 2010 22:00:11 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3S4xohN001553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Apr 2010 23:59:51 -0500 Message-Id: <9EF580C2-93F9-4B26-9806-A898C0CD9978@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Apr 2010 23:59:45 -0500 References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Hadriel Kaplan' , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 05:01:01 -0000 On Apr 27, 2010, at 2:59 PM, Christer Holmberg wrote: > > Hi, > >>> I don't think we should reserve a name. Use of options "ping" >>> should >>> be between two devices that have some kind of established >>> relationship >>> and the "ping" address should be known only locally. >> >> IIUC, you are saying that any specific options-ping behavior should >> be the result of *configuration* of the UAC and UAS. And then can I >> infer that recognition that in incoming OPIONS is a ping would be >> based on source address and/or use of a "special" address that is >> configured into the UAC rather than reserved. > > Or a URI parameter. I assume the pings will use a pre-defined route, > and would not be re-targeted etc. Maybe we can also assume that they > will be used between adjacent nodes. But we always have to consider (and document) that which happens if they are not used as expected. What happens when you ping a non- adjacent node? What happens when the ping is contact-routed or loose- routed by an intermediate proxy? I'm not saying that we need to have a perfect solution, but at least we need to consider and document the likely failures and oddities. For example, saying "The node being pinged MUST be an adjacent node" is insufficient. This is a "naked requirement" -- for it to be respected, we need to put clothes on it. Perhaps we could add "because if the node is not adjacent, then the following is likely...." -- Dean From paulej@packetizer.com Tue Apr 27 22:02:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9572E3A6AED for ; Tue, 27 Apr 2010 22:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx9NnvxqW1dc for ; Tue, 27 Apr 2010 22:02:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 29FA43A6B70 for ; Tue, 27 Apr 2010 22:01:08 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3S50cDF002499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 01:00:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272430843; bh=aPdCc1ARoaShz14a7HDCPKeu+mHbvN3GcTPgeaGvtC0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JBzmoNWnBCjL98yb4bzXuHCym2vz0AZ8Ni00VrvF4lc5UFeG3QknjobB0jNxwx2TL nzTutHqsr77drSiVCRLcRudwouBOFbeyvyvCVT03MI0UHVAXqfKPaGagCiX2q/CSSI SHDUGiRkhDyZhpgieNZhXy1U+nWcUDC931CtpS4M= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3S50bl1018560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 01:00:38 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <430FC6BDED356B4C8498F634416644A91A8A5F1349@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1349@mail> Date: Wed, 28 Apr 2010 01:00:32 -0400 Message-ID: <006d01cae68f$bb434420$31c9cc60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrmQtKolkNBY8tUQ02YzbQpw5eBCwAAvuIAAAwhLqAABjT70A== Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 05:02:16 -0000 Hadriel, > > I don't think behavior of OPTIONS "ping" should be unspecified (as it > is > > today). I'm only saying that we should not reserve in a > specification a > > particular address (e.g., "sip:ping@host") to which SIP OPTIONS > should be > > directed. A vendor might want to process OPTIONS "ping" messages > > addressed > > as sip:192.168.1.10 or sip:ping@example.com, and I see no reason to > > specify > > what that is. We might specify that either form may be used. > > The rub with that is it doesn't remove the per-hop interop > configuration that a draft such as this one is trying to remove/avoid. > I'm not saying that makes the draft useless, because at least it would > avoid the response-code configuration portion - but just wondering why > we can't avoid the intended target issue as well. I assume you're referring to such things as performing a DNS query on a name, discovering 4 IP addresses, and then needed to know how to address them (if not by IP address). In that case, yes, I can see why a defined username or some type of "ping" tag might be necessary. A question: why not just use the IP address and port as the "ping" address? I'm sure there may be a few good reasons, but that seems like a logical destination (and is the reason I proposed it in the draft). > BTW, defining the syntax for the intent of the request can be done > multiple ways, and I was only suggesting that agreeing on a specific > user name would be one way. (it's always seemed to me to be a hack > that requests intended for a Proxy to process as a logical UA are not > addressed to a specific logical UA/resource, but instead just inferred > by the Proxy as being for it) > > But there are other ways of skinning that cat. It would be nice to > agree on one way, though, to avoid more config. Agree. This is not a complex problem, so I'd like to just agree on something and go forward. Where's that coin? Or do I need to roll a die? What options do we want to consider? Paul From christer.holmberg@ericsson.com Wed Apr 28 00:55:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE9E3A6B18 for ; Wed, 28 Apr 2010 00:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JARZqobwXqUm for ; Wed, 28 Apr 2010 00:55:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 173483A65A6 for ; Wed, 28 Apr 2010 00:55:25 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-1a-4bd7e9dfdbe7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5E.85.23740.FD9E7DB4; Wed, 28 Apr 2010 09:55:11 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Apr 2010 09:55:10 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 28 Apr 2010 09:55:10 +0200 From: Christer Holmberg To: Dean Willis Date: Wed, 28 Apr 2010 09:55:09 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrmj6aulC4qrVCsS7GcKpiBEYi31QAGFYrQ Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <9EF580C2-93F9-4B26-9806-A898C0CD9978@softarmor.com> In-Reply-To: <9EF580C2-93F9-4B26-9806-A898C0CD9978@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Hadriel Kaplan' , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 07:55:27 -0000 Hi,=20 >>>> I don't think we should reserve a name. Use of options "ping" =20 >>>> should >>>> be between two devices that have some kind of established=20 >>>> relationship and the "ping" address should be known only locally. >>> >>> IIUC, you are saying that any specific options-ping behavior should=20 >>> be the result of *configuration* of the UAC and UAS. And then can I=20 >>> infer that recognition that in incoming OPIONS is a ping would be=20 >>> based on source address and/or use of a "special" address that is=20 >>> configured into the UAC rather than reserved. >> >> Or a URI parameter. I assume the pings will use a pre-defined route,=20 >> and would not be re-targeted etc. Maybe we can also assume that they=20 >> will be used between adjacent nodes. >=20 >But we always have to consider (and document) that which=20 >happens if they are not used as expected. What happens when=20 >you ping a non- adjacent node? What happens when the ping is=20 >contact-routed or loose- routed by an intermediate proxy? I'm=20 >not saying that we need to have a perfect solution, but at=20 >least we need to consider and document the likely failures=20 >and oddities. >=20 >For example, saying "The node being pinged MUST be an adjacent node" =20 >is insufficient. This is a "naked requirement" -- for it to be =20 >respected, we need to put clothes on it. Perhaps we could add =20 >"because if the node is not adjacent, then the following is=20 >likely...." True. But, you could say that the Max-Forwards value MUST be 1. Regards, Christer From christer.holmberg@ericsson.com Wed Apr 28 01:25:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646313A6846 for ; Wed, 28 Apr 2010 01:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=1.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7VGGRVUke-m for ; Wed, 28 Apr 2010 01:25:22 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 96B0F3A65A6 for ; Wed, 28 Apr 2010 01:25:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-59-4bd7f0e3460b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F0.5F.23532.3E0F7DB4; Wed, 28 Apr 2010 10:25:07 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 28 Apr 2010 10:25:07 +0200 From: Christer Holmberg To: Dean Willis , "Paul E. Jones" Date: Wed, 28 Apr 2010 10:25:05 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrmjxcPBC/KkdVtSBGVFTSTPIh41AAHHXXA Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> In-Reply-To: <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'Michael Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:25:23 -0000 Hi,=20 >>I guess the question here is how we know whether an OPTIONS is for=20 >>"ping" or to query for OPTIONS. What I suggested is that=20 >>manufacturers would design their boxes to support the draft=20 >>-- and the=20 >>draft tries to align with 3261. >>There should be some address to which ping messages are directed,=20 >>which my preference would be the IP address of the device. =20 >>The reason for my suggesting that is that, generally, one does not establ= ish a=20 >>session with the IP address of an SBC :-) That said, I can see where=20 >>it might be useful to have a ping@example.com type address for such=20 >>things as IP phones or even SBCs. In any case, the "ping" address=20 >>should be an address that the manufacturer discloses and the peer=20 >>entity should be configured to use. >=20 >In my experience, everybody uses IP addresses for almost everything. =20 >It's a mistake to assume DNS in a real-world deployment=20 >outside of the occasional user-configured proxy. >=20 >So if we don't want any of the behavior of OPTIONS why not=20 >just do a coaxial STUN request on the SIP port, as one would=20 >do for outbound? =20 >It's MUCH lighter weight and doesn't even need text parsing. The keep-draft uses STUN. However, when you send something in-dialog, or in= -registration, you have the possibility to negotiate the usage. However, if you send something "stand alone", you don't know whether the re= ceiver supports something. Of course, you could send ONE OPTIONS, and see f= rom the response whether the receiver supports stun, eg using the mechanism= in the keep-draft. If you start sending STUN messages, and the receiver does not support it, i= t could treat the messages as crap, and in the worse case even put you on s= ome black list :) Regards, Christer > >> - that the particular feature used to make that distinction > >> may vary from one UAS to another. Its the responsibility > >> of the UAC (e.g. via configuration) to know what it is that > >> the UAS will used to decide, and then to construct the OPTIONS > >> appropriately depending on which behavior it wants. > >> > >> Is that right? > > > > If we feel that some kind of tag is necessary to identify a=20 > request as=20 > > a > > "ping", I would certainly not want it to vary by implementation. =20 > > However, > > I'm not yet convinced we even need such a feature tag, as I=20 > think the=20 > > Request URI would suffice. >=20 > The tag could be encoded in the R-URI, in the user-name, a=20 > parameter on the user-name, as a request-URI parameter, or as=20 > part of the target host name. >=20 > Or it could be a new header field inside the body of the request. =20 > That's got the best backward compatibility of any of the=20 > options discussed. >=20 > -- > dean >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Wed Apr 28 07:27:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAFA3A6A9F for ; Wed, 28 Apr 2010 07:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.615 X-Spam-Level: X-Spam-Status: No, score=-9.615 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBB9CDxYEK3I for ; Wed, 28 Apr 2010 07:27:08 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C3A693A6A88 for ; Wed, 28 Apr 2010 07:26:57 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFfi10tAZnwM/2dsb2JhbACcb3GjBJotglaCOAQ X-IronPort-AV: E=Sophos;i="4.52,288,1270425600"; d="scan'208";a="106060703" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2010 14:26:44 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SEQiC5016114; Wed, 28 Apr 2010 14:26:44 GMT Message-ID: <4BD845A4.1040402@cisco.com> Date: Wed, 28 Apr 2010 10:26:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> In-Reply-To: <005301cae68b$8f7d8110$ae788330$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 14:27:09 -0000 Paul E. Jones wrote: > Paul, > >> I think you are saying that: >> >> - there are potentially two behaviors in response to OPTIONS: >> . the "ping" behavior, which is potentially simpler >> and more optimized >> . the "normal" (non ping) behavior, which may have extra >> detail and be bigger and/or more expensive to produce. > > I would expect that if a device claims support for the draft we've > submitted, then it will always provide an "optimized" implementation > (whatever that means). Likely, it will return a 200 with some fairly static > payload or another code that makes sense. I can think of cases where that wouldn't be the case. Certainly the other OPTIONS discussion is suggesting returning *more* information about capabilities of the addressed resource. And that might be expected in a box that should also be involved in pinging. For instance a "registrar/home-proxy" box serving atlanta.com might be expected to respond to OPTIONS for sip:alice@atlanta with specifics about alice - possibly a 3xx with the registered contacts. OTOH a neighboring "load balancer" proxy might want to be pinging that box, and desiring a quick response with no "capabilities". Of course in this case the distinction could be made by the address of the request. But still there are two behaviors, distinguished by something in the request. > The "normal" reply would suggest the device does not support the draft, > right? That's a case I'm not interested in what such a device would do. This goes to the other discussion we have been having about Require - the distinction about "supporting" a feature and "using" the feature. Just because the box "supports" this ping doesn't mean it should use it all the time. > I guess the question here is how we know whether an OPTIONS is for "ping" or > to query for OPTIONS. Yup. > What I suggested is that manufacturers would design > their boxes to support the draft -- and the draft tries to align with 3261. Discussed above. > There should be some address to which ping messages are directed, So you *are* suggesting that ping behavior be selected based on the form of the address in the OPTIONS request. > which my > preference would be the IP address of the device. The reason for my > suggesting that is that, generally, one does not establish a session with > the IP address of an SBC :-) There are multiple "features" of that approach that might be the actual determiner of the behavior: - there is no user part to the uri - the domain part of the URI is an ip address rather than an FQDN - both of the above Trouble is: there is plenty of usage where that's a bad choice. Its my understanding that there are quite a few "phone" type devices that use IP address without a user part as a contact address, and so receive real requests directly at such an address. An OPTIONS request to their registered Contact would eventually arrive to them with just the ip address in the R-URI, yet the expectation is that the request is not a ping. And at the same time, a proxy upstream from that device might indeed want to ping it. > That said, I can see where it might be useful > to have a ping@example.com type address for such things as IP phones or even > SBCs. In any case, the "ping" address should be an address that the > manufacturer discloses and the peer entity should be configured to use. IMO the reason we have standards is to avoid having to configure such things. If its worth standardizing the behavior then its worth standardizing how its invoked. >> - that there is *some* feature of the incoming OPTIONS message >> that the recipient uses to distinguish which behavior to apply. > > I'm not opposed to it, but it seems like overkill. As I note above, I consider a particular address form (such as ip-address-only R-URI, or "ping" as the user part of the R-URI) as an example of a feature that might be used to select the behavior. I think there are several alternatives: 1) OPTIONS has only one behavior. 1a) A UAC may use OPTIONS as a ping, ignoring information in the response that is irrelevant to it. 1b) There is a new method, different from OPTIONS for the ping functionality. 2) OPTIONS has two different standardized behaviors: normal & ping. 2a) A given box always implements one or the other of those behaviors, in all cases. 2b) A given box may implement them both. The selection of which behavior to use for a specific request is determined by some feature of the request. (the source address, the R-URI, a special header, ...) Precisely what feature causes this is unstandardized. The sender who cares about which behavior it gets must "know" how to construct the request to get that behavior. 2c) A given box may implement them both. The selection of which behavior to use for a specific request is standardized. (Exactly what that is is TBD. Based on what you have said, I think you are advocating 2b. My preference would be for 1a or 1b. I could live with 2c. I find 2a and 2b unacceptable for reasons previously stated. Note that 1a and 1b can be used together: a UAC that wants to ping first tries sending the special PING request. If that is rejected, it falls back to using a "normal" OPTIONS as an alternative. Thanks, Paul > If one were to build an > SBC that expects to receive an OPTIONS "ping" at "sip:ping@192.168.1.10" and > the feature tag (or whatever) for "ping" is not there, do you really think > the box would behave differently? > >> - that the particular feature used to make that distinction >> may vary from one UAS to another. Its the responsibility >> of the UAC (e.g. via configuration) to know what it is that >> the UAS will used to decide, and then to construct the OPTIONS >> appropriately depending on which behavior it wants. >> >> Is that right? > > If we feel that some kind of tag is necessary to identify a request as a > "ping", I would certainly not want it to vary by implementation. However, > I'm not yet convinced we even need such a feature tag, as I think the > Request URI would suffice. > > Paul > > > From rjsparks@nostrum.com Wed Apr 28 12:14:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4113A68B5 for ; Wed, 28 Apr 2010 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z37IeTsXtUu7 for ; Wed, 28 Apr 2010 12:14:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A79103A69BB for ; Wed, 28 Apr 2010 12:14:51 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3SJEX8A019991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Apr 2010 14:14:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-37--30386968 Date: Wed, 28 Apr 2010 14:14:32 -0500 In-Reply-To: <14EF82F1-1369-45F8-A303-AB207341DD2C@nostrum.com> To: SIPCORE References: <14EF82F1-1369-45F8-A303-AB207341DD2C@nostrum.com> Message-Id: <7F24DA8B-95C7-4483-A933-4CF78B2CDB65@nostrum.com> X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Registration for SIPit 26 closes in 3 days X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 19:14:53 -0000 --Apple-Mail-37--30386968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Registration closes May 1. If you are planning to attend and have not = yet registered, please do so now. RjS On Mar 16, 2010, at 11:15 AM, Robert Sparks wrote: > SIPit 26 will be held in Kista - the telecom valley outside Stockholm, = Sweden on May 17-21, 2010. The event is hosted by Edvina and TANDBERG = and sponsored by Ingate, Intertex and .se. >=20 > See and for details = and to register. >=20 > RjS >=20 --Apple-Mail-37--30386968 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii SIPit 26 will be held in Kista - the telecom valley = outside Stockholm, Sweden on May 17-21, 2010. The event is hosted by = Edvina and TANDBERG and sponsored by Ingate, Intertex and = .se.

See <http://www.sipit.net> and <http://sipit.edvina.se> for = details and to register.

RjS

<= br>= --Apple-Mail-37--30386968-- From paulej@packetizer.com Wed Apr 28 16:56:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD583A67A4 for ; Wed, 28 Apr 2010 16:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHuTU14in4Jz for ; Wed, 28 Apr 2010 16:56:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D85073A66B4 for ; Wed, 28 Apr 2010 16:56:36 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3SNtmFG030999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 19:55:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272498954; bh=4VEbKZS7TzwmgUb21bc+/stNvHY6Kw5vdy/Qx+L3ffM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Tc1KwgIc/moTrbpB49U+Nw+vwb67JiJUMZDPklufTmg5mY/tPHhJKMAxBDkDJyvjl nqa1DSLzHjrQUGVu1hOW1VJLzZqOkm9hVGoI0zv1MgaW082JLVTuEAu/FsfaEA5Raw jN5Lh/D6UVMPFNTxs0lmSfeaD85W1yD2CDxOe3us= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3SNtlrd021664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 19:55:47 -0400 From: "Paul E. Jones" To: "'Dean Willis'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> In-Reply-To: <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> Date: Wed, 28 Apr 2010 19:55:41 -0400 Message-ID: <00da01cae72e$4f5590c0$ee00b240$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrmjxiLQor4ONNaTs+7gUoWoKxX8wAnBkGw Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:56:38 -0000 Dean, > In my experience, everybody uses IP addresses for almost everything. I can see where this might be an issue for sending "ping" messages to phones. > It's a mistake to assume DNS in a real-world deployment outside of the > occasional user-configured proxy. DNS is just one way of obtaining an address. One is not precluded from getting the address in any way whatsoever. > So if we don't want any of the behavior of OPTIONS why not just do a > coaxial STUN request on the SIP port, as one would do for outbound? > It's MUCH lighter weight and doesn't even need text parsing. The purpose for a SIP OPTIONS ping is to get a response from the SIP process, not another process on the box. Following your argument, an ICMP packet is even lighter :-) > >> - that there is *some* feature of the incoming OPTIONS message > >> that the recipient uses to distinguish which behavior to apply. > > > > I'm not opposed to it, but it seems like overkill. If one were to > > build an > > SBC that expects to receive an OPTIONS "ping" at > "sip:ping@192.168.1.10 > > " and > > the feature tag (or whatever) for "ping" is not there, do you really > > think > > the box would behave differently? > > Yes. Because if it's got a reasonable SIP stack and I send it an > OPTIONS request, I expect to see a legitimate OPTIONS response. Yeah, ok. Agreed. > >> - that the particular feature used to make that distinction > >> may vary from one UAS to another. Its the responsibility > >> of the UAC (e.g. via configuration) to know what it is that > >> the UAS will used to decide, and then to construct the OPTIONS > >> appropriately depending on which behavior it wants. > >> > >> Is that right? > > > > If we feel that some kind of tag is necessary to identify a request > > as a > > "ping", I would certainly not want it to vary by implementation. > > However, > > I'm not yet convinced we even need such a feature tag, as I think the > > Request URI would suffice. > > The tag could be encoded in the R-URI, in the user-name, a parameter > on the user-name, as a request-URI parameter, or as part of the target > host name. > > Or it could be a new header field inside the body of the request. > That's got the best backward compatibility of any of the options > discussed. Personally, I'd prefer to make this as simple and unobtrusive as possible. What is the preference? We've got too many options here. Paul From HKaplan@acmepacket.com Wed Apr 28 16:58:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263FE3A688C for ; Wed, 28 Apr 2010 16:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi7HDnvbJxfS for ; Wed, 28 Apr 2010 16:58:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 301683A6861 for ; Wed, 28 Apr 2010 16:58:47 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Apr 2010 19:58:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Apr 2010 19:58:31 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Wed, 28 Apr 2010 19:58:28 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrmWLMcDr8YWb2MTQa7l7QyPRJGXgAJiY7AACuDZEA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F15BF@mail> References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> In-Reply-To: <005301cae68b$8f7d8110$ae788330$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:58:48 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, April 28, 2010 12:31 AM > To: 'Paul Kyzivat' >=20 > I guess the question here is how we know whether an OPTIONS is for "ping" > or > to query for OPTIONS. What I suggested is that manufacturers would desig= n > their boxes to support the draft -- and the draft tries to align with 326= 1. Right, but when I design my box to handle it, I need to know the OPTIONS re= quest I receive from your box expects your draft's specific semantics. Bec= ause I still need to support my legacy OPTIONS request handling code, inclu= ding for OPTIONS which were just routed through your box to me and thus are= not expecting the same draft's semantics. > There should be some address to which ping messages are directed, which m= y > preference would be the IP address of the device. The reason for my > suggesting that is that, generally, one does not establish a session with > the IP address of an SBC :-) =20 I beg to differ - for every SBC vendor I've seen, you do establish a sessio= n (or target an OPTIONS request) to the SBC. I'm sure there are some SBC v= endors gear I haven't seen, which may act as some inline bump-in-the-wire A= LG-thingy, but that's not the model "generally". =20 > That said, I can see where it might be > useful > to have a ping@example.com type address for such things as IP phones or > even > SBCs. In any case, the "ping" address should be an address that the > manufacturer discloses and the peer entity should be configured to use. I'm getting confused - are you thinking the IP Address of the OPTIONS' requ= est-URI would be a *different* IP Address from the one other SIP requests a= re sent to?? I didn't grok that from the draft at all, and it would make t= hings very complicated. -hadriel From dean.willis@softarmor.com Wed Apr 28 17:17:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B6D3A68F1 for ; Wed, 28 Apr 2010 17:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua30BZd0mB3T for ; Wed, 28 Apr 2010 17:17:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B40753A6847 for ; Wed, 28 Apr 2010 17:17:37 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3T0HIcu011322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Apr 2010 19:17:20 -0500 Message-Id: <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> From: Dean Willis To: "Paul E. Jones" In-Reply-To: <00da01cae72e$4f5590c0$ee00b240$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Apr 2010 19:17:13 -0500 References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> X-Mailer: Apple Mail (2.936) Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:17:49 -0000 On Apr 28, 2010, at 6:55 PM, Paul E. Jones wrote: >> So if we don't want any of the behavior of OPTIONS why not just do a >> coaxial STUN request on the SIP port, as one would do for outbound? >> It's MUCH lighter weight and doesn't even need text parsing. > > The purpose for a SIP OPTIONS ping is to get a response from the SIP > process, not another process on the box. Following your argument, > an ICMP > packet is even lighter :-) Right, but the coaxial-STUN is at least driven from the same port- listener-dispatcher as the SIP process. Remember, we're running both protocols on the same port, so the packets go to the same listener. One can envision a multithreaded model with the SIP thread has crashed but the listener and STUN responders linger on, but I system a more total faliure is likely to be the norm. >> Or it could be a new header field inside the body of the request. >> That's got the best backward compatibility of any of the options >> discussed. > > Personally, I'd prefer to make this as simple and unobtrusive as > possible. > What is the preference? We've got too many options here. I think the simplest thing is a new header field, coupled with an option-tag that could be used to indicate or require support for the header field. Yes, it is standards-track work, but it's not "hard" standards track; we know how to do these things reasonably well by now. An AD could bless it through the individual track using a 1 month IETF LC. So for example, a new header field "Options-mode" with a value of "ping" means "If you support this extension, do not proxy this request, just send an immediate 200 OK response and do not bother populating the Supported header field of the 200 OK response." Somebody who didn't recognize the header field would just send a conventional 200 OK response. And perhaps an option tag of "optionsmodeping". That way we can add further options-modes, and option tags for them in the future as (and if) needed. You could basically cut-and-paste the answer-mode draft and be done writing in an hour. -- Dean From paulej@packetizer.com Wed Apr 28 17:47:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1B528C168 for ; Wed, 28 Apr 2010 17:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NX-6wKec4nK for ; Wed, 28 Apr 2010 17:47:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id CA68F28C167 for ; Wed, 28 Apr 2010 17:47:38 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3T0lFfw001972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 20:47:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272502041; bh=Vq0ViY4X/G8PY79NnNVbN3h3qQOprgfcMEkbpDH9/iM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Go/iIDYuTClES1bPbQdd0tvOn1grMVgHehF2Chj3/fumpPSDX+TAvmaSs/FSdr0HF P7AbqVTcBPKCNMT/1Fa92MoUmKvHMHFvBRyJXcSmk+bT6uYLOtg+B95mw6fnksjg0p LLh33Xqh6SVFcFayyTRgLwtX4aM6XD/nW4xF1MJc= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3T0lEOA021836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 20:47:15 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15BF@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F15BF@mail> Date: Wed, 28 Apr 2010 20:47:08 -0400 Message-ID: <010601cae735$7f55c1d0$7e014570$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrmWLMcDr8YWb2MTQa7l7QyPRJGXgAJiY7AACuDZEAAAecAQA== Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:47:40 -0000 Hadriel, > > That said, I can see where it might be > > useful > > to have a ping@example.com type address for such things as IP phones > or > > even > > SBCs. In any case, the "ping" address should be an address that the > > manufacturer discloses and the peer entity should be configured to > use. > > I'm getting confused - are you thinking the IP Address of the OPTIONS' > request-URI would be a *different* IP Address from the one other SIP > requests are sent to?? I didn't grok that from the draft at all, and > it would make things very complicated. No, I certainly didn't mean to suggest there would a different IP address. What I am referring to is the Request URI. Previously, I was suggesting that the request URI would be addressed to the IP address if it's a ping, but would be addressed to a user if it wasn't. But, you and Dean have convinced me that that's not always a good way to differentiate an OPTIONS "ping" from one that's an actual OPTIONS request. So, I removed the restriction from my local draft that specified what the Request URI looks like. What we need to decide is exactly what we want to have as a differentiator? A specific request URI, a tag, a header, etc. Having said that, I'm still favorable to sending an OPTIONS "ping" addressed to the IP address of the device (e.g., sip:192.168.1.10). Whether that contains a "ping" header or tag or other is likely not going to make much difference to an SBC that does not receive other requests addressed to that address. Paul From paulej@packetizer.com Wed Apr 28 18:23:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B133A6916 for ; Wed, 28 Apr 2010 18:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VhwCtaMacLq for ; Wed, 28 Apr 2010 18:23:26 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id EDED73A6886 for ; Wed, 28 Apr 2010 18:23:11 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3T1MmRX004020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 21:22:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272504174; bh=Y0tXfcFqmjVESZnbLP41evDU1CyeAb6KCbT8u+BJgnM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KStYTcsYSXssHK5ZGdpVDnbEbrSURZjn5bVEkH61dTM8LtUU02X7veZS4D9drFjWz dJLT1VAyt0Hj3oiWV7ZgxWL1OOgeMIO8kYtco4/B1tTmyiOCj1D+f8mAvMvToJm7Du N3qRhDbVa1blZbf7F80M4R1kT78oqwWowanpYUZA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3T1Mll6021909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 21:22:47 -0400 From: "Paul E. Jones" To: "'Dean Willis'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> In-Reply-To: <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> Date: Wed, 28 Apr 2010 21:22:41 -0400 Message-ID: <010901cae73a$766dfec0$6349fc40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnMV6Z9ypCx3VHRPiMOXvrTTOoFgABFw7Q Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 01:23:28 -0000 Dean, > So for example, a new header field "Options-mode" with a value of > "ping" means "If you support this extension, do not proxy this > request, just send an immediate 200 OK response and do not bother > populating the Supported header field of the 200 OK response." > Somebody who didn't recognize the header field would just send a > conventional 200 OK response. Not objecting to the header, but I think we would have failed in our effort if the message might possibly be proxied. The intent was for this to be peer-to-peer. > And perhaps an option tag of "optionsmodeping". That way we can add > further options-modes, and option tags for them in the future as (and > if) needed. So, you want a head like this: Options-Mode: ping Or this: Require: optionsmodeping > You could basically cut-and-paste the answer-mode draft and be done > writing in an hour. Oh, I'll be happy to plagiarize your work ... but not sure exactly what you want me to copy :-) Paul From pkyzivat@cisco.com Wed Apr 28 19:37:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADB63A6A3E for ; Wed, 28 Apr 2010 19:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u981+zbH+qK3 for ; Wed, 28 Apr 2010 19:37:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D1B1C3A69A2 for ; Wed, 28 Apr 2010 19:37:37 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACKO2EtAZnwN/2dsb2JhbACdCHGjL5oQhQ4E X-IronPort-AV: E=Sophos;i="4.52,292,1270425600"; d="scan'208";a="106290725" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2010 02:37:24 +0000 Received: from [10.86.255.132] ([10.86.255.132]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3T2bNhO016423; Thu, 29 Apr 2010 02:37:23 GMT Message-ID: <4BD8F0E7.1070000@cisco.com> Date: Wed, 28 Apr 2010 22:37:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> In-Reply-To: <010901cae73a$766dfec0$6349fc40$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 02:37:39 -0000 Now that we have established the goal is devising some options/headers to entirely change the behavior of OPTIONS, I would rather see a new method: PING. Given the assumptions being made I can see few if any downsides to this, and definite upsides. IMO the value of using OPTIONS for ping is in those cases where the device being pinged doesn't know that it is being pinged. Thanks, Paul Paul E. Jones wrote: > Dean, > >> So for example, a new header field "Options-mode" with a value of >> "ping" means "If you support this extension, do not proxy this >> request, just send an immediate 200 OK response and do not bother >> populating the Supported header field of the 200 OK response." >> Somebody who didn't recognize the header field would just send a >> conventional 200 OK response. > > Not objecting to the header, but I think we would have failed in our effort > if the message might possibly be proxied. The intent was for this to be > peer-to-peer. > >> And perhaps an option tag of "optionsmodeping". That way we can add >> further options-modes, and option tags for them in the future as (and >> if) needed. > > So, you want a head like this: > > Options-Mode: ping > > Or this: > > Require: optionsmodeping > >> You could basically cut-and-paste the answer-mode draft and be done >> writing in an hour. > > Oh, I'll be happy to plagiarize your work ... but not sure exactly what you > want me to copy :-) > > Paul > > > From paulej@packetizer.com Wed Apr 28 19:55:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE743A6A68 for ; Wed, 28 Apr 2010 19:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUNXAd1GFYio for ; Wed, 28 Apr 2010 19:55:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 6DE863A6A3A for ; Wed, 28 Apr 2010 19:55:10 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3T2slTW016706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 22:54:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272509693; bh=OmiZAIP6WTnZ/acjNKRfZIVd9jlA3DgcU94QogF0BRE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=a4QpfCKGvfU2GwnLD531zgdoDHXzF8ZOfeO9cY8rJnkybZ7kAUngtXxLjUOF8PCXH wjG7KWHdSe20Bp74nmAU3opDPojAzOpzyW7AJ8Ec1HCF/LvcX94UUBYvssHa+x2DMe 3yiJKAUcWpCGXUjCWZ5k6dIv/Af2pDRZ7DH12/n0= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3T2skoo022119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 22:54:46 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> In-Reply-To: <4BD8F0E7.1070000@cisco.com> Date: Wed, 28 Apr 2010 22:54:40 -0400 Message-ID: <011601cae747$5013a740$f03af5c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5w Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 02:55:11 -0000 Paul, I don't see it quite the same way. I don't want to entirely change OPTIONS, but I do want to define procedures that devices should follow if they implement an OPTIONS "ping" procedure. This is achieved with a new header or targeting a specific address. It also means that devices that do not implement the resulting RFC will still function as they do today. If we go the route of introducing a whole new method, it would be years before it gets introduced into the market. We still need to keep the OPTIONS "ping" around, because that's what virtually everybody is doing. The only thing we proposed in the initial draft was some consistency with respect to the way responses were given, etc. We're not calling for drastic changes in the behavior of OPTIONS. In fact, if a device wanted to return a complete response with all of the features it supports, that'd be fine with me. When used as a "ping", it's primarily the response code the peer is looking for. The only negative side effect is a bit more bandwidth on the wire, which is likely inconsequential as compared to everything else. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, April 28, 2010 10:37 PM > To: Paul E. Jones > Cc: 'Dean Willis'; 'Michael Miller'; sipcore@ietf.org; 'Hadriel Kaplan' > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > Now that we have established the goal is devising some options/headers > to entirely change the behavior of OPTIONS, I would rather see a new > method: PING. Given the assumptions being made I can see few if any > downsides to this, and definite upsides. > > IMO the value of using OPTIONS for ping is in those cases where the > device being pinged doesn't know that it is being pinged. > > Thanks, > Paul > > Paul E. Jones wrote: > > Dean, > > > >> So for example, a new header field "Options-mode" with a value of > >> "ping" means "If you support this extension, do not proxy this > >> request, just send an immediate 200 OK response and do not bother > >> populating the Supported header field of the 200 OK response." > >> Somebody who didn't recognize the header field would just send a > >> conventional 200 OK response. > > > > Not objecting to the header, but I think we would have failed in our > effort > > if the message might possibly be proxied. The intent was for this to > be > > peer-to-peer. > > > >> And perhaps an option tag of "optionsmodeping". That way we can add > >> further options-modes, and option tags for them in the future as > (and > >> if) needed. > > > > So, you want a head like this: > > > > Options-Mode: ping > > > > Or this: > > > > Require: optionsmodeping > > > >> You could basically cut-and-paste the answer-mode draft and be done > >> writing in an hour. > > > > Oh, I'll be happy to plagiarize your work ... but not sure exactly > what you > > want me to copy :-) > > > > Paul > > > > > > > From HKaplan@acmepacket.com Wed Apr 28 20:51:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF8B3A67A3 for ; Wed, 28 Apr 2010 20:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAOs866wfA4b for ; Wed, 28 Apr 2010 20:51:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 27A5E3A6782 for ; Wed, 28 Apr 2010 20:51:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Apr 2010 23:50:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Apr 2010 23:50:51 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Wed, 28 Apr 2010 23:50:50 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> In-Reply-To: <011601cae747$5013a740$f03af5c0$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 03:51:07 -0000 The problem is OPTIONS really is meant for getting capabilities, and althou= gh it may also be used as a ping (and often is), to use one for *only* a pi= ng and not return capabilities is likely to cause a bunch of folks here to = say "then it's not an OPTIONS". So I think that has to be kept in to keep = this method name and get anywhere. If we did identify the target of the OPTIONS as a specific resource, like "= ping@ip/host", then I would have argued we could specify that it does retur= n capabilities but that this "ping" logical UA/resource simply has no capab= ilities beyond supporting the OPTIONS request. But really if it's proxies you're talking about they generally can represen= t their capabilities with fairly hard-coded static strings, afaict, and obv= iously the system receiving the response can just ignore the capabilities r= eturned if it doesn't care. So I'm not sure it makes much difference, does= it? -hadriel > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, April 28, 2010 10:55 PM >=20 > I don't see it quite the same way. I don't want to entirely change > OPTIONS, > but I do want to define procedures that devices should follow if they > implement an OPTIONS "ping" procedure. This is achieved with a new heade= r > or targeting a specific address. It also means that devices that do not > implement the resulting RFC will still function as they do today. >=20 > If we go the route of introducing a whole new method, it would be years > before it gets introduced into the market. We still need to keep the > OPTIONS "ping" around, because that's what virtually everybody is doing. >=20 > The only thing we proposed in the initial draft was some consistency with > respect to the way responses were given, etc. We're not calling for > drastic > changes in the behavior of OPTIONS. In fact, if a device wanted to retur= n > a > complete response with all of the features it supports, that'd be fine > with > me. When used as a "ping", it's primarily the response code the peer is > looking for. The only negative side effect is a bit more bandwidth on th= e > wire, which is likely inconsequential as compared to everything else. >=20 > Paul >=20 From paulej@packetizer.com Wed Apr 28 20:59:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C803A685B for ; Wed, 28 Apr 2010 20:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDF-nwyRBQs6 for ; Wed, 28 Apr 2010 20:59:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 5143B3A6ABA for ; Wed, 28 Apr 2010 20:59:01 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3T3wcMf028037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Apr 2010 23:58:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272513524; bh=fdiCP0JnEUA7Rc74pYRgl5miiCsi5ZPbwiaZ9Lb6iWU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Nu+q8QZimbXajPcwrmZFDOg1nJFt+GZkIIL80pHBNGsm6gmvUIGQMKchP7b5OVrUM surdPZk0J7ArajNPrdqqg35jCTNw3Hl48NJqcHPhix3+rP9KmaAjJp954tHHrW2Z+h wl1cpx9qOm8TJoNv1E5LeRwnlgAeWswcfYdqSNps= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3T3wbnn022242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Apr 2010 23:58:37 -0400 From: "Paul E. Jones" To: "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> Date: Wed, 28 Apr 2010 23:58:30 -0400 Message-ID: <011f01cae750$3b424840$b1c6d8c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoA== Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 03:59:02 -0000 Hadriel, > The problem is OPTIONS really is meant for getting capabilities, and > although it may also be used as a ping (and often is), to use one for > *only* a ping and not return capabilities is likely to cause a bunch of > folks here to say "then it's not an OPTIONS". So I think that has to > be kept in to keep this method name and get anywhere. We never proposed a use where capabilities are not returned. If folks wanted to do that, they could, but we're not prescribing different behavior w.r.t. OPTIONS payload content. Personally, I would reply with the same payload, "ping" or not. > If we did identify the target of the OPTIONS as a specific resource, > like "ping@ip/host", then I would have argued we could specify that it > does return capabilities but that this "ping" logical UA/resource > simply has no capabilities beyond supporting the OPTIONS request. What I really, really wanted to encourage is sending an OPTIONS message to the IP address of the device you wish you ping and with a SIP URI of "sip:hostport". This does not address a "user" and therefore makes it a little clearer that it's a device-level request. In any case, I would still return the same payload, just because I'd likely have it statically composed in memory and it would be trivial to return. > But really if it's proxies you're talking about they generally can > represent their capabilities with fairly hard-coded static strings, > afaict, and obviously the system receiving the response can just ignore > the capabilities returned if it doesn't care. So I'm not sure it makes > much difference, does it? I think that's true of most devices: they can be fairly static responses. What we were trying to do with this draft was not be disruptive to the existing SIP spec, but to try to get OPTIONS handled in a consistent manner when used as a "ping" mechanism. We didn't want to call for a whole different mode of operations, per se. Paul > -hadriel > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Wednesday, April 28, 2010 10:55 PM > > > > I don't see it quite the same way. I don't want to entirely change > > OPTIONS, > > but I do want to define procedures that devices should follow if they > > implement an OPTIONS "ping" procedure. This is achieved with a new > header > > or targeting a specific address. It also means that devices that do > not > > implement the resulting RFC will still function as they do today. > > > > If we go the route of introducing a whole new method, it would be > years > > before it gets introduced into the market. We still need to keep the > > OPTIONS "ping" around, because that's what virtually everybody is > doing. > > > > The only thing we proposed in the initial draft was some consistency > with > > respect to the way responses were given, etc. We're not calling for > > drastic > > changes in the behavior of OPTIONS. In fact, if a device wanted to > return > > a > > complete response with all of the features it supports, that'd be > fine > > with > > me. When used as a "ping", it's primarily the response code the peer > is > > looking for. The only negative side effect is a bit more bandwidth > on the > > wire, which is likely inconsequential as compared to everything else. > > > > Paul > > > From christer.holmberg@ericsson.com Wed Apr 28 22:24:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7F328C1AE for ; Wed, 28 Apr 2010 22:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7gFVRWGpA1g for ; Wed, 28 Apr 2010 22:24:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CC9023A67A6 for ; Wed, 28 Apr 2010 22:21:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-68-4bd916e7f3b0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0C.22.23532.7E619DB4; Thu, 29 Apr 2010 07:19:35 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 29 Apr 2010 07:19:34 +0200 From: Christer Holmberg To: "Paul E. Jones" , 'Hadriel Kaplan' , 'Paul Kyzivat' Date: Thu, 29 Apr 2010 07:19:34 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAACzxUg Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> In-Reply-To: <011f01cae750$3b424840$b1c6d8c0$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 05:24:46 -0000 Hi, >>The problem is OPTIONS really is meant for getting=20 >>capabilities, and although it may also be used as a ping (and often is), = to=20 >>use one for *only* a ping and not return capabilities is likely to=20 >>cause a bunch of folks here to say "then it's not an OPTIONS". So I=20 >>think that has to be kept in to keep this method name and get anywhere. >=20 >We never proposed a use where capabilities are not returned. =20 >If folks wanted to do that, they could, but we're not=20 >prescribing different behavior w.r.t. OPTIONS payload=20 >content. Personally, I would reply with the same payload,=20 >"ping" or not. > >>If we did identify the target of the OPTIONS as a specific resource,=20 >>like "ping@ip/host", then I would have argued we could specify that it=20 >>does return capabilities but that this "ping" logical UA/resource=20 >>simply has no capabilities beyond supporting the OPTIONS request. >=20 >What I really, really wanted to encourage is sending an=20 >OPTIONS message to the IP address of the device you wish you=20 >ping and with a SIP URI of "sip:hostport". This does not=20 >address a "user" and therefore makes it a little clearer that=20 >it's a device-level request. >=20 >In any case, I would still return the same payload, just=20 >because I'd likely have it statically composed in memory and=20 >it would be trivial to return. The message body payload part is easy to get rid of - you just include an e= mpty Accept header field in the OPTIONS request. >>But really if it's proxies you're talking about they generally can=20 >>represent their capabilities with fairly hard-coded static strings,=20 >>afaict, and obviously the system receiving the response can just=20 >>ignore the capabilities returned if it doesn't care. So=20 >>I'm not sure it makes much difference, does it? >=20 >I think that's true of most devices: they can be fairly static responses. I think one issue is how often you think these OPTIONS requests need to be = sent. If they are not sent that often, it's probably not a problem to retur= n what you would return in normal cases. Regards, Christer >=20 > What we were trying to do with this draft was not be=20 > disruptive to the existing SIP spec, but to try to get=20 > OPTIONS handled in a consistent manner when used as a "ping"=20 > mechanism. We didn't want to call for a whole different mode=20 > of operations, per se. >=20 > Paul > =20 > > -hadriel > >=20 > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Wednesday, April 28, 2010 10:55 PM > > > > > > I don't see it quite the same way. I don't want to=20 > entirely change=20 > > > OPTIONS, but I do want to define procedures that devices should=20 > > > follow if they implement an OPTIONS "ping" procedure. This is=20 > > > achieved with a new > > header > > > or targeting a specific address. It also means that=20 > devices that do > > not > > > implement the resulting RFC will still function as they do today. > > > > > > If we go the route of introducing a whole new method, it would be > > years > > > before it gets introduced into the market. We still need to keep=20 > > > the OPTIONS "ping" around, because that's what virtually=20 > everybody=20 > > > is > > doing. > > > > > > The only thing we proposed in the initial draft was some=20 > consistency > > with > > > respect to the way responses were given, etc. We're not=20 > calling for=20 > > > drastic changes in the behavior of OPTIONS. In fact, if a device=20 > > > wanted to > > return > > > a > > > complete response with all of the features it supports, that'd be > > fine > > > with > > > me. When used as a "ping", it's primarily the response code the=20 > > > peer > > is > > > looking for. The only negative side effect is a bit more=20 > bandwidth > > on the > > > wire, which is likely inconsequential as compared to=20 > everything else. > > > > > > Paul > > > > >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From HKaplan@acmepacket.com Wed Apr 28 22:36:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1048E3A67FF for ; Wed, 28 Apr 2010 22:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4969JJ8aXSIR for ; Wed, 28 Apr 2010 22:36:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 850B33A67A6 for ; Wed, 28 Apr 2010 22:36:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Apr 2010 01:36:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Apr 2010 01:36:14 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' Date: Thu, 29 Apr 2010 01:36:13 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAADM50w Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F15F0@mail> References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> In-Reply-To: <011f01cae750$3b424840$b1c6d8c0$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 05:36:30 -0000 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, April 28, 2010 11:59 PM >=20 > We never proposed a use where capabilities are not returned. If folks > wanted to do that, they could, but we're not prescribing different > behavior > w.r.t. OPTIONS payload content. Personally, I would reply with the same > payload, "ping" or not. Oh. Well someone did. :) Good, so we can move onto flipping coins to decide what syntax to use to ma= ke it clear the OPTIONS is using/expecting this draft's rules. :) -hadriel=20 From alexander.milinski@nsn.com Thu Apr 29 00:33:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43143A6BB5 for ; Thu, 29 Apr 2010 00:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbIGnyuGqjbO for ; Thu, 29 Apr 2010 00:33:56 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1AF4A28C1A8 for ; Thu, 29 Apr 2010 00:33:53 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3T7XWHD008074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Apr 2010 09:33:32 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3T7XVc6016217; Thu, 29 Apr 2010 09:33:31 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 09:33:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Apr 2010 09:33:30 +0200 Message-ID: <3F4C11BC54A36642BFB5875D599F47BD029E4A89@DEMUEXC013.nsn-intra.net> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F15F0@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAADM50wAARtvhA= References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com><4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com><4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com><1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com><00da01cae72e$4f5590c0$ee00b240$@com><8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com><010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com><011601cae747$5013a740$f03af5c0$@com><430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail><011f01cae750$3b424840$b1c6d8c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15F0@mail> From: "Milinski, Alexander (NSN - DE/Munich)" To: "ext Hadriel Kaplan" , "Paul E. Jones" , "Paul Kyzivat" X-OriginalArrivalTime: 29 Apr 2010 07:33:31.0396 (UTC) FILETIME=[446E0440:01CAE76E] Cc: Michael Miller , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 07:33:56 -0000 One moment please, before you start throwing the dice ... Having followed the debate and looked at the draft, it still isn't clear to me: What is broken today that the draft indends to fix? What are the underlying requirements for the solution? Alex > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan > Sent: Thursday, April 29, 2010 7:36 AM > To: Paul E. Jones; 'Paul Kyzivat' > Cc: 'Michael Miller'; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D=20 > Action:draft-jones-sip-options-ping-00.txt >=20 >=20 >=20 > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Wednesday, April 28, 2010 11:59 PM > >=20 > > We never proposed a use where capabilities are not=20 > returned. If folks > > wanted to do that, they could, but we're not prescribing different > > behavior > > w.r.t. OPTIONS payload content. Personally, I would reply=20 > with the same > > payload, "ping" or not. >=20 > Oh. Well someone did. :) >=20 > Good, so we can move onto flipping coins to decide what=20 > syntax to use to make it clear the OPTIONS is using/expecting=20 > this draft's rules. :) >=20 > -hadriel=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Thu Apr 29 07:05:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48EFA28C28F for ; Thu, 29 Apr 2010 07:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E4twAsMJKpp for ; Thu, 29 Apr 2010 07:05:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EAD943A6BD7 for ; Thu, 29 Apr 2010 07:00:32 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADYu2UtAZnwM/2dsb2JhbACdDXGkNZoGhRAE X-IronPort-AV: E=Sophos;i="4.52,295,1270425600"; d="scan'208";a="106310117" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2010 14:00:19 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3TE0J3M007575; Thu, 29 Apr 2010 14:00:19 GMT Message-ID: <4BD990F3.8020909@cisco.com> Date: Thu, 29 Apr 2010 10:00:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> In-Reply-To: <011601cae747$5013a740$f03af5c0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:05:56 -0000 Paul J, I see two alternatives here, but you seem to be straddling them. 1) you can leave the behavior of OPTIONS alone. Document a set of practices for how a UAC can use OPTIONS to accomplish a ping. In this case, the UAS never knows whether an OPTIONS it receives is intended as a capability query or a ping. + this is relatively quick to accomplish because it doesn't require standards action + this is relatively quick to deploy, because only the UACs that want to ping need be updated. - the benefit is limited because you are stuck with the way OPTIONS currently works, and with the variations in behavior that it allows. - pinging this way may be more costly than necessary because of the extra work of applying policy, including capabilities, and the extra size of the message to carry the capabilities 2) define new standardized behavior for pinging, with roles for both the UAC and UAS, that is different from what OPTIONS does today. + the behavior is not constrained by the existing definition of OPTIONS. It can be defined precisely for the purpose. + the implementation can be optimized. the server can "fast path" it, and policy application can be simplified because little is disclosed. - it will take longer to get specified because it must be standards track. (Note that this will be pretty much the same regardless of whether it is defined as new optional behavior of OPTIONS, or as a new method.) - it will take longer to deploy because both UAC and UAS must support it. I guess there is a possible variant on (1): also do a *clarification* of OPTIONS behavior in cases where there is some ambiguity about what response code should be returned in particular circumstances. I would be ok with that *if* the clarification applied to all uses of OPTIONS. But once you start to do that you start to pick up the negatives of (2). It would also be possible to do a combination of (1) and (2), where (2) is preferred if both UAS supports it, with fallback to (1) for those that don't. What I don't see is a way to avoid standards action and yet define special optional behavior by the UAS that the UAC can request and know was provided. This seems to be what you are seeking. Thanks, Paul K Paul E. Jones wrote: > Paul, > > I don't see it quite the same way. I don't want to entirely change OPTIONS, > but I do want to define procedures that devices should follow if they > implement an OPTIONS "ping" procedure. This is achieved with a new header > or targeting a specific address. It also means that devices that do not > implement the resulting RFC will still function as they do today. > > If we go the route of introducing a whole new method, it would be years > before it gets introduced into the market. We still need to keep the > OPTIONS "ping" around, because that's what virtually everybody is doing. > > The only thing we proposed in the initial draft was some consistency with > respect to the way responses were given, etc. We're not calling for drastic > changes in the behavior of OPTIONS. In fact, if a device wanted to return a > complete response with all of the features it supports, that'd be fine with > me. When used as a "ping", it's primarily the response code the peer is > looking for. The only negative side effect is a bit more bandwidth on the > wire, which is likely inconsequential as compared to everything else. > > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, April 28, 2010 10:37 PM >> To: Paul E. Jones >> Cc: 'Dean Willis'; 'Michael Miller'; sipcore@ietf.org; 'Hadriel Kaplan' >> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- >> 00.txt >> >> Now that we have established the goal is devising some options/headers >> to entirely change the behavior of OPTIONS, I would rather see a new >> method: PING. Given the assumptions being made I can see few if any >> downsides to this, and definite upsides. >> >> IMO the value of using OPTIONS for ping is in those cases where the >> device being pinged doesn't know that it is being pinged. >> >> Thanks, >> Paul >> >> Paul E. Jones wrote: >>> Dean, >>> >>>> So for example, a new header field "Options-mode" with a value of >>>> "ping" means "If you support this extension, do not proxy this >>>> request, just send an immediate 200 OK response and do not bother >>>> populating the Supported header field of the 200 OK response." >>>> Somebody who didn't recognize the header field would just send a >>>> conventional 200 OK response. >>> Not objecting to the header, but I think we would have failed in our >> effort >>> if the message might possibly be proxied. The intent was for this to >> be >>> peer-to-peer. >>> >>>> And perhaps an option tag of "optionsmodeping". That way we can add >>>> further options-modes, and option tags for them in the future as >> (and >>>> if) needed. >>> So, you want a head like this: >>> >>> Options-Mode: ping >>> >>> Or this: >>> >>> Require: optionsmodeping >>> >>>> You could basically cut-and-paste the answer-mode draft and be done >>>> writing in an hour. >>> Oh, I'll be happy to plagiarize your work ... but not sure exactly >> what you >>> want me to copy :-) >>> >>> Paul >>> >>> >>> > > > From pkyzivat@cisco.com Thu Apr 29 07:16:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8897228C2C1 for ; Thu, 29 Apr 2010 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rM7pDN6-XTY for ; Thu, 29 Apr 2010 07:16:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5BFBC3A6BC5 for ; Thu, 29 Apr 2010 07:12:32 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAYx2UtAZnwN/2dsb2JhbACdDnGkRZoGhRAE X-IronPort-AV: E=Sophos;i="4.52,295,1270425600"; d="scan'208";a="106451508" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2010 14:12:11 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3TECBIM020944; Thu, 29 Apr 2010 14:12:11 GMT Message-ID: <4BD993BB.10202@cisco.com> Date: Thu, 29 Apr 2010 10:12:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Hadriel Kaplan' , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:16:05 -0000 Christer Holmberg wrote: > The message body payload part is easy to get rid of - you just include an empty Accept header field in the OPTIONS request. That *could* work, if the UAS understands and does it right. I'll venture to guess that most existing implementations would either: a) return the SDP anyway (assuming there were prepared to return it.) b) barf and return some error code, hopefully 406 If (a) happened, you could file a complaint against the vendor of the UAS. But I think you could make a good case that (b) is appropriate in this case, as it would if you put an empty Accept in an INVITE. Thanks, Paul From HKaplan@acmepacket.com Thu Apr 29 07:52:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82413A6821 for ; Thu, 29 Apr 2010 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe3hVH9SjivD for ; Thu, 29 Apr 2010 07:52:16 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 150D53A6AB2 for ; Thu, 29 Apr 2010 07:52:15 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Apr 2010 10:52:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Apr 2010 10:52:00 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Christer Holmberg Date: Thu, 29 Apr 2010 10:51:59 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnpgnpiANa6YtzR5acL8rlD4N6kwABWIWA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F16AF@mail> References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <4BD993BB.10202@cisco.com> In-Reply-To: <4BD993BB.10202@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: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:52:16 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 29, 2010 10:12 AM >=20 > Christer Holmberg wrote: >=20 > > The message body payload part is easy to get rid of - you just include > an empty Accept header field in the OPTIONS request. >=20 > That *could* work, if the UAS understands and does it right. >=20 > I'll venture to guess that most existing implementations would either: > a) return the SDP anyway (assuming there were prepared to return it.) > b) barf and return some error code, hopefully 406 >=20 > If (a) happened, you could file a complaint against the vendor of the > UAS. But I think you could make a good case that (b) is appropriate in > this case, as it would if you put an empty Accept in an INVITE. Unfortunately I think 3261 is ambiguous for that: A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). -hadriel From paulej@packetizer.com Thu Apr 29 08:02:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AB33A696F for ; Thu, 29 Apr 2010 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5rBUGXbIPej for ; Thu, 29 Apr 2010 08:02:03 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D5DC03A6AFF for ; Thu, 29 Apr 2010 08:01:59 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3TF1TKu026210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 11:01:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272553295; bh=35qCVpO1XGLX+HdlwKdqa0mJHdO2VimB7A2bWZ4JRQ0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=V/OvdQmuU58S/WN9dCBO1qnXrMWVSkcVyNUAYZD9n93LRuHTl01oXbcuki58BuLKF BYu/y1d9eShMW0KUhKOIpvb+4tp+x9U0FktFF12gr77UJAsg9Un6oO/3UNNO1ixGBV d5kk9vwA6sPQGsK2TixsDLlRlEvvfdYC00YSKVaY= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3TF1RAR024202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 11:01:27 -0400 From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Hadriel Kaplan'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> In-Reply-To: Date: Thu, 29 Apr 2010 11:01:20 -0400 Message-ID: <017f01cae7ac$d3f5e860$7be1b920$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAACzxUgABRw2IA= Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:02:05 -0000 Christer, > >I think that's true of most devices: they can be fairly static > responses. > > I think one issue is how often you think these OPTIONS requests need to > be sent. If they are not sent that often, it's probably not a problem > to return what you would return in normal cases. I expect that to vary for a number of reasons, but I would suspect that the more frequent they are sent, the less important the bandwidth would be. There's no requirement to even look at the SDP, and I doubt a device sending a "ping" packet would. In any case, as you suggest we could get rid of it if it was important via the Accept header. But, that actually would mean more processing. It's either CPU or bandwidth :-) Paul From paulej@packetizer.com Thu Apr 29 08:12:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35483A693C for ; Thu, 29 Apr 2010 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1XOuFJvyOgN for ; Thu, 29 Apr 2010 08:12:00 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 06E273A696F for ; Thu, 29 Apr 2010 08:11:41 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3TFBDhL026854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 11:11:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272553880; bh=gc0HwyUIhijfpTmMOARrgmhHb/ZjPBdm6+8E/yCPAKA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NRq/5qAL0KkDxKcUeFFRALd1oBPd+dWHy33/NF7TM3mMtKvKuT1yxMw9bYlkaFmR/ jXgXfij65SuB1LkBTCZtLAUJSIX6eBI5jADp8jAgMrpNmo/I1P3a8x/R8TzWxIZ0Ib dby8zTCYXdbWF2wVA5z8wUfn1ekchq7mkb+/d5KU= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3TFBBo8024231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 11:11:12 -0400 From: "Paul E. Jones" To: "'Milinski, Alexander \(NSN - DE/Munich\)'" , "'ext Hadriel Kaplan'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com><4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com><4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com><1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com><00da01cae72e$4f5590c0$ee00b240$@com><8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com><010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com><011601cae747$5013a740$f03af5c0$@com><430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail><011f01cae750$3b424840$b1c6d8c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15F0@mail> <3F4C11BC54A36642BFB5875D599F47BD029E4A89@DEMUEXC013.nsn-intra.net> In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD029E4A89@DEMUEXC013.nsn-intra.net> Date: Thu, 29 Apr 2010 11:11:05 -0400 Message-ID: <018201cae7ae$308be240$91a3a6c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAADM50wAARtvhAAD9tS0A== Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:12:17 -0000 Alex, There are two objectives: 1) Legitimize the use of OPTIONS as a "ping" mechanism, since virtually every product I've seen does that, but it's not described in any RFC 2) Try to converge on behavior that is in line with what RFC 3261 says, but narrow the recommended response codes. When a device cannot accept to requests, I've seen the following response codes returned: 408, 480, 503, 505, and 600. The only thing place where I've seen implementation agreement is returning a 200 when things are OK. In meeting these objectives, we really, really wanted to not make any changes to the core spec, but I have no objection to introducing a new header, for example, to hint as to the purpose of the OPTIONS: I just don't personally think it's that important, but others apparently do. Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Milinski, Alexander (NSN - DE/Munich) > Sent: Thursday, April 29, 2010 3:34 AM > To: ext Hadriel Kaplan; Paul E. Jones; Paul Kyzivat > Cc: Michael Miller; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > One moment please, before you start throwing the dice ... > > Having followed the debate and looked at the draft, it still isn't > clear > to me: > What is broken today that the draft indends to fix? > What are the underlying requirements for the solution? > > Alex > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan > > Sent: Thursday, April 29, 2010 7:36 AM > > To: Paul E. Jones; 'Paul Kyzivat' > > Cc: 'Michael Miller'; sipcore@ietf.org > > Subject: Re: [sipcore] FW: I-D > > Action:draft-jones-sip-options-ping-00.txt > > > > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Wednesday, April 28, 2010 11:59 PM > > > > > > We never proposed a use where capabilities are not > > returned. If folks > > > wanted to do that, they could, but we're not prescribing different > > > behavior > > > w.r.t. OPTIONS payload content. Personally, I would reply > > with the same > > > payload, "ping" or not. > > > > Oh. Well someone did. :) > > > > Good, so we can move onto flipping coins to decide what > > syntax to use to make it clear the OPTIONS is using/expecting > > this draft's rules. :) > > > > -hadriel > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Thu Apr 29 08:12:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6073A687F for ; Thu, 29 Apr 2010 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEciJ4M49Kkz for ; Thu, 29 Apr 2010 08:12:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 824553A6BC5 for ; Thu, 29 Apr 2010 08:12:22 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3TFBxar001825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Apr 2010 10:12:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BD9A1BF.3080204@nostrum.com> Date: Thu, 29 Apr 2010 10:11:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <017f01cae7ac$d3f5e860$7be1b920$@com> In-Reply-To: <017f01cae7ac$d3f5e860$7be1b920$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:12:47 -0000 [as a participant] On 4/29/10 10:01 AM, Paul E. Jones wrote: > There's no requirement to even look at the SDP, and I doubt a device > sending a "ping" packet would. If you're trying to accomplish something orthogonal to OPTIONS (i.e, liveness tests), and planning to ignore the capabilities indicated by the responding entity, why do you want to use OPTIONS? /a From HKaplan@acmepacket.com Thu Apr 29 08:43:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE663A6A93 for ; Thu, 29 Apr 2010 08:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af4idh2b3UiE for ; Thu, 29 Apr 2010 08:43:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5F1713A6BC4 for ; Thu, 29 Apr 2010 08:43:22 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Apr 2010 11:43:06 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Apr 2010 11:43:06 -0400 From: Hadriel Kaplan To: Adam Roach , "Paul E. Jones" Date: Thu, 29 Apr 2010 11:42:49 -0400 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnrlHA0KYUK0IGSeCBBFVQ8WArbAAArhPA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F16DE@mail> References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <017f01cae7ac$d3f5e860$7be1b920$@com> <4BD9A1BF.3080204@nostrum.com> In-Reply-To: <4BD9A1BF.3080204@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 15:43:25 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, April 29, 2010 11:12 AM > To: Paul E. Jones >=20 > On 4/29/10 10:01 AM, Paul E. Jones wrote: > > There's no requirement to even look at the SDP, and I doubt a device > > sending a "ping" packet would. >=20 > If you're trying to accomplish something orthogonal to OPTIONS (i.e, > liveness tests), and planning to ignore the capabilities indicated by > the responding entity, why do you want to use OPTIONS? But it's _not_ really orthogonal to OPTIONS. We're using the term "ping" h= ere, but that's a bit misleading - the request is really being used to dete= rmine the *state* of the next-hop. Classic "ping" is just "are you there?"= - like ICMP, or a STUN or CRLF keepalive. But this draft is also clarifyi= ng what to respond with for actual SIP processing state - admin up/down, ov= erloaded, etc. One could argue that the returned state is in fact a returned "capability" = - the capability of the responder to handle other requests. And 3261 pretty clearly not only allows OPTIONS to do that, but describes h= ow it is done. Section 11.2: The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. -hadriel From paulej@packetizer.com Thu Apr 29 10:02:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168EB3A6BEA for ; Thu, 29 Apr 2010 10:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbhdRXfyFer2 for ; Thu, 29 Apr 2010 10:02:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 33D053A6B67 for ; Thu, 29 Apr 2010 10:02:02 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3TH1XWG002765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 13:01:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272560499; bh=YWnbHwjNhuW+Vfdul3NovkWDyQhlnr1hzs4R5LBm7uE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LuZTTT0LO9c0S8I5sJkjpMPbVqL10WThBtnthwqwmdRjsZkC0u8F0hXFweWUbg3Tk MGOkWwuwbFkvKIhSyKBfAT21r6fkbRDCf0Uvu/ncHzHMIH+uSVUw1/T1c8JGOnSVmO A+ymqoWswxIvdBoEeEFaQjITguJzXD9new5wvddc= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3TH1WmE024494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 13:01:32 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <4BD990F3.8020909@cisco.com> In-Reply-To: <4BD990F3.8020909@cisco.com> Date: Thu, 29 Apr 2010 13:01:25 -0400 Message-ID: <01cf01cae7bd$9a1d09f0$ce571dd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnpFMz4woQ8XkUTeGR0rHzjLt0swAFfn5Q Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:02:04 -0000 Paul, > I see two alternatives here, but you seem to be straddling them. I've been accused of that before :-) > 1) you can leave the behavior of OPTIONS alone. > Document a set of practices for how a UAC can use > OPTIONS to accomplish a ping. In this case, the > UAS never knows whether an OPTIONS it receives > is intended as a capability query or a ping. Yes and no. My thought was a device that receives an OPTIONS directed to the device (i.e., Request URI is sip:hostport), then it could assume it's likely a "ping". > + this is relatively quick to accomplish because > it doesn't require standards action It is true that there is minimal work, but what we need to do is legitimize OPTIONS for use as a "ping" method and agree on response codes. > + this is relatively quick to deploy, because > only the UACs that want to ping need be updated. Definitely: this is definitely not something we're suggesting to send across the Internet. This is a peer-to-peer relationship. > - the benefit is limited because you are stuck > with the way OPTIONS currently works, and with > the variations in behavior that it allows. Understood, but what is the problem with that? Apparently, many felt it wasn't an issue since this is widely, inconsistently deployed > - pinging this way may be more costly than > necessary because of the extra work of applying > policy, including capabilities, and the extra > size of the message to carry the capabilities Yeah, but our intent was that this would be done over a local link and probably only when the device is otherwise not generating traffic. Perhaps the thing I believe is a non-issue is the composition and processing of those messages. Surely folks are not going to construct that response based on querying a bunch of configuration information upon every request. I'd assume the information is readily in hand and perhaps even sitting in a buffer read to be copied as-is. > 2) define new standardized behavior for pinging, > with roles for both the UAC and UAS, that is > different from what OPTIONS does today. We're not looking for something that is different, per se, but just to agree on behavior. This behavior is in line with what 3261 says, but let's not do things that are all over the place. > + the behavior is not constrained by the existing > definition of OPTIONS. It can be defined > precisely for the purpose. We definitely want to constrain behavior: that's a major reason preparing the draft. > + the implementation can be optimized. > the server can "fast path" it, and policy > application can be simplified because little > is disclosed. It could be, but what I'm having trouble with is what I would do differently if it was a "ping" or not. For example, if I build a GW and I received an OPTIONS addressed to sip:192.168.1.10, I would reply the same way every time: I'd assume it's likely a "ping". And, that response should be a valid OPTIONS reply regardless of whether it's a "ping" or not. That is, no different code path followed. I would do the same thing if I were building an SBC: I'd assume the message is a "ping" and comply with this spec: a subset of what RFC 3261 describes. If the "ping" was directed to "sip:+19194762048@192.168.1.10", I might return something different, since there may be capabilities associated with a given port that is different than the GW as a whole. > - it will take longer to get specified because it > must be standards track. (Note that this will be > pretty much the same regardless of whether it is > defined as new optional behavior of OPTIONS, or > as a new method.) Understood, which is why I didn't really want to introduce new functionality. I do not object to introducing a header, for example: that seems like a minimal and perhaps useful addition. > - it will take longer to deploy because both > UAC and UAS must support it. Exactly, which is why I think defining a whole new method like PING is out of the question. SIP is too old at this point to introduce such new methods, in my opinion. It would take years to approve and we'd have to live with both OPTIONS and PING for 20 years. > I guess there is a possible variant on (1): > also do a *clarification* of OPTIONS behavior in cases where there is > some ambiguity about what response code should be returned in > particular > circumstances. I would be ok with that *if* the clarification applied > to > all uses of OPTIONS. But once you start to do that you start to pick up > the negatives of (2). I can't fix every problem with OPTIONS and I don't see a reason to expand this draft beyond that. If we were introducing new functionality, I'd agree... but I'd prefer we didn't introduce new functionality. > It would also be possible to do a combination of (1) and (2), where (2) > is preferred if both UAS supports it, with fallback to (1) for those > that don't. What I think we should do is more along the lines of (1), with possible consideration of introducing a header or tag to serve as a hint as to the purpose of the OPTIONS message. (I know that compels you to suggest that I might be bipolar, but I'm only trying recognize the fact that some find this useful. Still, I'd expect the same processing on the box.) > What I don't see is a way to avoid standards action and yet define > special optional behavior by the UAS that the UAC can request and know > was provided. This seems to be what you are seeking. So, what's special? We're constraining behavior, not expanding it. Paul From paulej@packetizer.com Thu Apr 29 10:04:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D783A6A2F for ; Thu, 29 Apr 2010 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBPtrMe0QpCQ for ; Thu, 29 Apr 2010 10:04:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id E83143A69F5 for ; Thu, 29 Apr 2010 10:04:13 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3TH3iTV002884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 13:03:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272560630; bh=w8Mik2soF+ZEjAMA4SQdvFYbAuiC4YUS0gjB2jTPIXA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=IIIrRa7AyQa0usyNoP4LRypOkEVgsV7/LWNUJ7UQrkdGzaoup2yQFsS5l9ipA6PXK SJspbRxvKtqngxFb2Tex0Lb5FikDh5H4BHGPHc0Pnfe82ePbjQDozZYCeIjqdfYuc0 acKxujP6MiliRJwxrf/zAbkLVWP9XFEi8Ug3Nwzw= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3TH3hOv024533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 13:03:43 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Christer Holmberg'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <4BD993BB.10202@cisco.com> In-Reply-To: <4BD993BB.10202@cisco.com> Date: Thu, 29 Apr 2010 13:03:35 -0400 Message-ID: <01d201cae7bd$e7eb1960$b7c14c20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrnpf346Mv6+b/oSqqb4mD6LxFfzgAF7P1A Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:04:15 -0000 Paul, > > The message body payload part is easy to get rid of - you just > include an empty Accept header field in the OPTIONS request. > > That *could* work, if the UAS understands and does it right. If it didn't, wouldn't it be non-compliant with 3261? > I'll venture to guess that most existing implementations would either: > a) return the SDP anyway (assuming there were prepared to return it.) > b) barf and return some error code, hopefully 406 > > If (a) happened, you could file a complaint against the vendor of the > UAS. But I think you could make a good case that (b) is appropriate in > this case, as it would if you put an empty Accept in an INVITE. Why would you argue that a device should do (b)? Paul From paulej@packetizer.com Thu Apr 29 10:12:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F033A679C for ; Thu, 29 Apr 2010 10:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKZQSrfUVtcD for ; Thu, 29 Apr 2010 10:12:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id A3F073A6A0F for ; Thu, 29 Apr 2010 10:12:34 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3THCAio003509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 13:12:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272561136; bh=WmuoMQLnzR0ARI4wn7Y0t/Gwn2CdMdRkgf4nJvlJd50=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XcJJrFzq0Ph2tauh6i7mGzn+8nfxP6eEzEXTobFLRP6RA0SREtdikPx/kgB8ouXH6 FfUsdqYwUEMUWJ/33uEA3naNO+fYJML1XaKeB2V7BYBfBJnvSoAuLvhzmNUOvY0aNi rCGYUPpxavCNM6hvHmqYEfhBPv6271qjQ5mFOrCw= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3THC95o024559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 13:12:09 -0400 From: "Paul E. Jones" To: "'Adam Roach'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <017f01cae7ac$d3f5e860$7be1b920$@com> <4BD9A1BF.3080204@nostrum.com> In-Reply-To: <4BD9A1BF.3080204@nostrum.com> Date: Thu, 29 Apr 2010 13:12:01 -0400 Message-ID: <01ea01cae7bf$15918ab0$40b4a010$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnrmneGg+NyI3zTRyczleHk9z9YwAEGvSw Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:12:40 -0000 Adam, > On 4/29/10 10:01 AM, Paul E. Jones wrote: > > There's no requirement to even look at the SDP, and I doubt a device > > sending a "ping" packet would. > > If you're trying to accomplish something orthogonal to OPTIONS (i.e, > liveness tests), and planning to ignore the capabilities indicated by > the responding entity, why do you want to use OPTIONS? Because that's what lots of vendors have elected to do. We submitted this document as a reaction to the fact that it's widely, but inconsistently implemented. We didn't submit the document because we wanted to define a new behavior and encourage people to adopt it. Paul From christer.holmberg@ericsson.com Thu Apr 29 10:38:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72A83A6A8F for ; Thu, 29 Apr 2010 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.276 X-Spam-Level: X-Spam-Status: No, score=-5.276 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeaNtccCOLFW for ; Thu, 29 Apr 2010 10:38:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5DF403A69AD for ; Thu, 29 Apr 2010 10:38:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-84-4bd9c3f8bbbc Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 31.01.08537.8F3C9DB4; Thu, 29 Apr 2010 19:38:00 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 29 Apr 2010 19:38:00 +0200 From: Christer Holmberg To: SIPCORE Date: Thu, 29 Apr 2010 19:37:59 +0200 Thread-Topic: SigComp and Service-Route Thread-Index: AQHK58K2VbA2czSRtUC38BERDQCunA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] SigComp and Service-Route X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:38:18 -0000 Hi, I appologize if the following issue have been discussed and solved before. When reading RFC 5049 (Sigcomp), the UA figures out whether the outbound proxy supports sigcomp by looking at outbound proxie's entry in the Service-Route in the REGISTER response. My questions are: 1. How can the UA ensure that the outbound proxy will be listed in the Service-Route in the first place? RFC 3608 (Service-Route) does not mandate the registrar to insert any intermediaries in the Service-Route, e.g based on Path. It's all based on local policy. 2. Even if the registrar would build the Service-Route based on Path, how does it know that the Path address/port values will be usable/routable in the UA-towards-registrar direction (Path is supposed to be used in the registrar-towards-UA direction)? This is similar to the Record-Route problem, and intermediaries with different network addresses/ports per direction would have to insert "double Path". I guess the outbound proxy could insert itself in the Service-Route, but that is not described anywhere in RFC 5049, and it is also a SHOULD NOT in RFC 3608. Regards, Christer From christer.holmberg@ericsson.com Thu Apr 29 10:45:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01D93A6B49 for ; Thu, 29 Apr 2010 10:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rErHaTk5jQi for ; Thu, 29 Apr 2010 10:45:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 09B2D3A6B27 for ; Thu, 29 Apr 2010 10:45:06 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-be-4bd9c594d095 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.11.21861.495C9DB4; Thu, 29 Apr 2010 19:44:52 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 29 Apr 2010 19:44:52 +0200 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Date: Thu, 29 Apr 2010 19:43:42 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnpgnpiANa6YtzR5acL8rlD4N6kwABWIWAAAYFyEs= Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <4BD993BB.10202@cisco.com>, <430FC6BDED356B4C8498F634416644A91A8A5F16AF@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F16AF@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" , 'Michael Miller' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 17:45:08 -0000 Hi, You DO insert Accept, but with no values. AFAIK, that will override any def= ault values.=20 Regards, Christer ________________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] Sent: Thursday, April 29, 2010 5:51 PM To: Paul Kyzivat; Christer Holmberg Cc: Paul E. Jones; 'Michael Miller'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 29, 2010 10:12 AM > > Christer Holmberg wrote: > > > The message body payload part is easy to get rid of - you just include > an empty Accept header field in the OPTIONS request. > > That *could* work, if the UAS understands and does it right. > > I'll venture to guess that most existing implementations would either: > a) return the SDP anyway (assuming there were prepared to return it.) > b) barf and return some error code, hopefully 406 > > If (a) happened, you could file a complaint against the vendor of the > UAS. But I think you could make a good case that (b) is appropriate in > this case, as it would if you put an empty Accept in an INVITE. Unfortunately I think 3261 is ambiguous for that: A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). -hadriel= From christer.holmberg@ericsson.com Thu Apr 29 12:28:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD553A68EE for ; Thu, 29 Apr 2010 12:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DghGP9wAUfjg for ; Thu, 29 Apr 2010 12:28:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DCB103A695A for ; Thu, 29 Apr 2010 12:28:13 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-1a-4bd9ddbe8dba Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.25.21861.EBDD9DB4; Thu, 29 Apr 2010 21:27:59 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Apr 2010 21:27:58 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 29 Apr 2010 21:27:58 +0200 From: Christer Holmberg To: "Paul E. Jones" , "'Milinski, Alexander (NSN - DE/Munich)'" , 'ext Hadriel Kaplan' , 'Paul Kyzivat' Date: Thu, 29 Apr 2010 21:23:16 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAADM50wAARtvhAAD9tS0AAJB0WH Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com><4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com><4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com><1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com><00da01cae72e$4f5590c0$ee00b240$@com><8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com><010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com><011601cae747$5013a740$f03af5c0$@com><430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail><011f01cae750$3b424840$b1c6d8c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15F0@mail> <3F4C11BC54A36642BFB5875D599F47BD029E4A89@DEMUEXC013.nsn-intra.net>, <018201cae7ae$308be240$91a3a6c0$@com> In-Reply-To: <018201cae7ae$308be240$91a3a6c0$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 19:28:15 -0000 Hi, >There are two objectives: >1) Legitimize the use of OPTIONS as a "ping" mechanism, since virtually >every product I've seen does that, but it's not described in any RFC >2) Try to converge on behavior that is in line with what RFC 3261 says, bu= t >narrow the recommended response codes. When a device cannot accept to >requests, I've seen the following response codes returned: 408, 480, 503, >505, and 600. The only thing place where I've seen implementation agreemen= t >is returning a 200 when things are OK. > >In meeting these objectives, we really, really wanted to not make any >changes to the core spec, but I have no objection to introducing a new >header, for example, to hint as to the purpose of the OPTIONS: I just don'= t >personally think it's that important, but others apparently do. In order for me to form an opinion on that, I would need to know how freque= nt the "pings" are expected to be sent. OPTIONS is not the only method that is too "heavy" if sent too often. Peopl= e have been using frequent re-registrations in order to do NAT keep-alives,= and that's also bad. That is one reason we have defined the usage of STUN = for keep-alives, because it's much more "lightweight". So, I think it would be useful to know how often (the minimum value) these = pings are expected to be sent.=20 Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Milinski, Alexander (NSN - DE/Munich) > Sent: Thursday, April 29, 2010 3:34 AM > To: ext Hadriel Kaplan; Paul E. Jones; Paul Kyzivat > Cc: Michael Miller; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping- > 00.txt > > One moment please, before you start throwing the dice ... > > Having followed the debate and looked at the draft, it still isn't > clear > to me: > What is broken today that the draft indends to fix? > What are the underlying requirements for the solution? > > Alex > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan > > Sent: Thursday, April 29, 2010 7:36 AM > > To: Paul E. Jones; 'Paul Kyzivat' > > Cc: 'Michael Miller'; sipcore@ietf.org > > Subject: Re: [sipcore] FW: I-D > > Action:draft-jones-sip-options-ping-00.txt > > > > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Wednesday, April 28, 2010 11:59 PM > > > > > > We never proposed a use where capabilities are not > > returned. If folks > > > wanted to do that, they could, but we're not prescribing different > > > behavior > > > w.r.t. OPTIONS payload content. Personally, I would reply > > with the same > > > payload, "ping" or not. > > > > Oh. Well someone did. :) > > > > Good, so we can move onto flipping coins to decide what > > syntax to use to make it clear the OPTIONS is using/expecting > > this draft's rules. :) > > > > -hadriel > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From pkyzivat@cisco.com Thu Apr 29 12:56:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286383A6A2F for ; Thu, 29 Apr 2010 12:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMa0l71OJFCg for ; Thu, 29 Apr 2010 12:56:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 659773A67DA for ; Thu, 29 Apr 2010 12:56:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGqB2UtAZnwN/2dsb2JhbACdFHGjZpl1hRAE X-IronPort-AV: E=Sophos;i="4.52,297,1270425600"; d="scan'208";a="106426569" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2010 19:56:30 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3TJuU4p005725; Thu, 29 Apr 2010 19:56:30 GMT Message-ID: <4BD9E46F.70606@cisco.com> Date: Thu, 29 Apr 2010 15:56:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <4BD990F3.8020909@cisco.com> <01cf01cae7bd$9a1d09f0$ce571dd0$@com> In-Reply-To: <01cf01cae7bd$9a1d09f0$ce571dd0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 19:56:46 -0000 Paul E. Jones wrote: > Paul, > >> I see two alternatives here, but you seem to be straddling them. > > I've been accused of that before :-) And you're still at it here. >> 1) you can leave the behavior of OPTIONS alone. >> Document a set of practices for how a UAC can use >> OPTIONS to accomplish a ping. In this case, the >> UAS never knows whether an OPTIONS it receives >> is intended as a capability query or a ping. > > Yes and no. My thought was a device that receives an OPTIONS directed to > the device (i.e., Request URI is sip:hostport), then it could assume it's > likely a "ping". Note: I presented these as alternatives, but you are trying to subsume some of the features of (2) into (1) without also accepting the consequences. Your statement here is saying that the recipient can discern a distinction between OPTIONS that mean ping from those that don't, based on the form of the R-URI. That of course presumes that the recipient agrees that there is such a distinction. Since the existing definition of OPTIONS has no such distinction, this is an *extension* to OPTIONS, and hence achieving it would require standards action. >> + this is relatively quick to accomplish because >> it doesn't require standards action > > It is true that there is minimal work, but what we need to do is legitimize > OPTIONS for use as a "ping" method and agree on response codes. As soon as you say that, you have said you don't want option (1). What you are asking for is option (2). Or *maybe* you are talking about is what I describe below as: "variant on (1): also do a *clarification* of OPTIONS behavior in cases where there is some ambiguity about what response code...". If that is the case, then lets discuss that one in all its gory details and implications. >> + this is relatively quick to deploy, because >> only the UACs that want to ping need be updated. > > Definitely: this is definitely not something we're suggesting to send across > the Internet. This is a peer-to-peer relationship. I don't get your point. It has no relation to the bullet above it is responding to. In any case, you won't get any traction here for a proposal that requires matching configuration of the two "peers" in this ping relationship. That's entirely contrary to the point I was making - that the UAS need not be aware this is a ping, or event that there is such a thing as a ping. Rather, here "ping" is a usage of OPTIONS whose significance is only known to the UAC. >> - the benefit is limited because you are stuck >> with the way OPTIONS currently works, and with >> the variations in behavior that it allows. > > Understood, but what is the problem with that? Apparently, many felt it > wasn't an issue since this is widely, inconsistently deployed You are also stuck with the ambiguity in what response is returned in various situations, as well as the possibility that undesired capabilities might be returned, or the the device might decide to forward the request. Those are all part of accepting OPTIONS for what it currently is. >> - pinging this way may be more costly than >> necessary because of the extra work of applying >> policy, including capabilities, and the extra >> size of the message to carry the capabilities > > Yeah, but our intent was that this would be done over a local link and > probably only when the device is otherwise not generating traffic. Perhaps > the thing I believe is a non-issue is the composition and processing of > those messages. Surely folks are not going to construct that response based > on querying a bunch of configuration information upon every request. I'd > assume the information is readily in hand and perhaps even sitting in a > buffer read to be copied as-is. If the thing you are pinging is a white box to you, then maybe you know all that. But in any sort of multi-vendor situation that is likely not to be the case. For instance, if you send OPTIONS to a gateway, it *might* decide it should investigate its current resources before responding with its capabilities. The boxes you are familiar may not work that way. But don't make that assumption about all boxes. >> 2) define new standardized behavior for pinging, >> with roles for both the UAC and UAS, that is >> different from what OPTIONS does today. > > We're not looking for something that is different, per se, but just to agree > on behavior. This behavior is in line with what 3261 says, but let's not do > things that are all over the place. As best I can tell, you still want some options to be treated as ping, while allowing others to be treated as capability query and handled differently. That is *new standardized behavior* in my book. Alternately, maybe you are asking for OPTIONS, on all devices in all circumstances, to be more deterministic than it currently is, so that it is more suitable for ping usage while still being simultaneously suitable as a capability query. This is *still* a normative change, though a smaller one than the other. PLEASE clarify which of these you want. >> + the behavior is not constrained by the existing >> definition of OPTIONS. It can be defined >> precisely for the purpose. > > We definitely want to constrain behavior: that's a major reason preparing > the draft. You misunderstand me. Of course the behavior is constrained. Its just that there are two different behaviors: - capability query behavior - ping behavior But these could be specified independently, so that a ping can have a more circumscribed behavior than the capability query behavior has. >> + the implementation can be optimized. >> the server can "fast path" it, and policy >> application can be simplified because little >> is disclosed. > > It could be, but what I'm having trouble with is what I would do differently > if it was a "ping" or not. For example, if I build a GW and I received an > OPTIONS addressed to sip:192.168.1.10, I would reply the same way every > time: I'd assume it's likely a "ping". And, that response should be a valid > OPTIONS reply regardless of whether it's a "ping" or not. That is, no > different code path followed. I would do the same thing if I were building > an SBC: I'd assume the message is a "ping" and comply with this spec: a > subset of what RFC 3261 describes. > If the "ping" was directed to "sip:+19194762048@192.168.1.10", I might > return something different, since there may be capabilities associated with > a given port that is different than the GW as a whole. Then you are asking that the OPTIONS sent to sip:192.168.1.10 might produce a different result than OPTIONS sent to sip:+19194762048@192.168.1.10. That is of course *permitted* under the current definition of OPTIONS. But it isn't *required*. And you want there to be specific semantics to the sip:192.168.1.10 form. In the context of your GW example that makes a certain amount of sense. When the target is some other sort of device, say a phone, that may not make much sense. My point is that if you want to ascribe specific semantics to options when the host is an ip address and the user part is missing, then that will be a standards action to accomplish, and then you will have to wait while it is implemented. And, I think you may have difficulty getting everyone to agree. >> - it will take longer to get specified because it >> must be standards track. (Note that this will be >> pretty much the same regardless of whether it is >> defined as new optional behavior of OPTIONS, or >> as a new method.) > > Understood, which is why I didn't really want to introduce new > functionality. But you *do* want to introduce new functionality: You want to specify that all those implementations that do it a way different than what you propose should change to do it this way. That is new. > I do not object to introducing a header, for example: that > seems like a minimal and perhaps useful addition. > >> - it will take longer to deploy because both >> UAC and UAS must support it. > > Exactly, which is why I think defining a whole new method like PING is out > of the question. SIP is too old at this point to introduce such new > methods, in my opinion. It would take years to approve and we'd have to > live with both OPTIONS and PING for 20 years. It will take no longer to introduce a PING method, and no more effort to implement, than to introduce a new header or a new option tag, or simply to document new behavior and get it approved as a *standard* and then get it widely implemented. >> I guess there is a possible variant on (1): >> also do a *clarification* of OPTIONS behavior in cases where there is >> some ambiguity about what response code should be returned in >> particular >> circumstances. I would be ok with that *if* the clarification applied >> to >> all uses of OPTIONS. But once you start to do that you start to pick up >> the negatives of (2). > > I can't fix every problem with OPTIONS and I don't see a reason to expand > this draft beyond that. If we were introducing new functionality, I'd > agree... but I'd prefer we didn't introduce new functionality. > >> It would also be possible to do a combination of (1) and (2), where (2) >> is preferred if both UAS supports it, with fallback to (1) for those >> that don't. > > What I think we should do is more along the lines of (1), with possible > consideration of introducing a header or tag to serve as a hint as to the > purpose of the OPTIONS message. (I know that compels you to suggest that I > might be bipolar, but I'm only trying recognize the fact that some find this > useful. Still, I'd expect the same processing on the box.) > >> What I don't see is a way to avoid standards action and yet define >> special optional behavior by the UAS that the UAC can request and know >> was provided. This seems to be what you are seeking. > > So, what's special? We're constraining behavior, not expanding it. Its *harder* to get a change deployed that constrains behavior than it is to deploy one that expands behavior! Constraining behavior presents backward compatibility issues to everybody that was doing something that used to be valid and no longer is. Expanding behavior presents no backward compatibility issues. Thanks, Paul K From christer.holmberg@ericsson.com Thu Apr 29 12:58:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162D33A6981 for ; Thu, 29 Apr 2010 12:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.276 X-Spam-Level: X-Spam-Status: No, score=-5.276 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-XeBY2HGooC for ; Thu, 29 Apr 2010 12:58:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0492D3A67DB for ; Thu, 29 Apr 2010 12:58:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-58-4bd9e4e44be4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E1.66.08537.4E4E9DB4; Thu, 29 Apr 2010 21:58:28 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Apr 2010 21:58:28 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 29 Apr 2010 21:58:27 +0200 From: Christer Holmberg To: "Paul E. Jones" , 'Hadriel Kaplan' , 'Paul Kyzivat' Date: Thu, 29 Apr 2010 21:54:15 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: AcrmWLMcDr8YWb2MTQa7l7QyPRJGXgAJiY7AACuDZEAAAecAQAAoT0sP Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15BF@mail>, <010601cae735$7f55c1d0$7e014570$@com> In-Reply-To: <010601cae735$7f55c1d0$7e014570$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 19:58:44 -0000 Hi, >>>That said, I can see where it might be useful to have a ping@example.com= type address for such things as IP phones or >>>even SBCs. In any case, the "ping" address should be an address that th= e manufacturer discloses and the peer entity should be configured to >>>use. >>> >>I'm getting confused - are you thinking the IP Address of the OPTIONS' >>request-URI would be a *different* IP Address from the one other SIP >>requests are sent to?? I didn't grok that from the draft at all, and >>it would make things very complicated. > >No, I certainly didn't mean to suggest there would a different IP address. > >What I am referring to is the Request URI. Previously, I was suggesting >that the request URI would be addressed to the IP address if it's a ping, >but would be addressed to a user if it wasn't. But, you and Dean have >convinced me that that's not always a good way to differentiate an OPTIONS >"ping" from one that's an actual OPTIONS request. > >So, I removed the restriction from my local draft that specified what the >Request URI looks like. What we need to decide is exactly what we want to >have as a differentiator? A specific request URI, a tag, a header, etc. > >Having said that, I'm still favorable to sending an OPTIONS "ping" address= ed >to the IP address of the device (e.g., sip:192.168.1.10). Whether that >contains a "ping" header or tag or other is likely not going to make much >difference to an SBC that does not receive other requests addressed to tha= t >address. If the receiver is a proxy I don't think the IP address would work as a dif= ferentiator, because according to RFC 3261 OPTIONS requests sent to proxies are addressed by only using the host part. So, you would us= e sip:192.168.1.10 also for a "normal" OPTIONS request. Regards, Christer= From pkyzivat@cisco.com Thu Apr 29 13:01:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23B43A67DA for ; Thu, 29 Apr 2010 13:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+0SxfD85v-C for ; Thu, 29 Apr 2010 13:01:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C43D63A67D7 for ; Thu, 29 Apr 2010 13:01:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOOB2UtAZnwM/2dsb2JhbACdFHGkAJl1hRAE X-IronPort-AV: E=Sophos;i="4.52,297,1270425600"; d="scan'208";a="106565900" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2010 20:01:30 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3TK1TFj000621; Thu, 29 Apr 2010 20:01:29 GMT Message-ID: <4BD9E59A.40309@cisco.com> Date: Thu, 29 Apr 2010 16:01:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <4BD993BB.10202@cisco.com> <01d201cae7bd$e7eb1960$b7c14c20$@com> In-Reply-To: <01d201cae7bd$e7eb1960$b7c14c20$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 20:01:45 -0000 I'll be happy to be shown to be unduly pessimistic. I agree that the empty accept ought to result in a response without a body. I just expect that isn't what will happen in practice. Certainly implementations can then be called out for violation. Thanks, Paul Paul E. Jones wrote: > Paul, > >>> The message body payload part is easy to get rid of - you just >> include an empty Accept header field in the OPTIONS request. >> >> That *could* work, if the UAS understands and does it right. > > If it didn't, wouldn't it be non-compliant with 3261? > >> I'll venture to guess that most existing implementations would either: >> a) return the SDP anyway (assuming there were prepared to return it.) >> b) barf and return some error code, hopefully 406 >> >> If (a) happened, you could file a complaint against the vendor of the >> UAS. But I think you could make a good case that (b) is appropriate in >> this case, as it would if you put an empty Accept in an INVITE. > > Why would you argue that a device should do (b)? > > Paul > > > From christer.holmberg@ericsson.com Thu Apr 29 13:13:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D2C3A68FC for ; Thu, 29 Apr 2010 13:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDqL0+Kc909P for ; Thu, 29 Apr 2010 13:13:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2448C3A68B9 for ; Thu, 29 Apr 2010 13:13:16 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-95-4bd9e84ec0cd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.A6.21861.E48E9DB4; Thu, 29 Apr 2010 22:13:02 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Apr 2010 22:13:02 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 29 Apr 2010 22:13:01 +0200 From: Christer Holmberg To: Paul Kyzivat , "Paul E. Jones" Date: Thu, 29 Apr 2010 22:13:00 +0200 Thread-Topic: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt Thread-Index: Acrn1sOlWuzSlwsPRr68cWltI6pvuAAANme9 Message-ID: References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com> <011601cae747$5013a740$f03af5c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail> <011f01cae750$3b424840$b1c6d8c0$@com> <4BD993BB.10202@cisco.com> <01d201cae7bd$e7eb1960$b7c14c20$@com>,<4BD9E59A.40309@cisco.com> In-Reply-To: <4BD9E59A.40309@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: 'Michael Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 20:13:18 -0000 Hi, >I'll be happy to be shown to be unduly pessimistic. >I agree that the empty accept ought to result in a response without a >body. I just expect that isn't what will happen in practice. That may be true, but I don't think it should be a reason for not specifyin= g a solution. After all, the protocol doesn't break even if the response do= es contain a body. But, so far we have been mostly talking about the content of the response. = However, I think the content of the request is also important. Assume I send an OPTIONS "ping" request, and don't include any capabilities= etc. Assuming there is no "ping" identifier, the receiver may actually thi= nk that I don't support any capabilities, and may use that information e.g.= when making routing/forking decissions about requests. Regards, Christer Paul E. Jones wrote: > Paul, > >>> The message body payload part is easy to get rid of - you just >> include an empty Accept header field in the OPTIONS request. >> >> That *could* work, if the UAS understands and does it right. > > If it didn't, wouldn't it be non-compliant with 3261? > >> I'll venture to guess that most existing implementations would either: >> a) return the SDP anyway (assuming there were prepared to return it.) >> b) barf and return some error code, hopefully 406 >> >> If (a) happened, you could file a complaint against the vendor of the >> UAS. But I think you could make a good case that (b) is appropriate in >> this case, as it would if you put an empty Accept in an INVITE. > > Why would you argue that a device should do (b)? > > Paul > > >= From paulej@packetizer.com Thu Apr 29 16:12:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814C93A6A17 for ; Thu, 29 Apr 2010 16:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CkMGepUazRG for ; Thu, 29 Apr 2010 16:12:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 7A3333A682D for ; Thu, 29 Apr 2010 16:12:51 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3TNCPM6032590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 19:12:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272582751; bh=tJ2SJ6YdAsXmwI6l/6cM+RxLZqzuf/xULfDQ0ecbkPo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WgIvMn+FYyBcaLNpxY9OQgpjPmUeWOnhf7k6ylkVTOgEWm2NyrBTxPsbJQOgnolQd rxiAe4vQ3+79sBgzWy7gtOVpe782jIRE3hJrItUl1L+TZe+csvTUX66gIbPMRcWRQ5 q86J/spfNDmy8xWk0H7O4/CKGSTo0iCAhgrzZZu8= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3TNCNs2025509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 19:12:24 -0400 From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Milinski, Alexander \(NSN - DE/Munich\)'" , "'ext Hadriel Kaplan'" , "'Paul Kyzivat'" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com><4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com><4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com><1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com><00da01cae72e$4f5590c0$ee00b240$@com><8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com><010901cae73a$766dfec0$6349fc40$@com> <4BD8F0E7.1070000@cisco.com><011601cae747$5013a740$f03af5c0$@com><430FC6BDED356B4C8498F634416644A91A8A5F15EA@mail><011f01cae750$3b424840$b1c6d8c0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F15F0@mail> <3F4C11BC54A36642BFB5875D599F47BD029E4A89@DEMUEXC013.nsn-intra.net>, <018201cae7ae$308be240$91a3a6c0$@com> In-Reply-To: Date: Thu, 29 Apr 2010 19:12:16 -0400 Message-ID: <020201cae7f1$69355d40$3ba017c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrnROnQymZSZUGRTSuWO2B29HSnawAAaJ5wAAFMCjAAAOfeoAADM50wAARtvhAAD9tS0AAJB0WHAAfuj3A= Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 23:12:52 -0000 Christer, > OPTIONS is not the only method that is too "heavy" if sent too often. > People have been using frequent re-registrations in order to do NAT > keep-alives, and that's also bad. That is one reason we have defined > the usage of STUN for keep-alives, because it's much more > "lightweight". > > So, I think it would be useful to know how often (the minimum value) > these pings are expected to be sent. Since this was intended for use between two devices that have some kind of relationship, not merely transmitted anywhere on the Internet, we recommended that the interval be left to the administrator. If I were implementing it, I would not even send a ping if I knew there was activity (i.e., I would only send one when I had not seen any other SIP message for some specified period of time .. again, configurable). Paul From paulej@packetizer.com Thu Apr 29 18:11:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C093A6818 for ; Thu, 29 Apr 2010 18:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrXXhmXEaC+d for ; Thu, 29 Apr 2010 18:11:50 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 57FC43A67FC for ; Thu, 29 Apr 2010 18:11:50 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o3U1BNak006514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Apr 2010 21:11:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1272589889; bh=89tSyGTA864PUWW6bCfmNH0Vqyc6+4zoLrdBvNp1yl4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=UBMHwEJf23Xq2uZI/D+pifo7lHa5mdzQ4KbVV2i8gz4AmRBfkfFnOIMtGi2of72rf EhtU5mktW059aQT7VDRgnr8oJXGrHbHhrtonFSPiC+GBT2JSMecUmVKgQNWLUMxPa3 5XhnbAjy2+Lo0PX6c7WRAxnwbTYDsaahQ+d2Q5zA= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o3U1BM10025775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Apr 2010 21:11:22 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'Christer Holmberg'" Date: Thu, 29 Apr 2010 21:11:14 -0400 Message-ID: <020801cae802$07b56ef0$17204cd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcroAgdrECXtfMTaQWOFS+ksMkGMVA== Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: [sipcore] SIP OPTIONS "ping" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 01:11:52 -0000 Guys, I decided to start this new thread, because the previous one is proving to be a bit challenging to respond to. Let's back up and review where we are and what we're trying to accomplish. Many devices today use OPTIONS as a "ping" method. The reason is that there was nothing better or more appropriate for an out-of-dialog means of determining status of a peer SIP device. These devices include PBXes, SBCs, etc. The problems are: 1) Response codes vary from one device to another (e.g., 600 vs. 503 vs. 486) 2) Nowhere is it documented that an OPTIONS can be used as an application-level "ping" Taking note of the current state of affairs and desiring to improve it without changing SIP in any significant way, we prepared the OPTIONS "ping" draft. Is it a ping message or not? The thread has focused heavily on the contents of the message, but we're not proposing changes to the contents of a message. We only wish to focus on response codes: the contents of headers and body were not subject to change. We proposed sending OPTIONS "ping" messages to the IP address of the peer device with a request URI of "sip:hostport" since that seemed most logical to us. Christer pointed out that that's the address used when addressing a SIP proxy server. I think that's OK, since we're not suggesting that the proxy server actually alter its behavior. That said, we would like to propose use of 503 to indicate that the device is overloaded, rather than 600: that's what RFC 3261 says. But, note that we're not saying a 600 is illegal if that were the appropriate code -- it just isn't in this case. We also expect this to be used only between two devices that agree to do so. The interval for messages I also wanted to keep locally configured. It might be useful to indicate that the message was a "ping" -- I have no objection. But, I would not implement a different code path, personally. That's why I felt it wasn't terribly important to include. If we do nothing, the world will continue to use OPTIONS as they do today. Introducing PING will take time to standardize and we still have to support OPTIONS for a decade. So, why bother? My recommendation is that we not boil the ocean and try to create the most architecturally pure solution. Let's recognize the use of OPTIONS in this way as legitimate, keep it peer-to-peer (maxforward=1), recommend response codes, and expect a locally provisioned usage policy (e.g., message frequency). I've captured the groups' comments in this draft, though I'd like to reinstate the paragraph relating to the SIP Request URI (sip:hostport): http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft-jones-sip- options-ping-01.pdf In any case, I'll go along with whatever the group wishes to do. Paul From HKaplan@acmepacket.com Fri Apr 30 01:39:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193BD3A6A7F for ; Fri, 30 Apr 2010 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfLmDVZ+wTej for ; Fri, 30 Apr 2010 01:39:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 35A763A6977 for ; Fri, 30 Apr 2010 01:39:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Apr 2010 04:39:25 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 30 Apr 2010 04:39:25 -0400 From: Hadriel Kaplan To: "Paul E. Jones" , 'Paul Kyzivat' , 'Christer Holmberg' Date: Fri, 30 Apr 2010 04:39:11 -0400 Thread-Topic: Indicator for SIP OPTIONS "ping" Thread-Index: AcroAgdrECXtfMTaQWOFS+ksMkGMVAAOhTQA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1802@mail> References: <020801cae802$07b56ef0$17204cd0$@com> In-Reply-To: <020801cae802$07b56ef0$17204cd0$@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: 'Michael Miller' , "sipcore@ietf.org" Subject: [sipcore] Indicator for SIP OPTIONS "ping" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 08:39:42 -0000 Hi Paul, Good idea to reset. Right, so one of the sub-threads previous was on the need or not for an ind= icator. In the snippet of your email below, you're saying the OPTIONS is no differe= nt and the code path would be the same. That's the part that confuses me. = If the code path is the same on the responder, such that it doesn't do any= thing different than what it does today, then by definition it won't fix th= e interop issues we've all seen in the wild. The whole point of documentin= g consistent behavior for response codes is to fix the interop issues, and = that means the box getting the OPTIONS request has to know the sender expec= ts the behavior of this document. For the responder to know that, there ne= eds to be something in the OPTIONS message to tell it that. And for the bo= x that sent the OPTIONS, it may also need to know the responder does the dr= aft so that it can treat the response codes appropriately, by something in = the response telling it so. I don't think that means it needs to be a new Method name, because we're no= t actually changing the OPTIONS from being an OPTIONS - using OPTIONS for t= his purpose is in rfc3261, it just wasn't succinct enough to avoid interop = issues. And the advantage of continuing to use an OPTIONS is that if the receiver d= oes NOT support this new draft, it will still "work" as before. In that se= nse using a new target URI username is probably not the best idea. We coul= d use a new options-tag in Supported, but since that would also still need = something else in the message to say "I'm using this options-tag mechanism = for this request", there's not much benefit to that. So the easiest/simple= st/most-likely-to-succeed path probably is Paul Kyzivat's suggestion of jus= t defining a new header for both the request and response.=20 -hadriel > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 29, 2010 9:11 PM > Subject: SIP OPTIONS "ping" >=20 > Is it a ping message or not? The thread has focused heavily on the > contents > of the message, but we're not proposing changes to the contents of a > message. We only wish to focus on response codes: the contents of header= s > and body were not subject to change. >=20 > We proposed sending OPTIONS "ping" messages to the IP address of the peer > device with a request URI of "sip:hostport" since that seemed most logica= l > to us. Christer pointed out that that's the address used when addressing > a > SIP proxy server. I think that's OK, since we're not suggesting that the > proxy server actually alter its behavior. That said, we would like to > propose use of 503 to indicate that the device is overloaded, rather than > 600: that's what RFC 3261 says. But, note that we're not saying a 600 is > illegal if that were the appropriate code -- it just isn't in this case. >=20 > We also expect this to be used only between two devices that agree to do > so. > The interval for messages I also wanted to keep locally configured. >=20 > It might be useful to indicate that the message was a "ping" -- I have no > objection. But, I would not implement a different code path, personally. > That's why I felt it wasn't terribly important to include. From pkyzivat@cisco.com Fri Apr 30 07:44:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BAF73A68F3 for ; Fri, 30 Apr 2010 07:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhVXOKAHE42h for ; Fri, 30 Apr 2010 07:44:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 29AA028C16F for ; Fri, 30 Apr 2010 07:43:57 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMqJ2kurRN+K/2dsb2JhbACdIHGkX5oPhRIE X-IronPort-AV: E=Sophos;i="4.52,302,1270425600"; d="scan'208";a="122999178" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 Apr 2010 14:43:43 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3UEhgHV012649; Fri, 30 Apr 2010 14:43:42 GMT Message-ID: <4BDAEC9E.9030304@cisco.com> Date: Fri, 30 Apr 2010 10:43:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <020801cae802$07b56ef0$17204cd0$@com> <430FC6BDED356B4C8498F634416644A91A8A5F1802@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F1802@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] Indicator for SIP OPTIONS "ping" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 14:44:06 -0000 Hadriel Kaplan wrote: > Hi Paul, > Good idea to reset. > > Right, so one of the sub-threads previous was on the need or not for an indicator. > > In the snippet of your email below, you're saying the OPTIONS is no different and the code path would be the same. That's the part that confuses me. If the code path is the same on the responder, such that it doesn't do anything different than what it does today, then by definition it won't fix the interop issues we've all seen in the wild. The whole point of documenting consistent behavior for response codes is to fix the interop issues, and that means the box getting the OPTIONS request has to know the sender expects the behavior of this document. For the responder to know that, there needs to be something in the OPTIONS message to tell it that. And for the box that sent the OPTIONS, it may also need to know the responder does the draft so that it can treat the response codes appropriately, by something in the response telling it so. Right! > I don't think that means it needs to be a new Method name, because we're not actually changing the OPTIONS from being an OPTIONS - using OPTIONS for this purpose is in rfc3261, it just wasn't succinct enough to avoid interop issues. If there is no intent to have *different* behavior for the ping usage, then there is also no reason to indicate in the OPTIONS request that it is being used as a ping. Nor is there any need to have a side agreement between the UAC and UAS that the UAC will be pinging the UAS. > And the advantage of continuing to use an OPTIONS is that if the receiver does NOT support this new draft, it will still "work" as before. In that sense using a new target URI username is probably not the best idea. We could use a new options-tag in Supported, but since that would also still need something else in the message to say "I'm using this options-tag mechanism for this request", there's not much benefit to that. So the easiest/simplest/most-likely-to-succeed path probably is Paul Kyzivat's suggestion of just defining a new header for both the request and response. There really isn't any need to put *anything* new into the request. All that is really needed is a header that says: "This response complies with the *new improved* OPTIONS definition." Unfortunately, just to accomplish that small step will still require a standards track draft to be approved. And if we are going to go to that much trouble, would it be worthwhile to do a separate ping mechanism? I'm not advocating that we *should* do that - just asking. If the clarified OPTIONS is what is desired, then maybe it isn't just about OPTIONS - is is really about more specific use of error codes for *all* requests? Thanks, Paul > -hadriel > >> -----Original Message----- >> From: Paul E. Jones [mailto:paulej@packetizer.com] >> Sent: Thursday, April 29, 2010 9:11 PM >> Subject: SIP OPTIONS "ping" >> >> Is it a ping message or not? The thread has focused heavily on the >> contents >> of the message, but we're not proposing changes to the contents of a >> message. We only wish to focus on response codes: the contents of headers >> and body were not subject to change. >> >> We proposed sending OPTIONS "ping" messages to the IP address of the peer >> device with a request URI of "sip:hostport" since that seemed most logical >> to us. Christer pointed out that that's the address used when addressing >> a >> SIP proxy server. I think that's OK, since we're not suggesting that the >> proxy server actually alter its behavior. That said, we would like to >> propose use of 503 to indicate that the device is overloaded, rather than >> 600: that's what RFC 3261 says. But, note that we're not saying a 600 is >> illegal if that were the appropriate code -- it just isn't in this case. >> >> We also expect this to be used only between two devices that agree to do >> so. >> The interval for messages I also wanted to keep locally configured. >> >> It might be useful to indicate that the message was a "ping" -- I have no >> objection. But, I would not implement a different code path, personally. >> That's why I felt it wasn't terribly important to include. > From rbarnes@bbn.com Fri Apr 30 09:39:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4BE3A6896 for ; Fri, 30 Apr 2010 09:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ6F1fEAf7V8 for ; Fri, 30 Apr 2010 09:39:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D981A3A6963 for ; Fri, 30 Apr 2010 09:39:31 -0700 (PDT) Received: from [128.89.253.165] (port=56300 helo=[192.168.1.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7ser-000EgN-Da for sipcore@ietf.org; Fri, 30 Apr 2010 12:01:41 -0400 Message-Id: From: Richard Barnes To: sipcore@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Apr 2010 12:01:41 -0400 X-Mailer: Apple Mail (2.936) Subject: [sipcore] ESW7: Detailed agenda and reminder to register X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 16:39:33 -0000 Dear colleagues, This is an update to let you know that the detailed agenda has been posted for the upcoming Emergency Services Workshop: Also, just a reminder that if you are planning to attend, please fill out the registration form on the website: Thanks for your interest, The ESW Coordination Team From fluffy@cisco.com Fri Apr 30 12:22:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E4B3A6B3D for ; Fri, 30 Apr 2010 12:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.853 X-Spam-Level: X-Spam-Status: No, score=-109.853 tagged_above=-999 required=5 tests=[AWL=0.746, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1wlwP6jpI58 for ; Fri, 30 Apr 2010 12:22:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B8DCC28C2B7 for ; Fri, 30 Apr 2010 12:21:30 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,304,1270425600"; d="scan'208";a="523211017" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 30 Apr 2010 19:21:17 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3UJLFnw001247; Fri, 30 Apr 2010 19:21:16 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <020801cae802$07b56ef0$17204cd0$@com> Date: Fri, 30 Apr 2010 13:21:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <020801cae802$07b56ef0$17204cd0$@com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1078) Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] SIP OPTIONS "ping" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 19:22:31 -0000 Thanks for the reset. I think the reasons this thread has been so unproductive is we are = unclear on what the problem is we are trying to solve. "We need a way to = do PING" is not a problem. It is a solution to some problem. If the = problem is figure out which of multiple next hops to use based on load = balancing and if the hop is dead or alive, well the PING approach here = will fail miserably (see the overload discussion and simulations) and we = have WG going to the IESG to try and solve that problem.=20 Let me make it very clear I am against the working group working on this = draft until someone can describe what the problem is. The current draft = hand waves at a few problems - does not say what it is trying to do. = Then proposes some syntax with no backing semantics that would help = solve any of the problems it mentions.=20 Cullen On Apr 29, 2010, at 7:11 PM, Paul E. Jones wrote: > Guys, >=20 > I decided to start this new thread, because the previous one is = proving to > be a bit challenging to respond to. >=20 > Let's back up and review where we are and what we're trying to = accomplish. >=20 > Many devices today use OPTIONS as a "ping" method. The reason is that = there > was nothing better or more appropriate for an out-of-dialog means of > determining status of a peer SIP device. These devices include PBXes, = SBCs, > etc. >=20 > The problems are: > 1) Response codes vary from one device to another (e.g., 600 vs. 503 = vs. > 486) > 2) Nowhere is it documented that an OPTIONS can be used as an > application-level "ping" >=20 > Taking note of the current state of affairs and desiring to improve it > without changing SIP in any significant way, we prepared the OPTIONS = "ping" > draft. >=20 > Is it a ping message or not? The thread has focused heavily on the = contents > of the message, but we're not proposing changes to the contents of a > message. We only wish to focus on response codes: the contents of = headers > and body were not subject to change. >=20 > We proposed sending OPTIONS "ping" messages to the IP address of the = peer > device with a request URI of "sip:hostport" since that seemed most = logical > to us. Christer pointed out that that's the address used when = addressing a > SIP proxy server. I think that's OK, since we're not suggesting that = the > proxy server actually alter its behavior. That said, we would like to > propose use of 503 to indicate that the device is overloaded, rather = than > 600: that's what RFC 3261 says. But, note that we're not saying a 600 = is > illegal if that were the appropriate code -- it just isn't in this = case. >=20 > We also expect this to be used only between two devices that agree to = do so. > The interval for messages I also wanted to keep locally configured. >=20 > It might be useful to indicate that the message was a "ping" -- I have = no > objection. But, I would not implement a different code path, = personally. > That's why I felt it wasn't terribly important to include. >=20 > If we do nothing, the world will continue to use OPTIONS as they do = today. > Introducing PING will take time to standardize and we still have to = support > OPTIONS for a decade. So, why bother? >=20 > My recommendation is that we not boil the ocean and try to create the = most > architecturally pure solution. Let's recognize the use of OPTIONS in = this > way as legitimate, keep it peer-to-peer (maxforward=3D1), recommend = response > codes, and expect a locally provisioned usage policy (e.g., message > frequency). >=20 > I've captured the groups' comments in this draft, though I'd like to > reinstate the paragraph relating to the SIP Request URI = (sip:hostport): > = http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft-jones-si= p- > options-ping-01.pdf >=20 > In any case, I'll go along with whatever the group wishes to do. >=20 > Paul >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adam@estacado.net Fri Apr 30 14:59:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76D73A6C6C for ; Fri, 30 Apr 2010 14:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-UlYMt3MDcO for ; Fri, 30 Apr 2010 14:59:23 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id C75603A6C69 for ; Fri, 30 Apr 2010 14:59:22 -0700 (PDT) Received: from dn3-228.estacado.net (dn3-228.estacado.net [172.16.3.228]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o3ULx7jU044976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Apr 2010 16:59:07 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4BDB52AB.9000507@estacado.net> Date: Fri, 30 Apr 2010 16:59:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Call for Consensus: INFO Specification and Congestion X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 21:59:24 -0000 [as chair] During IESG review of the INFO specification, several members expressed concerns about the congestion properties of INFO. The draft authors and IESG worked together to craft text that satisfies these concerns. Since the resulting text contains normative language, we are bringing the proposal to the SIPCORE working group for a 2-week consensus call. Please comment on the following proposed text before Friday, May 14th. If you agree with the proposal, please send a short response indicating that fact. "10.9. Rate and size of INFO Requests "INFO messages differ from many other sorts of SIP messages in that they carry application information, and the size and rate of the INFO message is directly determined by the application. This can cause application information traffic to interfere with other traffic on that infrastructure, or to self-interfere when data rates become too high. "A designer of an INFO package, and the application that uses it, need to consider the impact that the size and the rate of the INFO messages have on the network and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO message is sent over a such a transport protocol, a downstream SIP entity might forward the message over a transport protocol that does not provide congestion control. "Therefore, an application SHOULD generally have at most one outstanding INFO message. The guidelines in RFC3261 Section 18 MUST be followed for sending and receiving INFO requests and responses, such as the guideline to not exceed messages sizes of 1300 bytes when the path MTU is unknown. RFC5405 provides additional guidelines for applications using the User Datagram Protocol (UDP) that may be useful background reading." Thanks. /a From stpeter@stpeter.im Fri Apr 30 21:45:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354303A689D for ; Fri, 30 Apr 2010 21:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmHiNPBAsILs for ; Fri, 30 Apr 2010 21:45:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D70B23A6892 for ; Fri, 30 Apr 2010 21:45:48 -0700 (PDT) Received: from squire.local (dsl-228-154.dynamic-dsl.frii.net [216.17.228.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 57A7E40E2C for ; Fri, 30 Apr 2010 22:45:34 -0600 (MDT) Message-ID: <4BDBB1ED.9030104@stpeter.im> Date: Fri, 30 Apr 2010 22:45:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <4BDB52AB.9000507@estacado.net> In-Reply-To: <4BDB52AB.9000507@estacado.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080404060601060706000800" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 04:45:50 -0000 This is a cryptographically signed message in MIME format. --------------ms080404060601060706000800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/30/10 3:59 PM, Adam Roach wrote: > [as chair] >=20 > During IESG review of the INFO specification, several members expressed= > concerns about the congestion properties of INFO. The draft authors and= > IESG worked together to craft text that satisfies these concerns. >=20 > Since the resulting text contains normative language, we are bringing > the proposal to the SIPCORE working group for a 2-week consensus call. > Please comment on the following proposed text before Friday, May 14th. > If you agree with the proposal, please send a short response indicating= > that fact. >=20 > "10.9. Rate and size of INFO Requests >=20 > "INFO messages differ from many other sorts of SIP messages in that= > they carry application information, and the size and rate of the > INFO message is directly determined by the application. This can > cause application information traffic to interfere with other traf= fic > on that infrastructure, or to self-interfere when data rates becom= e > too high. >=20 > "A designer of an INFO package, and the application that uses it, > need to consider the impact that the size and the rate of the INFO= > messages have on the network and on other traffic, since it normal= ly > cannot be ensured that INFO messages will be carried over a > congestion-controlled transport protocol end-to-end. Even if an > INFO message is sent over a such a transport protocol, a downstrea= m > SIP entity might forward the message over a transport protocol tha= t > does not provide congestion control. >=20 > "Therefore, an application SHOULD generally have at most one > outstanding INFO message. > The guidelines in RFC3261 Section 18 MUST be followed for sending > and receiving INFO > requests and responses, such as the guideline to not exceed messag= es > sizes of 1300 bytes when the path MTU is unknown. RFC5405 provides= > additional guidelines for applications using the User Datagram > Protocol (UDP) that may be useful background reading." Seems good to me. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080404060601060706000800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUwMTA0NDUzM1owIwYJKoZIhvcNAQkEMRYEFAlOInCEgwx4F1jmFLVB Aiyo4L9vMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEALgsIGQB2WN3Qh/4purFBWEsOfhbb4g9U0p0Iyj1e ninJ2wJ0xMMeoU+b0Jgdh+Lf+mpMecld5Y9Rf1KVas/Xs6auZYweyAKe3NjCUiyMbasmOeuw bIUzT0xX3GGtbpour9Ax15ChJKUlEHT1kR0WBJGcSlqHyABcxLN58WBkpbjNFIc8iTTbtJBn IuoLLAzz4qWePdzJGAYz7zqcbhIzhCY54FBtKDUdV/1KccjLjP0Y7pMyJztPuOsFShvwvtlC aPLT4g2h28cTIFWnfP0pQBLVjEK4M3xgemlHRpWZBzjWt7IM8yzQjCIrSD84RuEuPbkrY6aB QA79BowlUj8vrQAAAAAAAA== --------------ms080404060601060706000800--