From paulej@packetizer.com Wed Aug 11 22:15:06 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2783A697B for ; Wed, 11 Aug 2010 22:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=0.246, 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 QjsSwuZKJtD5 for ; Wed, 11 Aug 2010 22:14:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 297B53A697F for ; Wed, 11 Aug 2010 22:14:55 -0700 (PDT) Received: from sydney (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 o7C5FNul010090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Aug 2010 01:15:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281590129; bh=e0LMmnjjLabFWIDJ0ilLwv2NBvutJfkcGk4RKcqyttc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=nzKTbIH5KQfoUf92ZAiLaBqLSLyc7/Mp8lNsYHB/A/z/oDXrJg/p2vjDIVG7VTBUI LrkCukh6tfd3T3pwmVMze8NGNBAayNqY439MVRayQqx+dbGBZvCm9zrezJsBnhBpsk K7RWXUIzeZHCEeF/pU9FEqdl+GDgnXiqhPWKxnXg= From: "Paul E. Jones" To: , Date: Thu, 12 Aug 2010 01:14:34 -0400 Message-ID: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0535_01CB39BB.BCF65940" X-Mailer: Microsoft Outlook 14.0 thread-index: Acs53UBmkKgtMEtOSxC/dOMzX8shWQ== Content-Language: en-us Cc: Hadriel Kaplan Subject: [sip-ops] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 05:15:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0535_01CB39BB.BCF65940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Gonzalo and I produced an Internet Draft aiming at trying to bring some consistency to the way in which SIP user agents implement an OPTIONS "ping" procedure. It seems that a very large number of vendors do this, but unfortunately, there seems to be little consistency. Initially, we positioned the document as a standards track RFC, since this essentially builds on RFC 3261. However, there was some pushback from folks in the IETF for a variety of reasons, not the least of which is the fact that there is no working group chartered to do the work. We don't feel this one draft warrants the creation of a working group. So, we've got three options we can consider: 1) Forge ahead outside of a working group 2) Change the status of the draft to Informational 3) Forget about the draft and let every SIP device do it the way they want, throwing hope of consistency out the window (Yeah, you can tell I prefer not to go for the third option.) In any case, I'd like to get feedback from the on the SIP operators and SIP implementers lists. Do you think it's worth trying to address this issue? If so, which option do you think we should pursue? Note that we're certainly open to feedback on the draft. I'd prefer it to have a few more "MUST" statements in the text, rather than "SHOULD". But, we need to find that right balance: http://tools.ietf.org/html/draft-jones-sip-options-ping Paul ------=_NextPart_000_0535_01CB39BB.BCF65940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Gonzalo and = I produced an Internet Draft aiming at trying to bring some consistency = to the way in which SIP user agents implement an OPTIONS = “ping” procedure.  It seems that a very large number of = vendors do this, but unfortunately, there seems to be little = consistency.

 

Initially, we positioned the document as a standards = track RFC, since this essentially builds on RFC 3261.  However, = there was some pushback from folks in the IETF for a variety of reasons, = not the least of which is the fact that there is no working group = chartered to do the work.  We don’t feel this one draft = warrants the creation of a working group.

 

So, = we’ve got three options we can consider:

1)      = Forge ahead outside of a working = group

2)      = Change the status of the draft to = Informational

3)      = Forget about the draft and let every SIP device = do it the way they want, throwing hope of consistency out the = window

 

(Yeah, you can tell I prefer not to go for the third = option.)

 

In any case, I’d like to get feedback from the = on the SIP operators and SIP implementers lists.  Do you think = it’s worth trying to address this issue?  If so, which option = do you think we should pursue?

 

Note that = we’re certainly open to feedback on the draft.  I’d = prefer it to have a few more “MUST” statements in the text, = rather than “SHOULD”.  But, we need to find that right = balance:

http://t= ools.ietf.org/html/draft-jones-sip-options-ping

 

Paul

 

------=_NextPart_000_0535_01CB39BB.BCF65940-- From br@brianrosen.net Thu Aug 12 05:44:57 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FF23A68AB for ; Thu, 12 Aug 2010 05:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18sAzBixPUHD for ; Thu, 12 Aug 2010 05:44:56 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id D261A3A6868 for ; Thu, 12 Aug 2010 05:44:55 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.60.50]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OjXA0-0005dE-V7; Thu, 12 Aug 2010 07:45:29 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-69-514730923 From: Brian Rosen In-Reply-To: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> Date: Thu, 12 Aug 2010 08:45:25 -0400 Message-Id: <736CC4E3-7489-42F6-9E68-1C6EA51C0503@brianrosen.net> References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: sip-ops@ietf.org, Hadriel Kaplan , sip-implementors@lists.cs.columbia.edu Subject: Re: [sip-ops] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:44:57 -0000 --Apple-Mail-69-514730923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think this is needed, and I would go for informational. While I sort = of understand that you are "pushing" the definition of OPTIONS, if it = was PS, you wouldn't update any RFCs, right? Brian On Aug 12, 2010, at 1:14 AM, Paul E. Jones wrote: > Folks, > =20 > Gonzalo and I produced an Internet Draft aiming at trying to bring = some consistency to the way in which SIP user agents implement an = OPTIONS =93ping=94 procedure. It seems that a very large number of = vendors do this, but unfortunately, there seems to be little = consistency. > =20 > Initially, we positioned the document as a standards track RFC, since = this essentially builds on RFC 3261. However, there was some pushback = from folks in the IETF for a variety of reasons, not the least of which = is the fact that there is no working group chartered to do the work. We = don=92t feel this one draft warrants the creation of a working group. > =20 > So, we=92ve got three options we can consider: > 1) Forge ahead outside of a working group > 2) Change the status of the draft to Informational > 3) Forget about the draft and let every SIP device do it the way = they want, throwing hope of consistency out the window > =20 > (Yeah, you can tell I prefer not to go for the third option.) > =20 > In any case, I=92d like to get feedback from the on the SIP operators = and SIP implementers lists. Do you think it=92s worth trying to address = this issue? If so, which option do you think we should pursue? > =20 > Note that we=92re certainly open to feedback on the draft. I=92d = prefer it to have a few more =93MUST=94 statements in the text, rather = than =93SHOULD=94. But, we need to find that right balance: > http://tools.ietf.org/html/draft-jones-sip-options-ping > =20 > Paul > =20 > _______________________________________________ > sip-ops mailing list > sip-ops@ietf.org > https://www.ietf.org/mailman/listinfo/sip-ops --Apple-Mail-69-514730923 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think this is needed, and I would go for = informational.  While I sort of understand that you are "pushing" = the definition of OPTIONS, if it was PS, you wouldn't update any RFCs, = right?

Brian

On Aug 12, 2010, = at 1:14 AM, Paul E. Jones wrote:

Folks,
Gonzalo and I produced an Internet = Draft aiming at trying to bring some consistency to the way in which SIP = user agents implement an OPTIONS =93ping=94 procedure.  It seems = that a very large number of vendors do this, but unfortunately, there = seems to be little consistency.
Initially, we positioned the = document as a standards track RFC, since this essentially builds on RFC = 3261.  However, there was some pushback from folks in the IETF for = a variety of reasons, not the least of which is the fact that there is = no working group chartered to do the work.  We don=92t feel this = one draft warrants the creation of a working group.
So, we=92ve got three options we can = consider:
1) Forge ahead = outside of a working group
      Change the = status of the draft to Informational
3) Forget about = the draft and let every SIP device do it the way they want, throwing = hope of consistency out the window
(Yeah, you can tell I prefer not to = go for the third option.)
 
 
In-Reply-To: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> Date: Thu, 12 Aug 2010 20:44:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1081) Cc: sip-ops@ietf.org, Hadriel Kaplan Subject: Re: [sip-ops] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 03:43:49 -0000 I think you discuss how to move forward with this draft on dispatch = mailing list given that's the point of that list is help with problems = like this.=20 On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > Folks, > =20 > Gonzalo and I produced an Internet Draft aiming at trying to bring = some consistency to the way in which SIP user agents implement an = OPTIONS =93ping=94 procedure. It seems that a very large number of = vendors do this, but unfortunately, there seems to be little = consistency. > =20 > Initially, we positioned the document as a standards track RFC, since = this essentially builds on RFC 3261. However, there was some pushback = from folks in the IETF for a variety of reasons, not the least of which = is the fact that there is no working group chartered to do the work. We = don=92t feel this one draft warrants the creation of a working group. > =20 > So, we=92ve got three options we can consider: > 1) Forge ahead outside of a working group > 2) Change the status of the draft to Informational > 3) Forget about the draft and let every SIP device do it the way = they want, throwing hope of consistency out the window > =20 > (Yeah, you can tell I prefer not to go for the third option.) > =20 > In any case, I=92d like to get feedback from the on the SIP operators = and SIP implementers lists. Do you think it=92s worth trying to address = this issue? If so, which option do you think we should pursue? > =20 > Note that we=92re certainly open to feedback on the draft. I=92d = prefer it to have a few more =93MUST=94 statements in the text, rather = than =93SHOULD=94. But, we need to find that right balance: > http://tools.ietf.org/html/draft-jones-sip-options-ping > =20 > Paul > =20 > _______________________________________________ > sip-ops mailing list > sip-ops@ietf.org > https://www.ietf.org/mailman/listinfo/sip-ops Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From paulej@packetizer.com Thu Aug 12 21:09:15 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602A03A68B1 for ; Thu, 12 Aug 2010 21:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=1.485, 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 JmDPOBe8e6Sw for ; Thu, 12 Aug 2010 21:09:07 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id C97903A6892 for ; Thu, 12 Aug 2010 21:09:03 -0700 (PDT) Received: from sydney (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 o7D49Vwo016316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Aug 2010 00:09:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281672577; bh=hjrecyR8xMAjK60wTp2DvfSt4mgBkmb+MxDWTtb6kZ8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VVWkXJYulVCbX+N8w0cBWyzE4qmmhLmcgdi3uL1cUhbKUcpULBblpFeifXx1xC8GE oQVgJUGDosmvMnxHq5B7TgkKBUjpwUVHEoPaocdsUe/IoJRTvtNsIDo5Dyh9TSwxWT kcfU2UO7NFQfisuiG0tI6Ip4cSXevfKBlVycBQ5U= From: "Paul E. Jones" To: "'$@r\\/|>r!`/@'" References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> In-Reply-To: Date: Fri, 13 Aug 2010 00:08:41 -0400 Message-ID: <005601cb3a9d$3a9c0110$afd40330$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01CB3A7B.B38D9560" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAHNWDL+kXAKcxA= Content-language: en-us Cc: sip-ops@ietf.org, 'Hadriel Kaplan' , sip-implementors@lists.cs.columbia.edu Subject: Re: [sip-ops] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 04:09:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0057_01CB3A7B.B38D9560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The draft does specify the use of 503 to indicate overload. The 486 was proposed as a means of indicating that the device is nearing capacity, versus being totally overloaded. So, if one sends an OPTIONS message and the peer device is in great shape, it would return a 200. If it's nearing capacity, but still able to accept new requests, it would return a 486. If it cannot accept new requests, it would return 503. The value in using the 486 (and this could be any other code folks agreed to use) is that it gives an SBC warning that overload is eminent. It's important to give given that advanced warning before the peer reaches an overload state. Having said that, addressing overload is really a separate problem entirely and is not the primary focus of OPTIONS "ping". So, I would not be opposed to removing this part entirely. For overload control, there is a WG focused on doing percentage-based overload control. I view that as good for stateless SIP entities, but not very useful (in my opinion) for peered SBCs. So, we have a separate draft aimed at overload control called "Session Capacity Estimate" SIP entities that are stateful: http://tools.ietf.org/html/draft-jones-sip-overload-sce-00 Anyway, I don't want to get too off-topic :-) For OPTIONS, I just want to get the feel of the group as to whether there is value in trying to do something. I take it you think this is worthwhile. I'll remove the paragraph that describes use of 486, since I think use of Session Capacity Estimate is a far better solution. OPTIONS is just to determine if the peer is alive and an SCE value can be returned in an OPTIONS ping. Any other changes that would help tighten the language and reduce interop issues? Paul From: $@r\/|>r!`/@ [mailto:sarvpriyagupta@gmail.com] Sent: Thursday, August 12, 2010 3:51 AM To: Paul E. Jones Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo Salgueiro; Hadriel Kaplan Subject: Re: [Sip-implementors] SIP OPTIONS "ping" Hi, Gud to see your initiative. Instead of using 486 for denoting overload, 503 message can be used. I have seen this usage to use as overload control mechanism. Entirely in my opinion, 486 is not apt. cheers!!!! sarvpriya http://sarvpriyak.blogspot.com/ On Thu, Aug 12, 2010 at 10:44 AM, Paul E. Jones wrote: Folks, Gonzalo and I produced an Internet Draft aiming at trying to bring some consistency to the way in which SIP user agents implement an OPTIONS "ping" procedure. It seems that a very large number of vendors do this, but unfortunately, there seems to be little consistency. Initially, we positioned the document as a standards track RFC, since this essentially builds on RFC 3261. However, there was some pushback from folks in the IETF for a variety of reasons, not the least of which is the fact that there is no working group chartered to do the work. We don't feel this one draft warrants the creation of a working group. So, we've got three options we can consider: 1) Forge ahead outside of a working group 2) Change the status of the draft to Informational 3) Forget about the draft and let every SIP device do it the way they want, throwing hope of consistency out the window (Yeah, you can tell I prefer not to go for the third option.) In any case, I'd like to get feedback from the on the SIP operators and SIP implementers lists. Do you think it's worth trying to address this issue? If so, which option do you think we should pursue? Note that we're certainly open to feedback on the draft. I'd prefer it to have a few more "MUST" statements in the text, rather than "SHOULD". But, we need to find that right balance: http://tools.ietf.org/html/draft-jones-sip-options-ping Paul _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- ------=_NextPart_000_0057_01CB3A7B.B38D9560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft does specify the use of 503 to indicate overload.  The = 486 was proposed as a means of indicating that the device is nearing = capacity, versus being totally overloaded.  So, if one sends an = OPTIONS message and the peer device is in great shape, it would return a = 200.  If it’s nearing capacity, but still able to accept new = requests, it would return a 486.  If it cannot accept new requests, = it would return 503.

 

The value in using the 486 (and this could be any other code folks = agreed to use) is that it gives an SBC warning that overload is = eminent.  It’s important to give given that advanced warning = before the peer reaches an overload state.  Having said that, = addressing overload is really a separate problem entirely and is not the = primary focus of OPTIONS “ping”.  So, I would not be = opposed to removing this part entirely.  For overload control, = there is a WG focused on doing percentage-based overload control.  = I view that as good for stateless SIP entities, but not very useful (in = my opinion) for peered SBCs.  So, we have a separate draft aimed at = overload control called “Session Capacity Estimate” SIP = entities that are stateful:

http:= //tools.ietf.org/html/draft-jones-sip-overload-sce-00

 

Anyway, I don’t want to get too off-topic :-)  For = OPTIONS, I just want to get the feel of the group as to whether there is = value in trying to do something.  I take it you think this is = worthwhile.

 

I’ll remove the paragraph that describes use of 486, since I = think use of Session Capacity Estimate is a far better solution.  = OPTIONS is just to determine if the peer is alive and an SCE value can = be returned in an OPTIONS ping.  Any other changes that would help = tighten the language and reduce interop issues?

 

Paul

 

From:= = $@r\/|>r!`/@ [mailto:sarvpriyagupta@gmail.com]
Sent: = Thursday, August 12, 2010 3:51 AM
To: Paul E. = Jones
Cc: sip-ops@ietf.org; = sip-implementors@lists.cs.columbia.edu; Gonzalo Salgueiro; Hadriel = Kaplan
Subject: Re: [Sip-implementors] SIP OPTIONS = "ping"

 

Hi,

 

Gud to see your = initiative.

 

Instead of using 486 for denoting overload, 503 = message can be used. I have seen this usage to use as overload control = mechanism. Entirely in my opinion, 486 is not = apt.

 

 

cheers!!!!
sarvpriya

 

On Thu, Aug 12, 2010 at 10:44 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,



Gonzalo = and I produced an Internet Draft aiming at trying to bring = some
consistency to the way in which SIP user agents implement an = OPTIONS "ping"
procedure.  It seems that a very large = number of vendors do this, but
unfortunately, there seems to be = little consistency.



Initially, we positioned the document = as a standards track RFC, since this
essentially builds on RFC 3261. =  However, there was some pushback from folks
in the IETF for a = variety of reasons, not the least of which is the fact
that there is = no working group chartered to do the work.  We don't feel = this
one draft warrants the creation of a working = group.



So, we've got three options we can = consider:

1)      Forge ahead outside of a working = group

2)      Change the status of the draft to = Informational

3)      Forget about the draft and = let every SIP device do it the way they
want, throwing hope of = consistency out the window



(Yeah, you can tell I prefer = not to go for the third option.)



In any case, I'd like to = get feedback from the on the SIP operators and SIP
implementers = lists.  Do you think it's worth trying to address this issue?
If = so, which option do you think we should pursue?



Note that = we're certainly open to feedback on the draft.  I'd prefer it = to
have a few more "MUST" statements in the text, rather = than "SHOULD".  But,
we need to find that right = balance:

http://tools.ietf.org/html/draft-jones-sip-options-ping=



Paul



_________________________________= ______________
Sip-implementors mailing list
Sip-implementors@l= ists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-im= plementors




-- =

------=_NextPart_000_0057_01CB3A7B.B38D9560-- From paulej@packetizer.com Thu Aug 12 21:19:00 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5D33A6814 for ; Thu, 12 Aug 2010 21:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=1.188, 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 sOCPPGzRsDhC for ; Thu, 12 Aug 2010 21:18:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 072F33A6892 for ; Thu, 12 Aug 2010 21:18:55 -0700 (PDT) Received: from sydney (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 o7D4JNcW016677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Aug 2010 00:19:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281673169; bh=2zXETL6GEJeMPfG32qbQx+7IbuRzIMrU6lx2Zk2yVaU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kPQHD40HjSqJqdsKPHkcvqz/uXEMOdasdF8dobQPR17tKwn8KHcA6vG4HGDiW1R7X /ytmAqiwFoO+l06n6zwbR8r89QLYr7EyiyHn1GkC2oAZ9lDEZa5dOZScfoJ0bQNo73 psPxgXkB41sOPBrQOkEQBBnA85xp/7hAdmOE/rgI= From: "Paul E. Jones" To: "'Brian Rosen'" References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <736CC4E3-7489-42F6-9E68-1C6EA51C0503@brianrosen.net> In-Reply-To: <736CC4E3-7489-42F6-9E68-1C6EA51C0503@brianrosen.net> Date: Fri, 13 Aug 2010 00:18:34 -0400 Message-ID: <006b01cb3a9e$9bbc3e00$d334ba00$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CB3A7D.14AC4BB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAH8ZVRzkW6XLaA= Content-language: en-us Cc: sip-ops@ietf.org, 'Hadriel Kaplan' , sip-implementors@lists.cs.columbia.edu Subject: Re: [sip-ops] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 04:19:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006C_01CB3A7D.14AC4BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian, If I could, I'd revise RFC 3261. It's that document that introduces the use of OPTIONS as a "ping" mechanism, but gives little guidance to implementers and, as such, implementations are all over the map. I've seen at least 6 different variants implemented. But, I think trying to revise RFC 3261 would open a can of worms. So, I was suggesting we progress this as standard track to update RFC 3261, but that didn't happen. I'm not trying to introduce anything new, though: just clarify what should have been elaborated upon more fully in 3261. Even so, there are certainly points of contention, I'm sure, since folks do have it implemented differently. Paul From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, August 12, 2010 8:45 AM To: Paul E. Jones Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Hadriel Kaplan Subject: Re: [sip-ops] SIP OPTIONS "ping" I think this is needed, and I would go for informational. While I sort of understand that you are "pushing" the definition of OPTIONS, if it was PS, you wouldn't update any RFCs, right? Brian On Aug 12, 2010, at 1:14 AM, Paul E. Jones wrote: Folks, Gonzalo and I produced an Internet Draft aiming at trying to bring some consistency to the way in which SIP user agents implement an OPTIONS "ping" procedure. It seems that a very large number of vendors do this, but unfortunately, there seems to be little consistency. Initially, we positioned the document as a standards track RFC, since this essentially builds on RFC 3261. However, there was some pushback from folks in the IETF for a variety of reasons, not the least of which is the fact that there is no working group chartered to do the work. We don't feel this one draft warrants the creation of a working group. So, we've got three options we can consider: 1) Forge ahead outside of a working group 2) Change the status of the draft to Informational 3) Forget about the draft and let every SIP device do it the way they want, throwing hope of consistency out the window (Yeah, you can tell I prefer not to go for the third option.) In any case, I'd like to get feedback from the on the SIP operators and SIP implementers lists. Do you think it's worth trying to address this issue? If so, which option do you think we should pursue? Note that we're certainly open to feedback on the draft. I'd prefer it to have a few more "MUST" statements in the text, rather than "SHOULD". But, we need to find that right balance: http://tools.ietf.org/html/draft-jones-sip-options-ping Paul _______________________________________________ sip-ops mailing list sip-ops@ietf.org https://www.ietf.org/mailman/listinfo/sip-ops ------=_NextPart_000_006C_01CB3A7D.14AC4BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

 

If I could, I’d revise RFC 3261.  It’s that document = that introduces the use of OPTIONS as a “ping” mechanism, = but gives little guidance to implementers and, as such, implementations = are all over the map.  I’ve seen at least 6 different = variants implemented.

 

But, I think trying to revise RFC 3261 would open a can of = worms.  So, I was suggesting we progress this as standard track to = update RFC 3261, but that didn’t happen.  I’m not = trying to introduce anything new, though: just clarify what should have = been elaborated upon more fully in 3261.  Even so, there are = certainly points of contention, I’m sure, since folks do have it = implemented differently.

 

Paul

 

From:= = Brian Rosen [mailto:br@brianrosen.net]
Sent: Thursday, August = 12, 2010 8:45 AM
To: Paul E. Jones
Cc: = sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Hadriel = Kaplan
Subject: Re: [sip-ops] SIP OPTIONS = "ping"

 

I think this = is needed, and I would go for informational.  While I sort of = understand that you are "pushing" the definition of OPTIONS, = if it was PS, you wouldn't update any RFCs, right?

 

Brian

 

On = Aug 12, 2010, at 1:14 AM, Paul E. Jones wrote:



Folks,=

 =

Gonzalo = and I produced an Internet Draft aiming at trying to bring some = consistency to the way in which SIP user agents implement an OPTIONS = “ping” procedure.  It seems that a very large number of = vendors do this, but unfortunately, there seems to be little = consistency.

 =

Initially, = we positioned the document as a standards track RFC, since this = essentially builds on RFC 3261.  However, there was some pushback = from folks in the IETF for a variety of reasons, not the least of which = is the fact that there is no working group chartered to do the = work.  We don’t feel this one draft warrants the creation of = a working group.

 =

So, = we’ve got three options we can = consider:

1)      Forge = ahead outside of a working group

2)      Change the = status of the draft to Informational

3)      Forget = about the draft and let every SIP device do it the way they want, = throwing hope of consistency out the = window

 =

(Yeah, you = can tell I prefer not to go for the third = option.)

 =

In any = case, I’d like to get feedback from the on the SIP operators and = SIP implementers lists.  Do you think it’s worth trying to = address this issue?  If so, which option do you think we should = pursue?

 =

Note that = we’re certainly open to feedback on the draft.  I’d = prefer it to have a few more “MUST” statements in the text, = rather than “SHOULD”.  But, we need to find that right = balance:

 =

Paul

 =

_________= ______________________________________
sip-ops mailing list
sip-ops@ietf.org
https://www.ietf.o= rg/mailman/listinfo/sip-ops

 

------=_NextPart_000_006C_01CB3A7D.14AC4BB0-- From paulej@packetizer.com Thu Aug 12 21:37:03 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134743A68AF; Thu, 12 Aug 2010 21:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.990, 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--Sn3epMqC4; Thu, 12 Aug 2010 21:37:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 7F4BD3A6886; Thu, 12 Aug 2010 21:37:01 -0700 (PDT) Received: from sydney (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 o7D4bV4m017262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Aug 2010 00:37:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281674257; bh=41p4n7EoAm5q58j8ClmAAJf2n2K4EamqWo3tDar8IIk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=AMOC93eGcjBYEu4hnchhkAzDKfcIoLjDQvBvUV5XD3cHokaF6AtuDcVvrgELF92S/ zjjZ7Owu64dYfurH+cvdfNWbGrIjAeDbf/IizM0bynVC49hfPxsqgwnWB3JIVstkM4 BVgKKvB+ZPnRcTfygHfKaInT837YdMmY9NJiMUwg= From: "Paul E. Jones" To: "'Cullen Jennings'" , Date: Fri, 13 Aug 2010 00:36:41 -0400 Message-ID: <007e01cb3aa1$23d1d190$6b7574b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acs6oSBLpTeEBoJnS/2FMd8r9uxzBg== Content-language: en-us Cc: sip-ops@ietf.org, 'Hadriel Kaplan' Subject: Re: [sip-ops] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 04:37:03 -0000 Cullen, Thanks for the suggestion. All, Please see the note below. We're seeking advice on how to proceed with the subject draft. Paul > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, August 12, 2010 11:44 PM > To: Paul E. Jones > Cc: sip-ops@ietf.org; Hadriel Kaplan > Subject: Re: [sip-ops] SIP OPTIONS "ping" > > > I think you discuss how to move forward with this draft on dispatch > mailing list given that's the point of that list is help with problems > like this. > > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote: > > > Folks, > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring some > consistency to the way in which SIP user agents implement an OPTIONS > "ping" procedure. It seems that a very large number of vendors do this, > but unfortunately, there seems to be little consistency. > > > > Initially, we positioned the document as a standards track RFC, since > this essentially builds on RFC 3261. However, there was some pushback > from folks in the IETF for a variety of reasons, not the least of which is > the fact that there is no working group chartered to do the work. We > don't feel this one draft warrants the creation of a working group. > > > > So, we've got three options we can consider: > > 1) Forge ahead outside of a working group > > 2) Change the status of the draft to Informational > > 3) Forget about the draft and let every SIP device do it the way > they want, throwing hope of consistency out the window > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > In any case, I'd like to get feedback from the on the SIP operators and > SIP implementers lists. Do you think it's worth trying to address this > issue? If so, which option do you think we should pursue? > > > > Note that we're certainly open to feedback on the draft. I'd prefer it > to have a few more "MUST" statements in the text, rather than "SHOULD". > But, we need to find that right balance: > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > Paul > > > > _______________________________________________ > > sip-ops mailing list > > sip-ops@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-ops > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > From paulej@packetizer.com Mon Aug 16 06:17:43 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CB23A681E; Mon, 16 Aug 2010 06:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=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 U7fv0jMSOlwZ; Mon, 16 Aug 2010 06:17:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id C75CD3A688E; Mon, 16 Aug 2010 06:17:41 -0700 (PDT) Received: from sydney (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 o7GDHx6Y014122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Aug 2010 09:18:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281964686; bh=7VdJc4HB6XEmHJkTJwC0KQJ3x6yT4Ssmjp8PlfTa1EU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=J09ayVr78hLC/D2k6PHDO22wdCizkEcVNVCv7c48TJAwYHq7aQrsToVyoXpuMGtW7 L6cIwJ4krd3onEHjp8IMrIntguiAmZn//iXL73tl7BxZga6cwXKhAhi1ZIbXORiubb 9LE6kpZcEUUuj/TBdqcraubtz3c8v6HToIVhMdJY= From: "Paul E. Jones" To: "'marius zbihlei'" References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> In-Reply-To: <4C690C38.6010804@1and1.ro> Date: Mon, 16 Aug 2010 09:17:03 -0400 Message-ID: <012901cb3d45$5544c880$ffce5980$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAJGarLckXGTVKA= Content-language: en-us Cc: sip-ops@ietf.org, dispatch@ietf.org, 'Hadriel Kaplan' , sip-implementors@lists.cs.columbia.edu Subject: Re: [sip-ops] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 13:17:43 -0000 Marius, It is certainly true that we were focused entirely on out-of-dialog OPTIONS messages when we wrote the draft. I'm certainly not opposed to also including in-dialog OPTIONS exchanges if it fit smoothly within the draft. Alternatively, we could create two drafts. Would you like to draft some initial text for in-dialog and see if it makes sense to include it in this same draft or a separate one? If in the same draft, then perhaps in-dialog and OOD would be two separate sections? Paul > -----Original Message----- > From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] > Sent: Monday, August 16, 2010 6:00 AM > To: Paul E. Jones > Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo > Salgueiro; Hadriel Kaplan > Subject: Re: [Sip-implementors] SIP OPTIONS "ping" > > Paul E. Jones wrote: > > Folks, > > > > > > > > Gonzalo and I produced an Internet Draft aiming at trying to bring > > some consistency to the way in which SIP user agents implement an > OPTIONS "ping" > > procedure. It seems that a very large number of vendors do this, but > > unfortunately, there seems to be little consistency. > > > > > > > > Initially, we positioned the document as a standards track RFC, since > > this essentially builds on RFC 3261. However, there was some pushback > > from folks in the IETF for a variety of reasons, not the least of > > which is the fact that there is no working group chartered to do the > > work. We don't feel this one draft warrants the creation of a working > group. > > > > > > > > So, we've got three options we can consider: > > > > 1) Forge ahead outside of a working group > > > > 2) Change the status of the draft to Informational > > > > 3) Forget about the draft and let every SIP device do it the way > they > > want, throwing hope of consistency out the window > > > > > > > > (Yeah, you can tell I prefer not to go for the third option.) > > > > > > > > In any case, I'd like to get feedback from the on the SIP operators > > and SIP implementers lists. Do you think it's worth trying to address > this issue? > > If so, which option do you think we should pursue? > > > > > > > Hello, > > I have read the draft and as far I can tell it addresses OPTIONS outside a > dialog. I know that this has already been discussed on this mailing > list[1], but there still are many vendors/SIP implementors that use a in- > dialog OPTIONS to figure out if a dialog is still running(if not the UAS > "will" respond with a 481- Call does not exist). By reading the comments > and the RFC I know this is wrong(a UAS might return a 200 OK even if the > dialog does not exist), but I think this enters into the "3) Forget about > the draft and let every SIP device do it the way they want, throwing hope > of consistency out the window " category. > > My first reaction is also to address this topic in the draft. What do you > think? > > Marius > > [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > May/019278.html > > Note that we're certainly open to feedback on the draft. I'd prefer > > it to have a few more "MUST" statements in the text, rather than > > "SHOULD". But, we need to find that right balance: > > > > http://tools.ietf.org/html/draft-jones-sip-options-ping > > > > > > > > Paul > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > From paulej@packetizer.com Mon Aug 16 09:46:21 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCB73A69FF; Mon, 16 Aug 2010 09:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, 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 mskALhJK5foI; Mon, 16 Aug 2010 09:46:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 4C51F3A6881; Mon, 16 Aug 2010 09:46:19 -0700 (PDT) Received: from sydney (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 o7GGkeZv021331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Aug 2010 12:46:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1281977206; bh=dNihPNbCFDt7yt2oAriEUHRYofxgpuvfKOiXR5gK9CA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=af+MLW3kUzXW7YjHnDXc27LmEfg+fq2VZKnyy9TGHCYlB9uHQnt7+awV2P4ZQWP08 m8RysRPrRtdvSRyQCn+Gu0fop6pXUtx+e7hy22AtpOdg6DEKZ8l9yOdSA0ov1YRuZV 9bp1m9H1tcLe5DwYBHyhS7yWB8mnYdpaKqkpb1gg= From: "Paul E. Jones" To: "'marius zbihlei'" References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> In-Reply-To: <4C694532.4020109@1and1.ro> Date: Mon, 16 Aug 2010 12:45:44 -0400 Message-ID: <017e01cb3d62$7c171d10$74455730$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ7YPXf2shkdXst8Oeg2uiqnTvIBAJGarLcAUcUVigCKte1dZFWP3xg Content-language: en-us Cc: sip-ops@ietf.org, dispatch@ietf.org, 'Hadriel Kaplan' , sip-implementors@lists.cs.columbia.edu Subject: Re: [sip-ops] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:46:21 -0000 Marius, There is another important consideration to give to this. The OPTIONS "ping" we described was intended to be between a device and its next hop. What you would actually want is an OPTIONS that goes end-to-end. I think both need clarification, but I'm now thinking that perhaps we ought to document these separately. Of course, I'd be happy to work with you on both. Paul > -----Original Message----- > From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] > Sent: Monday, August 16, 2010 10:04 AM > To: Paul E. Jones > Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo > Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org > Subject: Re: [Sip-implementors] SIP OPTIONS "ping" > > Paul E. Jones wrote: > > Marius, > > > > It is certainly true that we were focused entirely on out-of-dialog > > OPTIONS messages when we wrote the draft. I'm certainly not opposed > > to also including in-dialog OPTIONS exchanges if it fit smoothly within > the draft. > > Alternatively, we could create two drafts. > > > > Would you like to draft some initial text for in-dialog and see if it > > makes sense to include it in this same draft or a separate one? If in > > the same draft, then perhaps in-dialog and OOD would be two separate > sections? > > > > Paul > > > > > Hello again, > > I would gladly draft some initial text around this idea, but I am a little > torn apart between what I expect from the draft(and current > implementations) and what previous standards say. > > Quote from RFC 3261 > 12.2.2 UAS Behavior "Requests that do not change in any way the state of a > dialog may be received within a dialog (for example, an OPTIONS request). > They are processed as if they had been received outside the dialog." > > Along with other texts[1], this means that in-dialog OPTIONS requests > should be treated as OOD(also the thread I have linked seems to suggest > that). But I know for certain that lots of implementors do return a 481, > and several services rely on that error code to check if a dialog is still > running. I know about SIP Session Timers but using OPTIONS ping like > this(to discover if a dialog has finished) has some benefits(like the > proxy being able to terminate a call , which is not possible using SST > [2]), and more and more this looks like a "de facto" behavior. > > With this in mind, I have to ask the question: Should we allow (or > inforce) the 481 response for a in-dialog OPTIONS request(if the dialog > does not exits)(this is what I personally want and many implementors > already do), or should we respond with a 200 OK regardless if the dialog > exists or not?! > > Thank you in advance for answering this. > > [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only > those failures discussed in Section 5.1 and Section 5.2 that destroy > entire dialogs will have any effect on the usages sharing the dialog with > a failed OPTIONS request." > > This in fact might prove usefull, as a failed in-dialog OPTIONS request > will guaranty that the dialog will not be destroyed > > [2] http://www.rfc-editor.org/rfc/rfc4028.txt > 8.3. Session Expiration > > When the current time equals or passes the session expiration for a > session, the proxy MAY remove associated call state, and MAY free any > resources associated with the call. Unlike the UA, it MUST NOT send a BYE. > >> -----Original Message----- > >> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] > >> Sent: Monday, August 16, 2010 6:00 AM > >> To: Paul E. Jones > >> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo > >> Salgueiro; Hadriel Kaplan > >> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" > >> > >> Paul E. Jones wrote: > >> > >>> Folks, > >>> > >>> > >>> > >>> Gonzalo and I produced an Internet Draft aiming at trying to bring > >>> some consistency to the way in which SIP user agents implement an > >>> > >> OPTIONS "ping" > >> > >>> procedure. It seems that a very large number of vendors do this, > >>> but unfortunately, there seems to be little consistency. > >>> > >>> > >>> > >>> Initially, we positioned the document as a standards track RFC, > >>> since this essentially builds on RFC 3261. However, there was some > >>> pushback from folks in the IETF for a variety of reasons, not the > >>> least of which is the fact that there is no working group chartered > >>> to do the work. We don't feel this one draft warrants the creation > >>> of a working > >>> > >> group. > >> > >>> > >>> So, we've got three options we can consider: > >>> > >>> 1) Forge ahead outside of a working group > >>> > >>> 2) Change the status of the draft to Informational > >>> > >>> 3) Forget about the draft and let every SIP device do it the way > >>> > >> they > >> > >>> want, throwing hope of consistency out the window > >>> > >>> > >>> > >>> (Yeah, you can tell I prefer not to go for the third option.) > >>> > >>> > >>> > >>> In any case, I'd like to get feedback from the on the SIP operators > >>> and SIP implementers lists. Do you think it's worth trying to > >>> address > >>> > >> this issue? > >> > >>> If so, which option do you think we should pursue? > >>> > >>> > >>> > >>> > >> Hello, > >> > >> I have read the draft and as far I can tell it addresses OPTIONS > >> outside a dialog. I know that this has already been discussed on this > >> mailing list[1], but there still are many vendors/SIP implementors > >> that use a in- dialog OPTIONS to figure out if a dialog is still > >> running(if not the UAS "will" respond with a 481- Call does not > >> exist). By reading the comments and the RFC I know this is wrong(a > >> UAS might return a 200 OK even if the dialog does not exist), but I > >> think this enters into the "3) Forget about the draft and let every > >> SIP device do it the way they want, throwing hope of consistency out > the window " category. > >> > >> My first reaction is also to address this topic in the draft. What do > >> you think? > >> > >> Marius > >> > >> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > >> May/019278.html > >> > >>> Note that we're certainly open to feedback on the draft. I'd prefer > >>> it to have a few more "MUST" statements in the text, rather than > >>> "SHOULD". But, we need to find that right balance: > >>> > >>> http://tools.ietf.org/html/draft-jones-sip-options-ping > >>> > >>> > >>> > >>> Paul > >>> > >>> > >>> > >>> _______________________________________________ > >>> Sip-implementors mailing list > >>> Sip-implementors@lists.cs.columbia.edu > >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>> > >>> > >>> > > > > > > > > From mlm.michael.miller@gmail.com Mon Aug 16 14:17:32 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7783A6AC3; Mon, 16 Aug 2010 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.397 X-Spam-Level: ** X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17HH-wbfciW4; Mon, 16 Aug 2010 14:17:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 605483A6ABD; Mon, 16 Aug 2010 14:17:29 -0700 (PDT) Received: by vws10 with SMTP id 10so4217175vws.31 for ; Mon, 16 Aug 2010 14:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=A1WWeN+jA66ljfKs/cX2V56cvQ1cRglw2VCJjmvT5fk=; b=LMNqNvCMxbbyGKHengAlWNE2nPnydUMf4gaZuxnIcH+irvZBdGM2gHejkFSmcnm8WM LnhS7yC8dq2iF6lpXQyKd25U7h7NA8aqu3l7Zmu5sW/eRT4knbho6SeAO89yEMlxpqFn cHWh1V3BNp98zvTBrdUbCw7oBy4zTds89gqO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=rPMrs4kEOUwe1Rpmyf514rVmGnGwZjj08pL8KE48X/mzH4QMxkZnhIGwopDCbpDps5 GigylktONdgo5SGyfi9B8S73Vwg51dl7qSAVw/602wjlKLZurms/7Ldp+6KxoGn0SsZB k+J+9KrBaKt0LwF+h0XuRDCBUrwaO8WKJaiYU= Received: by 10.220.122.151 with SMTP id l23mr3365024vcr.162.1281993482887; Mon, 16 Aug 2010 14:18:02 -0700 (PDT) Received: from [10.70.112.39] (mobile-166-137-136-078.mycingular.net [166.137.136.78]) by mx.google.com with ESMTPS id a16sm432583vcm.42.2010.08.16.14.18.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 14:18:02 -0700 (PDT) References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> In-Reply-To: <017e01cb3d62$7c171d10$74455730$@packetizer.com> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8A306) From: Michael Miller Date: Mon, 16 Aug 2010 17:18:06 -0400 To: "Paul E. Jones" X-Mailman-Approved-At: Mon, 16 Aug 2010 14:54:33 -0700 Cc: "dispatch@ietf.org" , "sip-ops@ietf.org" , marius zbihlei , Hadriel Kaplan , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [sip-ops] [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:17:32 -0000 The end the end OPTIONS ping sounds like a great ideal, but does this change= this doc from more of a informational/best practice to some thing that woul= d require a change to SIP (like a header or something).=20 I'm new to this Michael L. Miller Sent from my Mobile Device On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" wrote:= > Marius, >=20 > There is another important consideration to give to this. The OPTIONS > "ping" we described was intended to be between a device and its next hop. > What you would actually want is an OPTIONS that goes end-to-end. >=20 > I think both need clarification, but I'm now thinking that perhaps we ough= t > to document these separately. Of course, I'd be happy to work with you on= > both. >=20 > Paul >=20 >> -----Original Message----- >> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >> Sent: Monday, August 16, 2010 10:04 AM >> To: Paul E. Jones >> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo >> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org >> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>=20 >> Paul E. Jones wrote: >>> Marius, >>>=20 >>> It is certainly true that we were focused entirely on out-of-dialog >>> OPTIONS messages when we wrote the draft. I'm certainly not opposed >>> to also including in-dialog OPTIONS exchanges if it fit smoothly within >> the draft. >>> Alternatively, we could create two drafts. >>>=20 >>> Would you like to draft some initial text for in-dialog and see if it >>> makes sense to include it in this same draft or a separate one? If in >>> the same draft, then perhaps in-dialog and OOD would be two separate >> sections? >>>=20 >>> Paul >>>=20 >>>=20 >> Hello again, >>=20 >> I would gladly draft some initial text around this idea, but I am a littl= e >> torn apart between what I expect from the draft(and current >> implementations) and what previous standards say. >>=20 >> Quote from RFC 3261 >> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a= >> dialog may be received within a dialog (for example, an OPTIONS request).= >> They are processed as if they had been received outside the dialog." >>=20 >> Along with other texts[1], this means that in-dialog OPTIONS requests >> should be treated as OOD(also the thread I have linked seems to suggest >> that). But I know for certain that lots of implementors do return a 481, >> and several services rely on that error code to check if a dialog is stil= l >> running. I know about SIP Session Timers but using OPTIONS ping like >> this(to discover if a dialog has finished) has some benefits(like the >> proxy being able to terminate a call , which is not possible using SST >> [2]), and more and more this looks like a "de facto" behavior. >>=20 >> With this in mind, I have to ask the question: Should we allow (or >> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog >> does not exits)(this is what I personally want and many implementors >> already do), or should we respond with a 200 OK regardless if the dialog >> exists or not?! >>=20 >> Thank you in advance for answering this. >>=20 >> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only >> those failures discussed in Section 5.1 and Section 5.2 that destroy >> entire dialogs will have any effect on the usages sharing the dialog with= >> a failed OPTIONS request." >>=20 >> This in fact might prove usefull, as a failed in-dialog OPTIONS request >> will guaranty that the dialog will not be destroyed >>=20 >> [2] http://www.rfc-editor.org/rfc/rfc4028.txt >> 8.3. Session Expiration >>=20 >> When the current time equals or passes the session expiration for a >> session, the proxy MAY remove associated call state, and MAY free any >> resources associated with the call. Unlike the UA, it MUST NOT send a BYE= . >>>> -----Original Message----- >>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>> Sent: Monday, August 16, 2010 6:00 AM >>>> To: Paul E. Jones >>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo >>>> Salgueiro; Hadriel Kaplan >>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>=20 >>>> Paul E. Jones wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Gonzalo and I produced an Internet Draft aiming at trying to bring >>>>> some consistency to the way in which SIP user agents implement an >>>>>=20 >>>> OPTIONS "ping" >>>>=20 >>>>> procedure. It seems that a very large number of vendors do this, >>>>> but unfortunately, there seems to be little consistency. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Initially, we positioned the document as a standards track RFC, >>>>> since this essentially builds on RFC 3261. However, there was some >>>>> pushback from folks in the IETF for a variety of reasons, not the >>>>> least of which is the fact that there is no working group chartered >>>>> to do the work. We don't feel this one draft warrants the creation >>>>> of a working >>>>>=20 >>>> group. >>>>=20 >>>>>=20 >>>>> So, we've got three options we can consider: >>>>>=20 >>>>> 1) Forge ahead outside of a working group >>>>>=20 >>>>> 2) Change the status of the draft to Informational >>>>>=20 >>>>> 3) Forget about the draft and let every SIP device do it the way >>>>>=20 >>>> they >>>>=20 >>>>> want, throwing hope of consistency out the window >>>>>=20 >>>>>=20 >>>>>=20 >>>>> (Yeah, you can tell I prefer not to go for the third option.) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> In any case, I'd like to get feedback from the on the SIP operators >>>>> and SIP implementers lists. Do you think it's worth trying to >>>>> address >>>>>=20 >>>> this issue? >>>>=20 >>>>> If so, which option do you think we should pursue? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> Hello, >>>>=20 >>>> I have read the draft and as far I can tell it addresses OPTIONS >>>> outside a dialog. I know that this has already been discussed on this >>>> mailing list[1], but there still are many vendors/SIP implementors >>>> that use a in- dialog OPTIONS to figure out if a dialog is still >>>> running(if not the UAS "will" respond with a 481- Call does not >>>> exist). By reading the comments and the RFC I know this is wrong(a >>>> UAS might return a 200 OK even if the dialog does not exist), but I >>>> think this enters into the "3) Forget about the draft and let every >>>> SIP device do it the way they want, throwing hope of consistency out >> the window " category. >>>>=20 >>>> My first reaction is also to address this topic in the draft. What do >>>> you think? >>>>=20 >>>> Marius >>>>=20 >>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- >>>> May/019278.html >>>>=20 >>>>> Note that we're certainly open to feedback on the draft. I'd prefer >>>>> it to have a few more "MUST" statements in the text, rather than >>>>> "SHOULD". But, we need to find that right balance: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-jones-sip-options-ping >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Sip-implementors mailing list >>>>> Sip-implementors@lists.cs.columbia.edu >>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Mon Aug 16 16:16:03 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE113A6827; Mon, 16 Aug 2010 16:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, 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 TEc5N7jx-825; Mon, 16 Aug 2010 16:16:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id F3FF33A681D; Mon, 16 Aug 2010 16:16:01 -0700 (PDT) Received: from dyn-129.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 o7GNGNnB032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 19:16:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1282000590; bh=+S5AhyXvDDleSwLoNLEfFmVwGvtmlu2wPbDZpj8GY/0=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=NDmwEFgMbVnMe74tAmRWU7Jq1RHHvuuZkAJpGBaZYEy78bzelwAAmMunPEuVg7EVx MIc35BiyhohaQoRroFw0hwoqpsJH8VDekzit+Btm60nb+2Y29Hfm7u0IH2vXQk1SFP w3Ri/7/7nc9RgxzeZNiYhuEvXfL6yRX2Pe6AmvR0= X-User-Agent: K-9 Mail for Android References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Mon, 16 Aug 2010 18:54:09 -0400 To: Michael Miller Message-ID: Cc: "dispatch@ietf.org" , "sip-ops@ietf.org" , marius zbihlei , Hadriel Kaplan , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [sip-ops] [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 23:16:03 -0000 We had a side discussion and reached agreement that this end-to-end procedure really ought to be a separate document. I think the scope of each is enough to justify two documents. So, we'll collaborate to produce two separate documents. Whether those will be informational or standards track is TBD. Paul "Michael Miller" wrote: >The end the end OPTIONS ping sounds like a great ideal, but does this change this doc from more of a informational/best practice to some thing that would require a change to SIP (like a header or something). > >I'm new to this > >Michael L. Miller >Sent from my Mobile Device > >On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" wrote: > >> Marius, >> >> There is another important consideration to give to this. The OPTIONS >> "ping" we described was intended to be between a device and its next hop. >> What you would actually want is an OPTIONS that goes end-to-end. >> >> I think both need clarification, but I'm now thinking that perhaps we ought >> to document these separately. Of course, I'd be happy to work with you on >> both. >> >> Paul >> >>> -----Original Message----- >>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>> Sent: Monday, August 16, 2010 10:04 AM >>> To: Paul E. Jones >>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo >>> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org >>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>> >>> Paul E. Jones wrote: >>>> Marius, >>>> >>>> It is certainly true that we were focused entirely on out-of-dialog >>>> OPTIONS messages when we wrote the draft. I'm certainly not opposed >>>> to also including in-dialog OPTIONS exchanges if it fit smoothly within >>> the draft. >>>> Alternatively, we could create two drafts. >>>> >>>> Would you like to draft some initial text for in-dialog and see if it >>>> makes sense to include it in this same draft or a separate one? If in >>>> the same draft, then perhaps in-dialog and OOD would be two separate >>> sections? >>>> >>>> Paul >>>> >>>> >>> Hello again, >>> >>> I would gladly draft some initial text around this idea, but I am a little >>> torn apart between what I expect from the draft(and current >>> implementations) and what previous standards say. >>> >>> Quote from RFC 3261 >>> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a >>> dialog may be received within a dialog (for example, an OPTIONS request). >>> They are processed as if they had been received outside the dialog." >>> >>> Along with other texts[1], this means that in-dialog OPTIONS requests >>> should be treated as OOD(also the thread I have linked seems to suggest >>> that). But I know for certain that lots of implementors do return a 481, >>> and several services rely on that error code to check if a dialog is still >>> running. I know about SIP Session Timers but using OPTIONS ping like >>> this(to discover if a dialog has finished) has some benefits(like the >>> proxy being able to terminate a call , which is not possible using SST >>> [2]), and more and more this looks like a "de facto" behavior. >>> >>> With this in mind, I have to ask the question: Should we allow (or >>> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog >>> does not exits)(this is what I personally want and many implementors >>> already do), or should we respond with a 200 OK regardless if the dialog >>> exists or not?! >>> >>> Thank you in advance for answering this. >>> >>> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only >>> those failures discussed in Section 5.1 and Section 5.2 that destroy >>> entire dialogs will have any effect on the usages sharing the dialog with >>> a failed OPTIONS request." >>> >>> This in fact might prove usefull, as a failed in-dialog OPTIONS request >>> will guaranty that the dialog will not be destroyed >>> >>> [2] http://www.rfc-editor.org/rfc/rfc4028.txt >>> 8.3. Session Expiration >>> >>> When the current time equals or passes the session expiration for a >>> session, the proxy MAY remove associated call state, and MAY free any >>> resources associated with the call. Unlike the UA, it MUST NOT send a BYE. >>>>> -----Original Message----- >>>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>>> Sent: Monday, August 16, 2010 6:00 AM >>>>> To: Paul E. Jones >>>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo >>>>> Salgueiro; Hadriel Kaplan >>>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>> >>>>> Paul E. Jones wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> >>>>>> >>>>>> Gonzalo and I produced an Internet Draft aiming at trying to bring >>>>>> some consistency to the way in which SIP user agents implement an >>>>>> >>>>> OPTIONS "ping" >>>>> >>>>>> procedure. It seems that a very large number of vendors do this, >>>>>> but unfortunately, there seems to be little consistency. >>>>>> >>>>>> >>>>>> >>>>>> Initially, we positioned the document as a standards track RFC, >>>>>> since this essentially builds on RFC 3261. However, there was some >>>>>> pushback from folks in the IETF for a variety of reasons, not the >>>>>> least of which is the fact that there is no working group chartered >>>>>> to do the work. We don't feel this one draft warrants the creation >>>>>> of a working >>>>>> >>>>> group. >>>>> >>>>>> >>>>>> So, we've got three options we can consider: >>>>>> >>>>>> 1) Forge ahead outside of a working group >>>>>> >>>>>> 2) Change the status of the draft to Informational >>>>>> >>>>>> 3) Forget about the draft and let every SIP device do it the way >>>>>> >>>>> they >>>>> >>>>>> want, throwing hope of consistency out the window >>>>>> >>>>>> >>>>>> >>>>>> (Yeah, you can tell I prefer not to go for the third option.) >>>>>> >>>>>> >>>>>> >>>>>> In any case, I'd like to get feedback from the on the SIP operators >>>>>> and SIP implementers lists. Do you think it's worth trying to >>>>>> address >>>>>> >>>>> this issue? >>>>> >>>>>> If so, which option do you think we should pursue? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hello, >>>>> >>>>> I have read the draft and as far I can tell it addresses OPTIONS >>>>> outside a dialog. I know that this has already been discussed on this >>>>> mailing list[1], but there still are many vendors/SIP implementors >>>>> that use a in- dialog OPTIONS to figure out if a dialog is still >>>>> running(if not the UAS "will" respond with a 481- Call does not >>>>> exist). By reading the comments and the RFC I know this is wrong(a >>>>> UAS might return a 200 OK even if the dialog does not exist), but I >>>>> think this enters into the "3) Forget about the draft and let every >>>>> SIP device do it the way they want, throwing hope of consistency out >>> the window " category. >>>>> >>>>> My first reaction is also to address this topic in the draft. What do >>>>> you think? >>>>> >>>>> Marius >>>>> >>>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- >>>>> May/019278.html >>>>> >>>>>> Note that we're certainly open to feedback on the draft. I'd prefer >>>>>> it to have a few more "MUST" statements in the text, rather than >>>>>> "SHOULD". But, we need to find that right balance: >>>>>> >>>>>> http://tools.ietf.org/html/draft-jones-sip-options-ping >>>>>> >>>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip-implementors mailing list >>>>>> Sip-implementors@lists.cs.columbia.edu >>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From mlm.michael.miller@gmail.com Mon Aug 16 16:36:56 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE8A3A6827; Mon, 16 Aug 2010 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.397 X-Spam-Level: ** X-Spam-Status: No, score=2.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSwh6dVXOrcm; Mon, 16 Aug 2010 16:36:55 -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 C8FB23A67F0; Mon, 16 Aug 2010 16:36:54 -0700 (PDT) Received: by gwaa18 with SMTP id a18so2562730gwa.31 for ; Mon, 16 Aug 2010 16:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=1ISZGdeQDIMKVkSO29svAsKiGU20+BAYTYVEYAv++4o=; b=Oits9tyQ0F6Wv13Bxs+nmPDCVCAtJcNWNgz0i0lN134bVRHs5Ugd6DFvsZ+9/DQLhN REdbdQZqG8OZyUB2xTQnmh3YHjdKx+BEF6Q3CXudmIx9MHoKLelAt97K2nDlqbSBW0bc ANOYZVGFZHqU+BX1uqWTa+IvDkqi9Eb1AFq1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=YUsaH7PW4r9hKz1HotcRzoUVBKvnN8qb+s260Ot2xMPemjAjgNtl35SetPD85dMJ01 ioziLbXYD+q0RYJxeK/8A+/3GGdb3zhP6ovW3LaAreE9IfVjPk0Ddwd3yBMNKWBSpdKf cszsZAhr3F+Oq0fhbwzkpI7m2EpI3j0HmsXH0= Received: by 10.101.138.8 with SMTP id q8mr6622814ann.164.1282001842173; Mon, 16 Aug 2010 16:37:22 -0700 (PDT) Received: from [192.168.1.162] (c-71-205-254-94.hsd1.mi.comcast.net [71.205.254.94]) by mx.google.com with ESMTPS id p12sm11128358ane.34.2010.08.16.16.37.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 16:37:21 -0700 (PDT) References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com> <4C690C38.6010804@1and1.ro> <012901cb3d45$5544c880$ffce5980$@packetizer.com> <4C694532.4020109@1and1.ro> <017e01cb3d62$7c171d10$74455730$@packetizer.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: text/plain; charset=us-ascii Message-Id: <67CEA0ED-6F29-4D89-9177-6355B8EC8458@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8A306) From: Michael Miller Date: Mon, 16 Aug 2010 19:37:28 -0400 To: "Paul E. Jones" Cc: "dispatch@ietf.org" , "sip-ops@ietf.org" , marius zbihlei , Hadriel Kaplan , "sip-implementors@lists.cs.columbia.edu" Subject: Re: [sip-ops] [dispatch] [Sip-implementors] SIP OPTIONS "ping" X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 23:36:56 -0000 Ok. Sounds good. I like to help where I can.=20 Michael L. Miller Sent from my Mobile Device On Aug 16, 2010, at 6:54 PM, "Paul E. Jones" wrote: > We had a side discussion and reached agreement that this end-to-end proced= ure really ought to be a separate document. I think the scope of each is eno= ugh to justify two documents. >=20 > So, we'll collaborate to produce two separate documents. Whether those wil= l be informational or standards track is TBD. >=20 > Paul >=20 > "Michael Miller" wrote: >=20 >> The end the end OPTIONS ping sounds like a great ideal, but does this cha= nge this doc from more of a informational/best practice to some thing that w= ould require a change to SIP (like a header or something).=20 >>=20 >> I'm new to this >>=20 >> Michael L. Miller >> Sent from my Mobile Device >>=20 >> On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" wro= te: >>=20 >>> Marius, >>>=20 >>> There is another important consideration to give to this. The OPTIONS >>> "ping" we described was intended to be between a device and its next hop= . >>> What you would actually want is an OPTIONS that goes end-to-end. >>>=20 >>> I think both need clarification, but I'm now thinking that perhaps we ou= ght >>> to document these separately. Of course, I'd be happy to work with you o= n >>> both. >>>=20 >>> Paul >>>=20 >>>> -----Original Message----- >>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>> Sent: Monday, August 16, 2010 10:04 AM >>>> To: Paul E. Jones >>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; 'Gonzalo >>>> Salgueiro'; 'Hadriel Kaplan'; dispatch@ietf.org >>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>=20 >>>> Paul E. Jones wrote: >>>>> Marius, >>>>>=20 >>>>> It is certainly true that we were focused entirely on out-of-dialog >>>>> OPTIONS messages when we wrote the draft. I'm certainly not opposed >>>>> to also including in-dialog OPTIONS exchanges if it fit smoothly withi= n >>>> the draft. >>>>> Alternatively, we could create two drafts. >>>>>=20 >>>>> Would you like to draft some initial text for in-dialog and see if it >>>>> makes sense to include it in this same draft or a separate one? If in= >>>>> the same draft, then perhaps in-dialog and OOD would be two separate >>>> sections? >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>> Hello again, >>>>=20 >>>> I would gladly draft some initial text around this idea, but I am a lit= tle >>>> torn apart between what I expect from the draft(and current >>>> implementations) and what previous standards say. >>>>=20 >>>> Quote from RFC 3261 >>>> 12.2.2 UAS Behavior "Requests that do not change in any way the state o= f a >>>> dialog may be received within a dialog (for example, an OPTIONS request= ). >>>> They are processed as if they had been received outside the dialog." >>>>=20 >>>> Along with other texts[1], this means that in-dialog OPTIONS requests >>>> should be treated as OOD(also the thread I have linked seems to suggest= >>>> that). But I know for certain that lots of implementors do return a 481= , >>>> and several services rely on that error code to check if a dialog is st= ill >>>> running. I know about SIP Session Timers but using OPTIONS ping like >>>> this(to discover if a dialog has finished) has some benefits(like the >>>> proxy being able to terminate a call , which is not possible using SST >>>> [2]), and more and more this looks like a "de facto" behavior. >>>>=20 >>>> With this in mind, I have to ask the question: Should we allow (or >>>> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog= >>>> does not exits)(this is what I personally want and many implementors >>>> already do), or should we respond with a 200 OK regardless if the dialo= g >>>> exists or not?! >>>>=20 >>>> Thank you in advance for answering this. >>>>=20 >>>> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only >>>> those failures discussed in Section 5.1 and Section 5.2 that destroy >>>> entire dialogs will have any effect on the usages sharing the dialog wi= th >>>> a failed OPTIONS request." >>>>=20 >>>> This in fact might prove usefull, as a failed in-dialog OPTIONS request= >>>> will guaranty that the dialog will not be destroyed >>>>=20 >>>> [2] http://www.rfc-editor.org/rfc/rfc4028.txt >>>> 8.3. Session Expiration >>>>=20 >>>> When the current time equals or passes the session expiration for a >>>> session, the proxy MAY remove associated call state, and MAY free any >>>> resources associated with the call. Unlike the UA, it MUST NOT send a B= YE. >>>>>> -----Original Message----- >>>>>> From: marius zbihlei [mailto:marius.zbihlei@1and1.ro] >>>>>> Sent: Monday, August 16, 2010 6:00 AM >>>>>> To: Paul E. Jones >>>>>> Cc: sip-ops@ietf.org; sip-implementors@lists.cs.columbia.edu; Gonzalo= >>>>>> Salgueiro; Hadriel Kaplan >>>>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping" >>>>>>=20 >>>>>> Paul E. Jones wrote: >>>>>>=20 >>>>>>> Folks, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Gonzalo and I produced an Internet Draft aiming at trying to bring >>>>>>> some consistency to the way in which SIP user agents implement an >>>>>>>=20 >>>>>> OPTIONS "ping" >>>>>>=20 >>>>>>> procedure. It seems that a very large number of vendors do this, >>>>>>> but unfortunately, there seems to be little consistency. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Initially, we positioned the document as a standards track RFC, >>>>>>> since this essentially builds on RFC 3261. However, there was some >>>>>>> pushback from folks in the IETF for a variety of reasons, not the >>>>>>> least of which is the fact that there is no working group chartered >>>>>>> to do the work. We don't feel this one draft warrants the creation >>>>>>> of a working >>>>>>>=20 >>>>>> group. >>>>>>=20 >>>>>>>=20 >>>>>>> So, we've got three options we can consider: >>>>>>>=20 >>>>>>> 1) Forge ahead outside of a working group >>>>>>>=20 >>>>>>> 2) Change the status of the draft to Informational >>>>>>>=20 >>>>>>> 3) Forget about the draft and let every SIP device do it the wa= y >>>>>>>=20 >>>>>> they >>>>>>=20 >>>>>>> want, throwing hope of consistency out the window >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> (Yeah, you can tell I prefer not to go for the third option.) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> In any case, I'd like to get feedback from the on the SIP operators >>>>>>> and SIP implementers lists. Do you think it's worth trying to >>>>>>> address >>>>>>>=20 >>>>>> this issue? >>>>>>=20 >>>>>>> If so, which option do you think we should pursue? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I have read the draft and as far I can tell it addresses OPTIONS >>>>>> outside a dialog. I know that this has already been discussed on this= >>>>>> mailing list[1], but there still are many vendors/SIP implementors >>>>>> that use a in- dialog OPTIONS to figure out if a dialog is still >>>>>> running(if not the UAS "will" respond with a 481- Call does not >>>>>> exist). By reading the comments and the RFC I know this is wrong(a >>>>>> UAS might return a 200 OK even if the dialog does not exist), but I >>>>>> think this enters into the "3) Forget about the draft and let every >>>>>> SIP device do it the way they want, throwing hope of consistency out >>>> the window " category. >>>>>>=20 >>>>>> My first reaction is also to address this topic in the draft. What do= >>>>>> you think? >>>>>>=20 >>>>>> Marius >>>>>>=20 >>>>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- >>>>>> May/019278.html >>>>>>=20 >>>>>>> Note that we're certainly open to feedback on the draft. I'd prefer= >>>>>>> it to have a few more "MUST" statements in the text, rather than >>>>>>> "SHOULD". But, we need to find that right balance: >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-jones-sip-options-ping >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Paul >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Sip-implementors mailing list >>>>>>> Sip-implementors@lists.cs.columbia.edu >>>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >=20 From partr@cisco.com Mon Aug 30 09:51:03 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B4D3A6837; Mon, 30 Aug 2010 09:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.287 X-Spam-Level: X-Spam-Status: No, score=-9.287 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iewwSj5unsHd; Mon, 30 Aug 2010 09:51:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 076363A6841; Mon, 30 Aug 2010 09:50:36 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgIAOV9e0yrR7H+/2dsb2JhbACTJoUYAYc3S3GhXJs7hTcEhDmIRA X-IronPort-AV: E=Sophos;i="4.56,293,1280707200"; d="scan'208,217";a="275346263" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 30 Aug 2010 16:51:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7UGp58k010748; Mon, 30 Aug 2010 16:51:06 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Aug 2010 22:21:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4863.88D4CDFE" Date: Mon, 30 Aug 2010 22:21:04 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Resource availability Event package Thread-Index: ActITqjnejR+Z0DIROGgppf59yc2GgAE/EYL References: <20100830142058.6A0EA3A69B8@core3.amsl.com> From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 30 Aug 2010 16:51:04.0732 (UTC) FILETIME=[88FB3DC0:01CB4863] Cc: sip-ops@ietf.org, "Sheshadri Shalya \(svshesha\)" , sip-overload@ietf.org, "Paul Kyzivat \(pkyzivat\)" , mediactrl@ietf.org Subject: [sip-ops] SIP Resource availability Event package X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 16:51:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4863.88D4CDFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.=20 This draft was discussed in IETF-78 SoC WG and considered as outside the = scope of SOC as it focus on SIP overload based on non-critical resources = like DS0, DSP. By looking at the mediactrl WG charter and working = documents, I doubt that this draft will falls under current media-ctrl = work. As this draft helps in SIP based devices manageability, I looked = for SIP manageability related WG but Sip-ops mailing alias only exists = and there is no WG associated with it. So, I'm putting this document in = dispatch WG for further proceedings.=20 Abstract is as follows: "Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities." The draft is available at = http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-availabili= ty/ = . Could you please provide your valuable comments. Thanks Partha ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Mon 8/30/2010 7:50 PM To: Parthasarathi R (partr) Cc: Sheshadri Shalya (svshesha) Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00=20 A new version of I-D, draft-partha-dispatch-resource-availability-00.txt = has been successfully submitted by Parthasarathi R and posted to the = IETF repository. Filename: draft-partha-dispatch-resource-availability Revision: 00 Title: Session Initiation Protocol (SIP) Resource availability = Event package Creation_date: 2010-08-30 WG ID: Independent Submission Number_of_pages: 17 Abstract: Collecting Resource availability information in Session Initiation Protocol (SIP) devices in real time helps in better managebility of resources in the SIP network. Resource availability monitoring in SIP devices helps administrator to take informed decision and corrective measures to tackle under or over resource utilization in the network. Resource availability information can also be used for SIP overload control in SIP based Media servers by passing resource demand vector between devices. This document defines resource availability XML document and the mechanisms that can be used to exchange the document between SIP entities. = =20 The IETF Secretariat. ------_=_NextPart_001_01CB4863.88D4CDFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Version Notification for = draft-partha-dispatch-resource-availability-00=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=

Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.

=0A=

This draft was discussed in IETF-78 SoC WG and considered as outside = the scope of SOC as it focus on SIP overload based on non-critical = resources like DS0, DSP. By looking at the mediactrl WG charter and = working documents, I doubt that this draft will falls under current = media-ctrl work. As this draft helps in SIP based devices manageability, = I looked for SIP manageability related WG but Sip-ops mailing alias only = exists and there is no WG associated with it. So, I'm putting this = document in dispatch WG for further proceedings.

=0A=

Abstract is as follows:

=0A=

"Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities."

=0A=

=0A=

The draft is available at http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-= availability/. Could you please provide your valuable comments.

=0A=

Thanks

=0A=

Partha

=0A=


=0A=


=0A= From: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]
Sent: Mon 8/30/2010 7:50 = PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya = (svshesha)
Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00 =

=0A=

=0A=

A new version of I-D, = draft-partha-dispatch-resource-availability-00.txt has been successfully = submitted by Parthasarathi R and posted to the IETF = repository.

Filename:        = draft-partha-dispatch-resource-availability
Revision:   = ;     00
Title:  =          Session Initiation = Protocol (SIP) Resource availability Event = package
Creation_date:   2010-08-30
WG ID:  =          Independent = Submission
Number_of_pages: 17

Abstract:
Collecting = Resource availability information in Session Initiation
Protocol = (SIP) devices in real time helps in better managebility of
resources = in the SIP network.  Resource availability monitoring in
SIP = devices helps administrator to take informed decision and
corrective = measures to tackle under or over resource utilization in
the = network.  Resource availability information can also be used = for
SIP overload control in SIP based Media servers by passing = resource
demand vector between devices.  This document defines = resource
availability XML document and the mechanisms that can be = used to
exchange the document between SIP = entities.
          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          


= The IETF Secretariat.


------_=_NextPart_001_01CB4863.88D4CDFE-- From mlm.michael.miller@gmail.com Tue Aug 31 14:34:24 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE803A684D; Tue, 31 Aug 2010 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFYp-QU+nelh; Tue, 31 Aug 2010 14:34:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 27AC13A682B; Tue, 31 Aug 2010 14:34:22 -0700 (PDT) Received: by yxl31 with SMTP id 31so1629019yxl.31 for ; Tue, 31 Aug 2010 14:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :x-mailer:from:subject:date:to; bh=9CXFTLynHfqFjDSTZ9JLyt7x0Y95j0ZCrRwyhRhD37U=; b=aTgz3TF9PZAAf9qoGV3ChYotlGj3pDptWeLfgdq1L6q4MiW7Ifv8Kkh7hJOZ8WEjmh TG0waD7ERJWDJT2bm1UnKczilBuVXgiIkMKdhLu3LNunFOmQ8ccoVGWUAOYi9Uq7zefw K2cA8xvMNiiJOnqTd++srVIcEOvViZs9Le6Z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=xDLVwo9jw1Y86QC5DdKw6QluAIxGRpPsqJTqUPvaM9LV9YV6xIzNj6CEW92u8bDReD JGbfM/ae80VIdL7JKxkB9w/1ptusuLndeFXUH5EbOAqLNNAhmOMobyga4ET8Cl37FTy5 zh/CNDtsaP3fwL+QKpSJlL57rmneQ4x7cARgk= Received: by 10.100.164.5 with SMTP id m5mr7157847ane.147.1283290492452; Tue, 31 Aug 2010 14:34:52 -0700 (PDT) Received: from [10.80.93.206] (mobile-166-137-136-115.mycingular.net [166.137.136.115]) by mx.google.com with ESMTPS id w6sm15292659anb.23.2010.08.31.14.34.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 14:34:51 -0700 (PDT) References: <20100830142058.6A0EA3A69B8@core3.amsl.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: multipart/alternative; boundary=Apple-Mail-26-40632250 Message-Id: <5D9746F9-9D36-4482-8B61-94AED338EDE2@gmail.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8A306) From: Michael Miller Date: Tue, 31 Aug 2010 17:35:05 -0400 To: "Parthasarathi R (partr)" Cc: "sip-ops@ietf.org" , "" , "sip-overload@ietf.org" , "mediactrl@ietf.org" Subject: Re: [sip-ops] [dispatch] SIP Resource availability Event package X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 21:34:24 -0000 --Apple-Mail-26-40632250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This draft looks pretty good. Should there be language that saids management= servers are alerted of critical conditions or is that outside of this draft= ? Michael L. Miller Sent from my Mobile Device On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" wr= ote: > Resource availability information from SIP devices improves the manageabil= ity of SIP devices by providing a framework for multiple applications like R= esource utilization monitoring, overload handling in SIP based media servers= . >=20 > This draft was discussed in IETF-78 SoC WG and considered as outside the s= cope of SOC as it focus on SIP overload based on non-critical resources like= DS0, DSP. By looking at the mediactrl WG charter and working documents, I d= oubt that this draft will falls under current media-ctrl work. As this draft= helps in SIP based devices manageability, I looked for SIP manageability re= lated WG but Sip-ops mailing alias only exists and there is no WG associated= with it. So, I'm putting this document in dispatch WG for further proceedin= gs. >=20 > Abstract is as follows: >=20 > "Collecting Resource availability information in Session Initiation Protoc= ol (SIP) devices in real time helps in better manageability of resources in t= he SIP network. Resource availability monitoring in SIP devices helps admini= strator to take informed decision and corrective measures to tackle under or= over resource utilization in the network. Resource availability information= can also be used for SIP overload control in SIP based Media servers by pas= sing resource demand vector between devices. This document defines resource a= vailability XML document and the mechanisms that can be used to exchange the= document between SIP entities." >=20 > The draft is available at http://datatracker.ietf.org/doc/draft-partha-dis= patch-resource-availability/. Could you please provide your valuable comment= s. >=20 > Thanks >=20 > Partha >=20 >=20 > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Mon 8/30/2010 7:50 PM > To: Parthasarathi R (partr) > Cc: Sheshadri Shalya (svshesha) > Subject: New Version Notification for draft-partha-dispatch-resource-avail= ability-00=20 >=20 >=20 > A new version of I-D, draft-partha-dispatch-resource-availability-00.txt h= as been successfully submitted by Parthasarathi R and posted to the IETF rep= ository. >=20 > Filename: draft-partha-dispatch-resource-availability > Revision: 00 > Title: Session Initiation Protocol (SIP) Resource availability E= vent package > Creation_date: 2010-08-30 > WG ID: Independent Submission > Number_of_pages: 17 >=20 > Abstract: > Collecting Resource availability information in Session Initiation > Protocol (SIP) devices in real time helps in better managebility of > resources in the SIP network. Resource availability monitoring in > SIP devices helps administrator to take informed decision and > corrective measures to tackle under or over resource utilization in > the network. Resource availability information can also be used for > SIP overload control in SIP based Media servers by passing resource > demand vector between devices. This document defines resource > availability XML document and the mechanisms that can be used to > exchange the document between SIP entities. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-26-40632250 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This draft looks pretty good. Should th= ere be language that saids management servers are alerted of critical condit= ions or is that outside of this draft?

Michael L. Miller<= /div>
Sent from my Mobile Device

On Aug 30, 2010, at= 12:51 PM, "Parthasarathi R (partr)" <= partr@cisco.com> wrote:

Resource availability information from SIP devices improves the manageabi= lity of SIP devices by providing a framework for multiple applications like R= esource utilization monitoring, overload handling in SIP based media servers= .

This draft was discussed in IETF-78 SoC WG and considered as outside the s= cope of SOC as it focus on SIP overload based on non-critical resources like= DS0, DSP. By looking at the mediactrl WG charter and working documents, I d= oubt that this draft will falls under current media-ctrl work. As this draft= helps in SIP based devices manageability, I looked for SIP manageability re= lated WG but Sip-ops mailing alias only exists and there is no WG associated= with it. So, I'm putting this document in dispatch WG for further proceedin= gs.

Abstract is as follows:

"Collecting Resource availability information in Session Initiation Proto= col (SIP) devices in real time helps in better manageability of resources in= the SIP network. Resource availability monitoring in SIP devices helps admi= nistrator to take informed decision and corrective measures to tackle under o= r over resource utilization in the network. Resource availability informatio= n can also be used for SIP overload control in SIP based Media servers by pa= ssing resource demand vector between devices. This document defines resource= availability XML document and the mechanisms that can be used to exchange t= he document between SIP entities."

The draft is available at http://datatracker.= ietf.org/doc/draft-partha-dispatch-resource-availability/= . Could you please prov= ide your valuable comments.

Thanks

Partha



From: IETF I-D Submission Tool [mail= to:idsubmission@ietf.org]
Sent: Mon 8/30/2010 7:50 PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya (svshesha)
Su= bject: New Version Notification for draft-partha-dispatch-resource-avail= ability-00


A new version of I-D, draft-partha-dispatch-resource-ava= ilability-00.txt has been successfully submitted by Parthasarathi R and post= ed to the IETF repository.

Filename:     &nb= sp;  draft-partha-dispatch-resource-availability
Revision: &nbs= p;      00
Title:      =      Session Initiation Protocol (SIP) Resource availabi= lity Event package
Creation_date:   2010-08-30
WG ID:  &= nbsp;        Independent Submission
Nu= mber_of_pages: 17

Abstract:
Collecting Resource availability infor= mation in Session Initiation
Protocol (SIP) devices in real time helps in= better managebility of
resources in the SIP network.  Resource avai= lability monitoring in
SIP devices helps administrator to take informed d= ecision and
corrective measures to tackle under or over resource utilizat= ion in
the network.  Resource availability information can also be u= sed for
SIP overload control in SIP based Media servers by passing resour= ce
demand vector between devices.  This document defines resourceavailability XML document and the mechanisms that can be used to
exchang= e the document between SIP entities.
      =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;           

The IETF Secretariat.


<= blockquote type=3D"cite">
________________________________________= _______
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/lis= tinfo/dispatch
= --Apple-Mail-26-40632250-- From partr@cisco.com Tue Aug 31 20:34:58 2010 Return-Path: X-Original-To: sip-ops@core3.amsl.com Delivered-To: sip-ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742CD3A68E2; Tue, 31 Aug 2010 20:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.189 X-Spam-Level: X-Spam-Status: No, score=-9.189 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEBxODF1bRt9; Tue, 31 Aug 2010 20:34:55 -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 531A03A68D0; Tue, 31 Aug 2010 20:34:55 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgGAIdmfUxAaMHG/2dsb2JhbACPYINhhRoBhzdKcaMpnBiFNwSEO4hR X-IronPort-AV: E=Sophos;i="4.56,301,1280707200"; d="scan'208,217";a="581580691" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2010 03:35:24 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o813ZN3r000827; Wed, 1 Sep 2010 03:35:23 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Sep 2010 09:05:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4986.B51BFFC5" Date: Wed, 1 Sep 2010 09:05:22 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP Resource availability Event package Thread-Index: ActJVHS+ebQI6RTDRGi7fyArDuPY7QAMOJfF References: <20100830142058.6A0EA3A69B8@core3.amsl.com> <5D9746F9-9D36-4482-8B61-94AED338EDE2@gmail.com> From: "Parthasarathi R (partr)" To: "Michael Miller" X-OriginalArrivalTime: 01 Sep 2010 03:35:22.0830 (UTC) FILETIME=[B56A9EE0:01CB4986] Cc: sip-ops@ietf.org, dispatch@ietf.org, sip-overload@ietf.org, mediactrl@ietf.org Subject: Re: [sip-ops] [dispatch] SIP Resource availability Event package X-BeenThere: sip-ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 03:34:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4986.B51BFFC5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, =20 Thanks for the comment. In the draft, Almost-out-of-resource element for = the particular resource has to be used whenever the resource is reaching = the critical condition (threshold) and it is explained in sec 5.4.1. = Almost-out-of-resource indication provides the alert to the = administrator about overuse of the specific resource in a particular = device. I'll add the text in the resource availability indication = mechanism for providing more clarity. =20 Thanks Partha ________________________________ From: Michael Miller [mailto:mlm.michael.miller@gmail.com] Sent: Wed 9/1/2010 3:05 AM To: Parthasarathi R (partr) Cc: ; sip-ops@ietf.org; sip-overload@ietf.org; = mediactrl@ietf.org Subject: Re: [dispatch] SIP Resource availability Event package This draft looks pretty good. Should there be language that saids = management servers are alerted of critical conditions or is that outside = of this draft? Michael L. Miller Sent from my Mobile Device On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" = wrote: =09 Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.=20 This draft was discussed in IETF-78 SoC WG and considered as outside = the scope of SOC as it focus on SIP overload based on non-critical = resources like DS0, DSP. By looking at the mediactrl WG charter and = working documents, I doubt that this draft will falls under current = media-ctrl work. As this draft helps in SIP based devices manageability, = I looked for SIP manageability related WG but Sip-ops mailing alias only = exists and there is no WG associated with it. So, I'm putting this = document in dispatch WG for further proceedings.=20 Abstract is as follows: "Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities." =09 The draft is available at = http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-availabili= ty/ = . Could you please provide your valuable comments. Thanks Partha =09 =09 ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Mon 8/30/2010 7:50 PM To: Parthasarathi R (partr) Cc: Sheshadri Shalya (svshesha) Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00=20 =09 =09 =09 A new version of I-D, = draft-partha-dispatch-resource-availability-00.txt has been successfully = submitted by Parthasarathi R and posted to the IETF repository. =09 Filename: draft-partha-dispatch-resource-availability Revision: 00 Title: Session Initiation Protocol (SIP) Resource = availability Event package Creation_date: 2010-08-30 WG ID: Independent Submission Number_of_pages: 17 =09 Abstract: Collecting Resource availability information in Session Initiation Protocol (SIP) devices in real time helps in better managebility of resources in the SIP network. Resource availability monitoring in SIP devices helps administrator to take informed decision and corrective measures to tackle under or over resource utilization in the network. Resource availability information can also be used for SIP overload control in SIP based Media servers by passing resource demand vector between devices. This document defines resource availability XML document and the mechanisms that can be used to exchange the document between SIP entities. = =20 =09 =09 The IETF Secretariat. =09 =09 =09 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 ------_=_NextPart_001_01CB4986.B51BFFC5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Michael,
=0A=
 
=0A=
Thanks for the comment. In = the draft, Almost-out-of-resource element for the = particular resource has to be used whenever the resource is = reaching the critical condition (threshold) and it is explained in = sec 5.4.1. Almost-out-of-resource indication provides the alert to = the administrator about overuse of the specific resource in a = particular device. I'll add the text in the resource availability = indication mechanism for providing more clarity.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=

=0A=
=0A= From: Michael Miller = [mailto:mlm.michael.miller@gmail.com]
Sent: Wed 9/1/2010 3:05 = AM
To: Parthasarathi R (partr)
Cc: = <dispatch@ietf.org>; sip-ops@ietf.org; sip-overload@ietf.org; = mediactrl@ietf.org
Subject: Re: [dispatch] SIP Resource = availability Event package

=0A=
=0A=
This draft looks pretty good. Should there be language that saids = management servers are alerted of critical conditions or is that outside = of this draft?
=0A=

=0A=
Michael L. Miller
=0A=
Sent from my Mobile Device
=0A=

On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" <partr@cisco.com> = wrote:

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

Resource availability information from SIP devices improves the = manageability of SIP devices by providing a framework for multiple = applications like Resource utilization monitoring, overload handling in = SIP based media servers.

=0A=

This draft was discussed in IETF-78 SoC WG and considered as outside = the scope of SOC as it focus on SIP overload based on non-critical = resources like DS0, DSP. By looking at the mediactrl WG charter and = working documents, I doubt that this draft will falls under current = media-ctrl work. As this draft helps in SIP based devices manageability, = I looked for SIP manageability related WG but Sip-ops mailing alias only = exists and there is no WG associated with it. So, I'm putting this = document in dispatch WG for further proceedings.

=0A=

Abstract is as follows:

=0A=

"Collecting Resource availability information in Session Initiation = Protocol (SIP) devices in real time helps in better manageability of = resources in the SIP network. Resource availability monitoring in SIP = devices helps administrator to take informed decision and corrective = measures to tackle under or over resource utilization in the network. = Resource availability information can also be used for SIP overload = control in SIP based Media servers by passing resource demand vector = between devices. This document defines resource availability XML = document and the mechanisms that can be used to exchange the document = between SIP entities."

=0A=

=0A=

The draft is available at http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-= availability/. Could you please provide your valuable = comments.

=0A=

Thanks

=0A=

Partha

=0A=


=0A=
=0A= From: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]
Sent: Mon 8/30/2010 7:50 = PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya = (svshesha)
Subject: New Version Notification for = draft-partha-dispatch-resource-availability-00

=0A=

=0A=

=0A=

A new version of I-D, = draft-partha-dispatch-resource-availability-00.txt has been successfully = submitted by Parthasarathi R and posted to the IETF = repository.

Filename:        = draft-partha-dispatch-resource-availability
Revision:   = ;     00
Title:  =          Session Initiation = Protocol (SIP) Resource availability Event = package
Creation_date:   2010-08-30
WG ID:  =          Independent = Submission
Number_of_pages: 17

Abstract:
Collecting = Resource availability information in Session Initiation
Protocol = (SIP) devices in real time helps in better managebility of
resources = in the SIP network.  Resource availability monitoring in
SIP = devices helps administrator to take informed decision and
corrective = measures to tackle under or over resource utilization in
the = network.  Resource availability information can also be used = for
SIP overload control in SIP based Media servers by passing = resource
demand vector between devices.  This document defines = resource
availability XML document and the mechanisms that can be = used to
exchange the document between SIP = entities.
          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          


= The IETF Secretariat.


=0A=
=0A=
_______________________________________________
dispatch mailing list
dispatch@ietf.org
<= A = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch
------_=_NextPart_001_01CB4986.B51BFFC5--